Closed Bug 661813 Opened 13 years ago Closed 12 years ago

Intermittent failure in browser_webconsole_bug_595934_message_categories.js | test #5: error category 'malformed-xml' - Got XPConnect JavaScript, expected malformed-xml


(DevTools :: General, defect, P2)

Windows XP


(Not tracked)

Firefox 17


(Reporter: vingtetun, Assigned: Dolske)



(Keywords: intermittent-failure)


(1 file)

Blocks: 438871
Whiteboard: [orange]
Sounds like a change to a call to ReportError somewhere in the platform
Summary: Intermittent failure in toolkit/components/console/hudservice/tests/browser/browser_webconsole_bug_595934_message_categories.js |test #5: error category 'malformed-xml' - Got XPConnect JavaScript, expected malformed-xml → Intermittent failure in browser_webconsole_bug_595934_message_categories.js | test #5: error category 'malformed-xml' - Got XPConnect JavaScript, expected malformed-xml
Assignee: nobody → getify
Four of those Jaegermonkey ones are interesting, because they're all on the same build - I wanted to be sure it was in shape to merge by getting a clean run, so I've just been retriggering and retriggering. Looks like maybe this failure is like the Linux SVG reftest failure that started around the same time, something that's busted in particular builds rather than something in the test providing the intermittence.
But apparently, I don't have a clue: failed five times straight on that one build, then I triggered another build on the same cset, and the test on that build passed, but I also triggered an extra four runs on a mozilla-inbound build that failed this earlier today, and all of those retriggers passed.
Assignee: getify → nobody
Priority: -- → P2
Hmm. This test is kind of strict (too strict?) in that it expects its nsIConsoleObserver to tell it about _only_ the logged console error it's expecting. If some other piece of code should happen to throw an error while this test is running, it will cause a failure.

This test should _probably_ just ignore unexpected console errors. That would mean that that if an expected error should fail to fire (or is logged in an unexpected form), then this test would timeout waiting for the expected error. But that seems ok.

Ideally something in the tests should be watching for unexpected console errors across all tests, since it might indicate something broke. But that's probably a hard state to get to -- I'm guessing that we log looooots of "errors" that are expected or harmless. I wonder how many errors are logged during a typical test run...
Attached patch Patch v.0Splinter Review
Like this, I think. Untested but I'm running out the door. ;-)
Assignee: nobody → dolske
Attachment #651075 - Flags: review?(mihai.sucan)
Comment on attachment 651075 [details] [diff] [review]
Patch v.0

Review of attachment 651075 [details] [diff] [review]:

Good point dolske. Thanks for your patch!

::: browser/devtools/webconsole/test/browser_webconsole_bug_595934_message_categories.js
@@ +115,5 @@
>      if (testEnded || !(aSubject instanceof Ci.nsIScriptError)) {
>        return;
>      }
> +    var expectedCategory = TESTS[pos].category,


(otherwise we get a syntax error)
Attachment #651075 - Flags: review?(mihai.sucan) → review+
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 17
Whiteboard: [orange]
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.