From a945053fd0a0f0f093d05054f7a351d5c91e1259 Mon Sep 17 00:00:00 2001 From: Raymond Hill Date: Tue, 15 Jul 2014 18:17:05 -0700 Subject: [PATCH] Updated Tricks and tips (markdown) --- Tricks-and-tips.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Tricks-and-tips.md b/Tricks-and-tips.md index bb837f1..2c881b8 100644 --- a/Tricks-and-tips.md +++ b/Tricks-and-tips.md @@ -1,6 +1,6 @@ #### Easy way to find out what other blockers do not block what they should block -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 evaluation of filters was done earlier in the pipeline, during `chrome.webRequest.onBeforeRequest`. This was required because the popup blocker code needs the HTTP referrer header to do its job. +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 another blocker does not block. Other blockers typically cancel requests during `chrome.webRequest.onBeforeRequest`, which means by the time µBlock's handler at `chrome.webRequest.onBeforeSendHeaders` time kicks in, many, if not all, net requests have been blocked by the other blocker(s).