search

ray-lothian / UserAgent-Switcher

A User-Agent spoofer browser extension that is highly configurable
https://webextension.org/listing/useragent-switcher.html
Mozilla Public License 2.0
949 stars 145 forks source link

webRequest listener needs to be registered synchronously in order to capture network requests at startup #132

Open Rob--W opened 3 years ago

Rob--W commented 3 years ago

Someone reported that the UA switching functionality does not work for URLs opened via the command-line at https://bugzilla.mozilla.org/show_bug.cgi?id=1725842.

Firefox does support interception and modification of URLs (and suspends network requests until the extension has loaded), but only for webRequest listeners that are registered again when the extension starts up. This event registration should happen immediately (i.e. synchronously). The extension however registers the events only after using the storage.local.get API, and consequently the extension may fail to rewrite the UA for initial requests.

ray-lothian commented 3 years ago

I can probably use localStorage instead of the browser.storage but since the extension ecosystem is moving to v3 and there will be no localStorage on the service worker, this is just a temporary solution.

If the user is calling FF from the terminal, why not set the initial UA by command-line until the extension takes place?

Rob--W commented 3 years ago

I can probably use localStorage instead of the browser.storage but since the extension ecosystem is moving to v3 and there will be no localStorage on the service worker, this is just a temporary solution.

Is it possible to use the declarativeNetRequest API to support the UA-switching functionality? This is not implemented in Firefox yet, but it will be.

If the user is calling FF from the terminal, why not set the initial UA by command-line until the extension takes place?

The CLI is a way to reproduce the bug. In reality something like clicking on a link while the browser isn't open yet would also trigger the issue.

ray-lothian commented 3 years ago

True, I think the new "declarativeNetRequest" API and its dynamic rule settings are the way to go. I'll play around to see if I can port the extension to use this API instead of the current async WebRequest.