1461090 - webRequests not always blocking

Status: RESOLVED DUPLICATE of bug 1447551

(WebExtensions :: Request Handling, defect)

Description

[Adam]

Attachment: Contains the user.js and [e-mail] test extension

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20180323154952

Steps to reproduce:

Environment:

Mozilla Firefox Developer Edition 61.0b4
Windows 7 SP1

I have been developing a private WebExtension and have been getting a very strange bug. The extension uses webRequest and webRequestBlocking. The extension is installed manually as an XPI unsigned file inside the Extensions folder inside my Firefox Profile folder and has the user.js settings to disable the unsigned extension check and autoDisableScopes set to 0 so the extension is installed automatically.

The extensions job is to synchronize cookies between a native app and Firefox by first blocking all onBeforeRequest requests until the cookies have been initialized from the native app into Firefox. However I was noticing that sometimes a request would "get through" before my onBeforeRequest listener would have time to catch it. Now here is the very strange part. If I close the Firefox profile and open it a few times the bug goes away and ALL requests are caught. It's only in the initial few launches (2nd one in particular) of the profile that the bug occurs. 

I have made a reproduce-able scenario. I have attached a user.js file and my test extension for testing the bug. Here are the steps:

1) Create a new Firefox profile using -no-remote -CreateProfile test_profile C:\test_profile_folder 
2) Navigate to the created profile folder and copy my attached user.js file (it disables the unsigned check/scopes and welcome/startup pages and sets a test homepage I've been testing with (http://httpbin.org/))
3) Inside the profile folder create a new folder called "Extensions" and copy the attached "[e-mail]" extension to this folder
4) Launch the profile now with -no-remote -P test_profile



Actual results:

The extension is very simple and all it does is add a onBeforeRequest listener that is blocking and returns cancel: true. So all it should be doing is not allowing any requests to happen.

On the first load of the profile I noticed it blocks correctly the majority of the time. If you goto the addons and enable addon debugging and then click the Debug addon button to open the console window for the addon, you should see the console log reports the correct homepage URL blocked as you would expect.

Now close the browser and relaunch the same profile again with -no-remote -P test_profile. THIS is where I see the bug happen the most. You will now probably see the homepage (http://httpbin.org/) load this time. HUH!? If you open up the debugging window for the addon you will see that the homepage was NOT blocked, but instead all of it's resources (js, images, etc) were. It's as if the extension "missed" the first request in the listener function.

Now here is where it gets even stranger. If you close the browser and launch it again using the same command, it may start blocking the page as you would expect, and will continue to work correctly on subsequent browser launches. It's only on the first few launches of the profile where this oddity occurs.


Expected results:

The onBeforeRequest should be blocking all requests as you would expect it to.

Comment 1

[Andrew Swan [:aswan]]

You report you are using Firefox 61.  Can you reproduce this issue with the preference extensions.webextensions.background-delayed-startup set to true?

Comment 2

[Kris Maglione [:kmag]]

This isn't that surprising. Extensions startup much faster when they're in the startup cache, which means they're much more likely to catch events at startup.

On the first startup, the extension won't actually be installed until after the window is visible. This is expected and intentional.

On the second startup, unfortunately, the startup cache will probably have been flushed from the installation in the previous session, so we're basically starting from scratch. Our startup cache flush handling is, unfortunately, pretty crude, and flushes way more than it needs to for WebExtensions.

On the third and subsequent startups, as long as you don't install a new extension, you'll be starting with a populated startup cache, so the extension will generally be started in time to catch early requests.

Comment 3

[Adam]

(In reply to Andrew Swan [:aswan] from comment #1)
> You report you are using Firefox 61.  Can you reproduce this issue with the
> preference extensions.webextensions.background-delayed-startup set to true?

Same issue with that user_pref set

Comment 4

[Adam]

I read the other bugzilla report and I downloaded the latest 61.0b4 from https://archive.mozilla.org/pub/devedition/releases/61.0b4/win64/en-US/ which I noticed in the src included the commits from the "fix". Not sure how the naming conventions of builds work in Firefox and why 61.0b4 is different than the version I had?

Anyway, with this latest version the blocking doesn't even work for the first launch of the newly created profile. It took 3 or 4 launches before it started blocking the first request.

So not sure why this is marked as resolved?