1653237 - Extensions fail to intercept requests that happen before the extension starts up

Status: NEW

(WebExtensions :: Request Handling, defect, P2)

Description

[Rob Wu [:robwu]]

Extensions that use proxy.onRequest or webRequest event listeners should always be able to intercept every request (provided that they have the right host permissions). At the startup of the browser, this is not guaranteed.
Bug 1447551 attempts to solve this by caching listeners and suspending matching requests until the background page finishes loading. This only works if the extension framework has started to initialize the background page of the extension. It fails to suspend requests that were started before the extension had started.

Ideally we should be able to suspend listeners without waiting for the full initialization of the extension framework, or at the very least offer an (off-by-default?) pref to suspend listeners until the webRequest module has finished its initialization if needed. Privacy-conscious users are probably willing to sacrifice some startup time for guaranteed request filtering.

STR:

1. Create a new profile directory ("profdir") and start Firefox: firefox --no-remote -profile profdir
2. Install uBlock Origin (or any other extension that intercepts and modifies network requests).
3. Quit Firefox
4. Start Firefox with a URL that would be blocked by the add-on: firefox --no-remote -profile profdir https://google-analytics.com/ga.js

Expected:

• The request should have been blocked.

Actual:

• The request is not blocked.

Comment 1

[Shane Caraveo (:mixedpuppy)]

We have a few tests for persistent event handlers, if those are passing but it doesn't actually work, that is bad. However, I'm unable to reproduce this, ublock does block the request on startup for me.

Comment 2

[Rob Wu [:robwu]]

I have repeatedly tested in Firefox 78.0.1 on Linux, and in all cases the request is not blocked (despite the listeners being present in addonStartup.json.lz4). Reloading the page does result in a block, so the add-on is working as expected (just not at startup).

This issue only happens if the network request is processed before the extension starts. If the network is slow (e.g. it takes a while before the DNS request is resolved), then I can imagine the issue being non-reproducible.

Comment 3

[gwarser]

I can confirm that URL from command line is not blocked. I noticed this when persistent listener was implemented in uBO https://github.com/uBlockOrigin/uBlock-issues/issues/128#issuecomment-435606901

Comment 4

[Christoph Anton Mitterer]

Guess I (and others) see the same thing... see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002592

Could be even a security issue, when the add-on in someway provides or adds to security.

Cheers,
Chris.