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).
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
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"
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.
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.
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.