-
-
Notifications
You must be signed in to change notification settings - Fork 191
Tricks and tips
Since version 0.2.0.0, when the popup blocker code was added, µBlock decides whether a request should be cancelled during chrome.webRequest.onBeforeSendHeaders
. Before 0.2.0.0, the cancellation of net requests was done earlier in the pipeline, during chrome.webRequest.onBeforeRequest
. The change was required because the popup blocker code needs the HTTP referrer header to do its job.
Net requests can be cancelled as effectively using chrome.webRequest.onBeforeSendHeaders
, so it's not an issue. There is a side effect though, which can actually be quite useful: you can find out what other blockers do not block.
Other blockers typically cancel requests during chrome.webRequest.onBeforeRequest
, which means by the time µBlock's handler kicks in, many, if not all, net requests have been blocked by the other blocker(s).
So in such case, if you notice µBlock actually still ends up blocks something, it's actually everything the other blocker(s) did not block. Thus, µBlock can also be used to find out what other blockers are missing.
Here is an example. ABP with EasyList and EasyPrivacy. µBlock shows it blocked one request, thus something was not blocked by ABP:
Turns out it's Google Analytics... I really thought EasyPrivacy was blocking completely Google Analytics. How many of you also thought so? (Found this...).
Once you disable the other blocker(s), µBlock will take over the whole responsibility to block all you want (and this includes Google Analytics with out of the box settings, via "Peter Lowe’s Ad server list"):
Note that using µBlock as a tool to find out what other blockers do not block works as long as the other blockers completely rely on chrome.webRequest.onBeforeRequest
to do their job, and not on chrome.webRequest.onBeforeSendHeaders
.