1401516 - Extension with listener at webRequest.onHeadersReceived breaks navigation (crash/blank page) when the previous page performs sync XHR upon unload

Status: RESOLVED DUPLICATE of bug 1396395

(WebExtensions :: Request Handling, defect, P5)

Description

[Oriol Brufau [:Oriol]]

Attachment: screencast.gif

1. Disable e10s
2. Set default search engine to DuckDuckGo
2. Install https://addons.mozilla.org/en-US/firefox/addon/ublock-origin/versions/1.14.8
3. Go to https://twitter.com/tabatkins and wait until it loads
4. Enter some text like 123 into the location bar and press enter to search it.

Result: A white page. If the default search engine is Google instead of DuckDuckGo, then the load spinner never disappears and you still see the Twitter page instead of Google.

This appeared in https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=461cde474a975489d9b1e411a0fab6c3e4e53bec&tochange=95bb4ca0e110cd8f07e7f355d71de8b7caab5121

After this change, Firefox crashed when doing the steps above. This was fixed in https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=9962668136836ded544ef877d5b6658b5dcc109f&tochange=cd03cacfcdddb92b40e259af83abdaaeaabc00b4 but there are still problems.

Comment 1

[Bob Silverberg [:bsilverberg]]

I have not been able to replicate the white page, but have been able to replicate the case where the loading animation on the tab never disappears and one is left on the original page, although the URL in the location bar is updated to the URL one would expect for the search. 

I also tried navigating from the test page listed in step 3, above to https://twitter.com by typing that into the location bar and had the same result (i.e., no navigation happened). I have witnessed the same behaviour trying to navigate from a number of different twitter pages to a number of different domains, although it doesn't always replicate.

Comment 2

[Rob Wu [:robwu]]

I can consistently get Firefox to crash, Firefox release (55.0.3) and Firefox Nightly. I also tried to run Firefox Nightly with AddressSanitizer, but ASAN did not intercept the crash.

https://crash-stats.mozilla.com/report/index/21de39d2-0663-4738-949d-eeda40170921

1. Create a new Firefox profile, disable e10s, install uBlock Origin (version 1.14.8).
2. Visit https://twitter.com/tabatkins and bookmark it (for ease of reproduction).
3. Clear browser cache and quit Firefox (just to rule out any other causes).
4. Start Firefox.
5. Click on the bookmark.
6. After Twitter has loaded, visit example.com.
7. CRASH in ParseAvailableData on "HTML5 parser" thread.

Comment 3

[Andy McKay]

So this only crashes when e10s is off?

Comment 4

[Bob Silverberg [:bsilverberg]]

(In reply to Andy McKay [:andym] from comment #3)
> So this only crashes when e10s is off?

For me, yes.

Comment 5

[Rob Wu [:robwu]]

Attachment: webRequest-onHeadersReceived-and-sync-xhr-unload-1401516.zip

Minimal reduction:

1. Disable e10s.
2. Load an extension that listens to webRequest.onHeadersReceived for the main_frame type.
3. Open a page (file: or http(s):, either works) that sends a synchronous XMLHttpRequest (e.g. requesting the page itself) **upon window.unload**.
4. Navigate to a URL that triggers onHeadersReceived in the extension (THE PAGE SHOULD NOT BE IN THE BROWSER CACHE).
--> CRASH or blank page (blank page if the destination URL loads slowly?)


The attached zip file contains
./reduced-extension/background.js
./reduced-extension/manifest.json
./site/index.html

The reduced-extension directory should be loaded at about:debugging.
site/index.html can be opened from the file system or a local file server.
After opening index.html, click on one of the top links to induce a crash or blank page.

Comment 7

[Rob Wu [:robwu]]

This also affects Android, just tested on Firefox Nightly for Android:
https://crash-stats.mozilla.com/report/index/ca4f8ba4-3577-4412-beaa-ef58b0170921

e10s is not available in Firefox for Android, so even if desktop switches to e10s in Firefox 57 for the majority of users, then Firefox Android will still be affected by this bug (keep that in mind before marking this as P5).

Comment 8

[Andy McKay]

Shane to investigate and change priority as needed.

Comment 9

[Shane Caraveo (:mixedpuppy)]

I'm unable to reproduce a crash on osx, trying windows next.

Comment 10

[Shane Caraveo (:mixedpuppy)]

Also unable to reproduce on windows, not sure where to go from here.

Comment 11

[Oriol Brufau [:Oriol]]

Fixed in bug 1396395.