782167 - Downgrade MOZ_ASSERT(win->IsClosedOrClosing()) to an NS_ASSERTION until it stops happening so often

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Phil Ringnalda (:philor)]

Attachment: downgrade

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 https://tbpl.mozilla.org/php/getParsedLog.php?id=14327884&tree=Try hitting the NS_ASSERTION): https://tbpl.mozilla.org/?tree=Try&rev=2f0c4a1feda9

Comment 1

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/9e0799cf1096

Comment 2

[Ed Morley [:emorley]]

Thank you for changing this :-)

Comment 3

[Bobby Holley (:bholley)]

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

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/9e0799cf1096

Comment 5

[Phil Ringnalda (:philor)]

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.