Issue 6622 - Implement $rewrite filter option

lib/requestBlocker.js

Index: lib/requestBlocker.js
===================================================================
--- a/lib/requestBlocker.js
+++ b/lib/requestBlocker.js
@@ -65,20 +65,21 @@
 
   for (let type in browser.webRequest.ResourceType)
     yield resourceTypes.get(browser.webRequest.ResourceType[type]) || "OTHER";
 
   // WEBRTC gets addressed through a workaround, even if the webRequest API is
   // lacking support to block this kind of a request.
   yield "WEBRTC";
 
-  // POPUP, CSP and ELEMHIDE filters aren't mapped to resource types.
+  // These filter types aren't mapped to resource types.
   yield "POPUP";
   yield "ELEMHIDE";
   yield "CSP";
+  yield "REWRITE";
 }());
 
 function getDocumentInfo(page, frame, originUrl)
 {
   return [
     extractHostFromFrame(frame, originUrl),
     getKey(page, frame, originUrl),
     !!checkWhitelisted(page, frame, originUrl,
@@ -189,24 +190,41 @@
     return;
 
   let type = resourceTypes.get(details.type) || "OTHER";
   let [docDomain, sitekey, specificOnly] = getDocumentInfo(page, frame,
                                                            originUrl);
   let [filter, urlString, thirdParty] = matchRequest(url, type, docDomain,
                                                      sitekey, specificOnly);
 
+  let result;
+
+  if (filter instanceof BlockingFilter)
+  {
+    if (filter.rewrite)
+    {
+      let rewritten = filter.rewriteUrl(urlString);
+      if (rewritten == urlString)

[Manish Jethani, 2018/05/04 15:37:47]

Do we still need this check? If the filter matched there was a rewrite, even if
the result was the same.

[hub, 2018/05/04 18:27:58]

definitely. a redirectUrl will cause onBeforeRequest to be called again - which
will likely be an infinite loop until the browser cancel it. By just doing a
return we say "let's go". 

+        // we couldn't do the rewrite, so just let it through.
+        return;
+
+      type = "REWRITE";

[Manish Jethani, 2018/05/04 15:37:47]

Also I'm wondering if it makes sense to set the type here. The original type may
be "SCRIPT" and now we're overwriting it with "REWRITE", but we don't provide
information on what it was rewritten to. Technically we did block the original
script, we just redirected it to a new resource. I'm wondering if I would prefer
to see "SCRIPT" rather than "REWRITE" in the DevTools panel in this case.

[Sebastian Noack, 2018/05/04 15:46:49]

I already thought the same, and tend to agree to not indicate requests matching
a $rewrite filter with a type of REWRITE. This would be a leaky abstraction. But
then we need a different way to indicate $rewrite filters in the devtools panel.

[hub, 2018/05/04 18:27:58]

I have a solution to indicate the rewrite in the devtools panel. It requires a
change in adblockplusui (for which I have a patch) to actually display it.

But then I wanted to be able to filter REWRITE explicitly. Can't have both the
type and REWRITE in the filter though. Not sure there is an easy way without an
overhaul of the logging.

If you think we don't need to filter REWRITE, then I'm fine. It will simplify
this part.

+      result = {redirectUrl: rewritten};
+    }
+    else
+      result = {cancel: true};
+  }
+
   getRelatedTabIds(details).then(tabIds =>
   {
     logRequest(tabIds, urlString, type, docDomain,
                thirdParty, sitekey, specificOnly, filter);
   });
 
-  if (filter instanceof BlockingFilter)
-    return {cancel: true};
+  return result;
 }, {urls: ["<all_urls>"]}, ["blocking"]);
 
 port.on("filters.collapse", (message, sender) =>
 {
   let {page, frame} = sender;
 
   if (checkWhitelisted(page, frame))
     return false;