As a security precaution, we have turned on the setting "Require API key authentication for API requests" for everyone. If this has broken something, please contact
Last Comment Bug 782167 - Downgrade MOZ_ASSERT(win->IsClosedOrClosing()) to an NS_ASSERTION until it stops happening so often
: Downgrade MOZ_ASSERT(win->IsClosedOrClosing()) to an NS_ASSERTION until it st...
Product: Core
Classification: Components
Component: XUL (show other bugs)
: Trunk
: All All
: -- critical (vote)
: mozilla17
Assigned To: Phil Ringnalda (:philor)
: Neil Deakin
Depends on:
Blocks: 777875 778424 781078
  Show dependency treegraph
Reported: 2012-08-12 17:18 PDT by Phil Ringnalda (:philor)
Modified: 2012-08-13 11:18 PDT (History)
2 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

downgrade (1.41 KB, patch)
2012-08-12 17:18 PDT, Phil Ringnalda (:philor)
khuey: review+
Details | Diff | Splinter Review

Description User image Phil Ringnalda (:philor) 2012-08-12 17:18:45 PDT
Created attachment 651242 [details] [diff] [review]

Between them, bug 777875 and bug 778424 and bug 781078 are amounting to around 15% of our test failures, though that undercounts their effect, since hitting a MOZ_ASSERT effectively means that we didn't run that test suite.

This is Gecko 17, as in what will become esr17, so we can't just say "oh, well, if it gets fixed for 18 in a way that can't jump trains, we can just live with it for 18 weeks on release branches." This Gecko's going to be around until after Gecko 25, in December 2013. AFAIK, nobody has looked at it so nobody can say whether or not it'll be fixed in a train-jumpable way.

Dropping down to an NS_ASSERTION lets us not crash mochitest runs, while still making it possible for someone looking into the problem to debug. If someone fixes the problem, great, they can revert to MOZ_ASSERT, but if not, we won't wind up having to retrigger and retrigger mochitest-1 and mochitest-oth from now until December 2013 just to get a run where every test gets a chance to be run.

Try run (including hitting the NS_ASSERTION):
Comment 2 User image Ed Morley [:emorley] 2012-08-13 01:11:29 PDT
Thank you for changing this :-)
Comment 3 User image Bobby Holley (:bholley) (busy with Stylo) 2012-08-13 01:44:01 PDT
FWIW, I have been looking into this - working with QA to try to find STR over in bug 776497, which I think is the version of this bug in the wild.

Regardless though, I totally agree with this course of action. Thanks for fixing that Philor!
Comment 4 User image Ed Morley [:emorley] 2012-08-13 11:10:56 PDT
Comment 5 User image Phil Ringnalda (:philor) 2012-08-13 11:18:49 PDT
STR may well involve triggering a tooltip - every instance I've seen with the NS_ASSERTION, after the busted stacks from failing to download symbols, winds up with a "JavaScript error: chrome://browser/content/browser.xul, line 1: NS_ERROR_FAILURE: Failure arg 0 [nsIDOMXULDocument.tooltipNode]" which I'm guessing is the returned NS_ERROR_FAILURE after the assertion.

Note You need to log in before you can comment on or make changes to this bug.