1299586 - Firefox Release w/"No more 404s" extension hangs whole browser on loading treeherder links (Force Close)

Status: RESOLVED DUPLICATE of bug 1279246

(WebExtensions :: Compatibility, defect, P1)

Description

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

STR:
1. On OSX, launch Firefox 48.0.1 with a clean profile.
2. Install "Test Pilot" and the "No more 404s" extensions.
3. Launch URL.
4. (If necessary) quit and restart browser, then launch URL.

Expected result:
- I can see both left and right side of treeherder page, and continue working.

Actual result:
- I see only left side of treeherder page, a spinning beachball of death, and totally frozen Firefox.

No UX or tabs work (I'm in the non-e10s population) and I'm forced to "Force Close", at which point I don't even get Mozilla's crash reporter, instead I get the "Send to Apple" one (do we even get those?)

Workaround:
- Disable the "No More 404s" extension (and possibly restart).

Comment 1

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

On Windows 8.1 with Firefox 48.0.2, I can sometimes reproduce the issue.

Maybe related to these kind of error messages?

Error: NS_BINDING_ABORTED: Component returned failure code: 0x804b0002 (NS_BINDING_ABORTED) [nsIStreamListener.onDataAvailable]
Source File: resource://gre/modules/WebRequest.jsm
Line: 223

Loading the treeherder tab sometimes doesn't finish and closing the Firefox window doesn't terminate the process (it hangs) and the crashreporter will pop up later, e.g. https://crash-stats.mozilla.com/report/index/2ae1667a-2420-4036-a828-fdf902160831

Comment 2

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

I can repro this bug.

Looking in the browser toolbox, this error is listed with a '1000' badge next to it, which I don't believe I've ever seen before (1000 errors mapped to a single error trace):

"Handler function DebuggerTransport.prototype.onOutputStreamReady threw an exception: [Exception... "Component returned failure code: 0x80470007 (NS_BASE_STREAM_WOULD_BLOCK) [nsIOutputStream.write]"  nsresult: "0x80470007 (NS_BASE_STREAM_WOULD_BLOCK)"  location: "JS frame :: resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/transport/packets.js :: JSONPacket.prototype.write :: line 197"  data: no]
Stack: JSONPacket.prototype.write@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/transport/packets.js:197:17
DebuggerTransport.prototype.onOutputStreamReady<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/transport/transport.js:279:9
exports.makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/ThreadSafeDevToolsUtils.js:101:14
Line: 197, column: 0"

Comment 3

[Kris Maglione [:kmag]]

I've only managed to reproduce this once on Linux. It would be helpful if you can get a profiler report, or reproduce this under a debugger and get a JS stack. Otherwise, I'll keep trying to reproduce it myself.

(In reply to Sebastian Hengst [:aryx][:archaeopteryx] from comment #1)
> Maybe related to these kind of error messages?
> 
> Error: NS_BINDING_ABORTED: Component returned failure code: 0x804b0002
> (NS_BINDING_ABORTED) [nsIStreamListener.onDataAvailable]
> Source File: resource://gre/modules/WebRequest.jsm
> Line: 223

I've only seen these for onStartRequest. As far as I can tell, they're happening for cached requests for Persona resources. I don't think they're related to the problem, but it would probably be good to fix either way.

(In reply to Jared Hirsch [:_6a68] [NEEDINFO please!] from comment #2)
> Looking in the browser toolbox, this error is listed with a '1000' badge
> next to it, which I don't believe I've ever seen before (1000 errors mapped
> to a single error trace):

That's not surprising, given that the main thread of the browser is blocked.

Comment 4

[krupa raj [:krupa--use this to needinfo]]

I'm able to consistently reproduce this issue on 48.0.2/mac osx 10.11.6

STR:
1. Start a new profile 
2. Install testpilot, nomore404s and the geckoprofiler-signed.xpi add-on
3. Load the treeher URL provided in the bug report
4. If firefox doesn't hang on teh first try, restart Firefox a few times and reload the URL

observed behavior:
Firefox freezes and becomes unusable. I had to Force quit every time. Firefox didn't crash even after being frozen for  > 20 minutes.

Notes:
Firefox froze on me which made it hard to get any profiler report. So, I forced a crash and here are the details - https://crash-stats.mozilla.com/report/index/19ce1b76-e3d6-4e65-b127-b9f022160912

Let me know if that helps.

Comment 5

[Robert (rrayborn, he/him)]

From a feedback perspective I didn't find anything super compelling:

 * There is not an obvious downtick of the rating from active or disabled users
 * There is not any write-in feedback since 8/31 obviously related to this in the "disable" exit survey
 * There have been a few reports of performance related issues without much detail before 8/31:
 ** 2016-08-07 - "I have seen significant slowdowns of firefox since then and want to try and see if this is the problem" - Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
 ** 2016-08-08 - "I have the felling my connection was slowed down significantly. I tested opening the same page on Chrome and Firefox and the time difference is noticeable. I'm disabling No More 404s to test if this is a real situation or not. It seems to slow down my connection" - Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Firefox/47.0
 ** 2016-08-23 - "After enabling No More 404s, My Fireforx hangs and crashes at times. This is a useful plugin. Please fix the problem if any. I have reported the crashes through the standard Firefox Crash Reports. Hope they would help you in resolving the issue. I will keep No More 404s disabled for a few days to check whether it was a problem of this plugin or some other. Firefox hangs up or crashes from time to time." - Mozilla/5.0 (Windows NT 6.1; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0
 ** 2016-08-30 - "It does not work with Nightly" - Mozilla/5.0 (X11; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0


If you have any other feedback avenue analysis that you think might be productive, let me know.