When I catch a browser webRequest with: chrome.webRequest.onBeforeRequest
It works well. But only when the browser was open already. If the browser was closed and an external application opens this link, the webRequest won’t be watched. It looks like the extension is at that time not active.
How can I handle this?
My extension already has the background permission in the manifest.json file.
My extension already has the background permission in the manifest.json file.
While that may help in Chrome, Firefox doesn’t support it. (And I don’t think it ever will, how could this ever work with multiple profiles?)
I thought Firefox already had a logic similar to the one Chrome uses to resume event pages: record the extensions event listeners at shutdown and at startup, stall those events until the extension is started, then fire them.
Either that doesn’t work, isn’t implemented yet, or you are not adding your listeners soon enough / remove them to early.
@NilkasG So is there no option for firefox to intercept webRequests made on startup of firefox? My listeners are in the background.js right on top. Is there an earlier way to register listeners?
@freaktechnik In my list of permissions webRequest & webRequestBlocking is already listed. My firefox version so this should work.
Yeah, this should be working as far as it can with Firefox 61: https://bugzilla.mozilla.org/show_bug.cgi?id=1447551 (though bug fixes to the system may possibly have been introduced in later versions, since it’s an improvement over the status quo)
It doesn’t really matter where you add them from, but when they are added, i.e. whether you allow the event loop to pass one or multiple times before adding them.
If you add them in a callback of an asynchronous operation (retrieving data from browser.storage, fetching scripts/resources, setTimeout, or really anything that involves Promises, you let the event loop pass and your listeners are not added synchronously anymore, which may be required here (even though I think that is pretty poor API design (originally by the Chrome team), considering that all browser APIs are asynchronous).
Okay so this bug is already fixed but still present in the current version as far as I can interpret this. Some commented this issue as verified and tested with version 61.x
Im working with version 62.x but still see this error.