According to https://bugzilla.mozilla.org/show_bug.cgi?id=1283160#c6, proxy filters registered with nsIProtocolProxyService execute before onBeforeRequest fires, though the opposition should happen. We need to either make webRequest.onBeforeRequest fire earlier or execute proxy filters later, and I think the former might be easier.

I'm not convinced webRequest.onBeforeRequest() should fire before nsIProtocolProxyService.applyFilter(). The argument in bug 1283160 seems to have to do with: > Our [chrome] extension works per tab This is not possible in Firefox WebExtensions until bug 1368559 lands. It's also worth noting the extension in bug 1368559 has never had a Firefox version, as far as I can tell. > and also filters out some requests (like video/audio), so we are sending config to the pac script in webRequest.onBeforeRequest for every request. In my opinion, this bug should be closed and a new one opened. Since nsIProtocolProxyService.applyFilter() is handed an nsIChannel instance, not a URI (that's according to bug 436344), we may be able to hand FindProxyForURL() mime-type info from nsIChannel.contentType as part of bug 1368559. I do not know if mime-type info is available at that point, but it is worth investigating.

I mentioned this in some other bug, bug onBeforeRequest is a result of the http-on-modify-request notification. It cannot move earlier without breaking compat. The proxy api will need to change to work after that. Baring the ability to do that, we'd need to decide whether supporting an earlier (but different) listener using http-on-opening-request.

> we'd need to decide whether supporting an earlier (but different) listener using http-on-opening-request. I still want to know why this is needed. It seems to me the original need may be bogus because the addon author is trying to port a Chrome addon to Firefox while the proxy APIs between the two are completely different.

Bug 1409878 will use the channel filter and provide more data, I'm not seeing a strong reason to muck with the timing here.