I coincidentally ran across the following bug: I'm not sure what caused it, but it's always reproducable by following the following steps (also tested in a blank Firefox profile without any add-ons): 1. Open Gmail - https://mail.google.com/mail/ 2. Look for a mail with an attachment. 3. Copy the URL of the attachment. 4. Execute the following code in the console: var x = new XMLHttpRequest(); x.open('get','....URL HERE...'); x.responseType = 'blob'; x.send(); 5. Firefox segfaults
Can you please provide a stacktrace or crash ID. https://developer.mozilla.org/en/How_to_get_a_stacktrace_for_a_bug_report
bp-5c7ac4f4-8910-4966-ad13-0088d2120914 Following the following steps: 1. Run Firefox with a new profile: * Create a directory, e.g. %tmp%\test or /tmp/test * Execute `firefox -profile /tmp/test --no-remote` 2. Add-ons > Install NoScript (tested using 2.5.5) 3. Restart browser (to activate NoScript) 4. Visit https://mail.google.com/ 5. Log in. 6. Run the following code: var x = new XMLHttpRequest(); x.open('get','https://mail.google.com/mail/?view=att'); x.responseType = 'blob'; x.send(); 7. Watch Firefox crash (seemingly after receiving the headers) - Discovered in Firefox 15.0 on Linux, reproduced in FF 15.0.1 on Windows and FF 15.0.1 on Linux. (I am not able to reproduce this bug in an blank profile (ie. without NoScript) any more, but I'm quite certain that the bug was reproduced in a profile without any add-ons, once, before creating this bug report.).
Can mBuilder be null in nsXMLHttpRequest::OnStopRequest?
bp-838d25bf-a05a-42f5-b8b5-aa9b12120916 Shorter STR (NoScript is not needed): var x = new XMLHttpRequest(); x.open('get','data:,'); x.responseType = 'blob'; x.send(); If the channel is non-file non-cacheable and if the response length is zero, both mDOMFile and mBuilder can be null here.
Created attachment 661606 [details] [diff] [review] Create an empty dummy builder in OnStopRequest if builder is null
(In reply to Masatoshi Kimura [:emk] from comment #6) > https://tbpl.mozilla.org/?tree=Try&rev=45e64ced59c7 Green on Try. https://hg.mozilla.org/integration/mozilla-inbound/rev/f5db1f9f47fc
It has spiked across 17 ESR since July 31, 19:30 UTC. It's currently #6 browser crasher in 17.0.7esr and #7 in 17.0.8esr.
It would be good to uplift it in 17.0.9esr that will be spin along with 23.0.1.
We don't take stability fixes to the ESR branches, unless there is a security implication here. Also given we're about to publish an ESR24 that orgs can migrate to (which would not be affected by this crash) we have a viable workaround for enterprise users.