Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blocking "early" requests is not possible #1327

Closed
laniakea64 opened this issue Jan 31, 2016 · 11 comments
Closed

Blocking "early" requests is not possible #1327

laniakea64 opened this issue Jan 31, 2016 · 11 comments

Comments

@laniakea64
Copy link

Environment: SeaMonkey 2.39, uBlock Origin 1.6.0 (self build from c7f1027 ), new profile

Steps to reproduce:
(shouldn't matter but I'm starting SeaMonkey from command line like: seamonkey -p. I have seen this issue starting SeaMonkey normally though.)

  1. install uBlock Origin, restart SeaMonkey
  2. set as home page, a page that contains an image that should be blocked (for this step, I put the following page up on my local test server and an image at the mentioned path: )
<!doctype html>
<img src="/banners/ads/advertisement.gif" />
<div>image blocked or allowed</div>
  1. restart SeaMonkey
    (if re-testing with the same profile, clear cache before restarting SeaMonkey again, to make sure nothing is loaded from cache)

Expected results: image is blocked

Actual results: image appears on screen (it loaded). The image does not get blocked until reloading the page.
(Un-checking "Hide placeholders of blocked elements" makes it easier to see what's going on, but is not necessary to reproduce the problem.)

IIUC this is not technically possible to fix in non-Gecko-based-browsers because there the browser doesn't load extensions until after firing the first network requests, making this moot. However, in Gecko-based browsers the extensions are loaded before any requests are fired, and can have control over these requests.
It is not reasonable to expect that uBlock Origin can finish initializing all its filters before the browser can fire requests, so I would suggest to fix the problem something like this: When "I am an advanced user" is checked, allow the user to choose whether "early" network requests (requests fired before uBlock Origin is finished loading) are allowed or blocked (default to allow, and this setting locked to allow if "I am an advanced user" is un-checked). (Also preferably blocking "early" requests would not be strict-blocked - that is, not blocked unless requested by a document loaded in a browser window/tab. But if top-level documents would have to be blocked as well, it wouldn't end to be a big deal.)

@gorhill
Copy link
Owner

gorhill commented Jan 31, 2016

Thing is, even the reading of the user settings -- which contains the state of the "advanced user mode" -- is asynchronous, so theoretically uBO could still be waiting on those settings to be loaded after it has handed control over to FF (i.e. finished executing its first-pass initialization code).

@laniakea64
Copy link
Author

Oops, didn't realize that reading extension settings was async...
Since it has to be Gecko-only, this setting could be an about:config boolean pref named something like extensions.ublock0.blockEarlyRequests and not directly tied to any extension settings.

@gorhill
Copy link
Owner

gorhill commented Feb 1, 2016

not directly tied to any extension settings

I have floated the idea of hidden settings since a while now to deal with a number of demands for specific behaviors sort of trivial to implement -- as long as there is no UI and no complicated code paths to add (actually there is already one such setting used in the logger, extensions.ublock0.loggerAutoDeleteVoidRows).

So this could be one of those settings. uBO could completely block a page from loading, and once initialization is done, it could force a reload of the pages which were blocked. The worry though here is about those behind-the-scene tabs (to not confuse with behind-the-scene requests) FF loads at start up time (like https://self-repair.mozilla.org/en-US/repair), will have to experiment to find out the results.

@gorhill gorhill changed the title ("Firefox" version only) Blocking "early" requests is not possible Nov 4, 2016
@gorhill
Copy link
Owner

gorhill commented Nov 4, 2016

Fixed with 8c3da95. Need to be tested. If the fix does not help, then it will mean there is nothing uBO can do.

Behind-the-scene network requests are left untouched, regardless of filters/rules -- behind-the-scene network requests are tabless, there is no tab which can be force-reloaded once all filters/rules are loaded.

@laniakea64
Copy link
Author

If the fix does not help, then it will mean there is nothing uBO can do.

Oddly, I can't reproduce this issue in uBlock Origin 1.9.17b4 even without flipping that setting. I'd say the fix definitely helped.

We'll flip the setting anyway and let you know any issues.

Thanks. 😃

@gorhill
Copy link
Owner

gorhill commented Nov 29, 2016

Link to the documentation on how to enable early blocking: https://github.com/gorhill/uBlock/wiki/Advanced-settings#suspendtabsuntilready-experimental.

@ghost
Copy link

ghost commented Dec 25, 2017

In Chrome, I wonder if uBlock could make use of chrome://discards functionality to "block" tabs from loading at startup (just like the very minimal Sloth extension currently does) and maybe have that as an addition to suspendTabsUntilReady ? Just a thought. Merry Xmas btw :)

@gwarser
Copy link
Contributor

gwarser commented May 4, 2018

RESOLVED FIXED in Firefox 61 https://bugzilla.mozilla.org/show_bug.cgi?id=1447551

Seems to work for me.

Maybe after this will finally work https://bugzilla.mozilla.org/show_bug.cgi?id=1457224

@gwarser
Copy link
Contributor

gwarser commented Jul 13, 2018

Network part was fixed in Let webRequest listeners see/block requests from early after browser startup #1447551 but required about:config pref extensions.webextensions.background-delayed-startup and now Enable delayed background page startup for all channels #1473757 was RESOLVED FIXED

Firefox should be OK now at least for network filtering.

@gorhill
Copy link
Owner

gorhill commented Dec 24, 2018

This is no longer experimental on Firefox: 41548be as of 1.17.5b17.

Firefox supports the ability to block early requests when a webRequest listener is registered in a certain way, see https://bugzilla.mozilla.org/show_bug.cgi?id=1503721.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants