onBeforeRequest event not fired Firefox is started with command line options

Add-ons Development
#1

Hi,

I’ve created an add-on which listens to several events like onBeforeRequest.

The lines:

var callbackFilter = {types: [“main_frame”, “sub_frame”, “xmlhttprequest”, “websocket”], urls: ["<all_urls>"]};
browser.webRequest.onBeforeRequest.addListener (onBeforeRequestCallback, callbackFilter);

are executed at the beginning in the background script.

This works fine when Firefox is opened and a webpage is opened afterwards.
But when Firefox is started via command line with an URL as parameter, the event for the first URL is not fired. The following events were fired correctly.
Command line example: start firefox https://www.mozilla.org

Can anybody confirm this behavior?

#2

I’m pretty sure you have to have a blocking listener for it to filter requests that were started before your extension is loaded.

#3

I don’t want to block URL. Just get a timestamp and the requested host (and some more metadata).

By the way: the events onCompleted and onBeforeRedirect, which I also subscribed, were not fired.

#4

“blocking” doesn’t mean that you want to necessarily block the request in this case, it means that the request can’t be completed until your listener has ran.

#5

I added “webRequestBlocking” to the manifest.json file, and the new listener line looks like this:
browser.webRequest.onBeforeRequest.addListener (onBeforeRequestCallback, callbackFilter, [“blocking”]);

The onBeforeRequestCallback function returns:
return {cancel: false};

Is it that what you meant? I still get not notified…

#6

Yes, that’s what he mean’t. You don’t actually need to return anything, I think.

I’m pretty sure this is supposed to work. IIRC this behaviour was added rather recently.
When shutting down, Firefox remembers which extensions installed blocking listeners. If they were any, Firefox stalls all (matching?) requests untill the extension is loaded and had a chance to add the listeners again.

So you must have had this listener added on the last shutdown and you have to add it again immediately when the extension gets started.
I think the latter is actually a pretty bad design, considering the inherently asynchronous nature of JavaScript and WebExtensions. (Chrome does the same.)
Also it forces you to permanently add a blocking listener (which is bad for performance) even if you are actually just interested in logging.