Permanent, but intermittent counted as failure test_hiddenitems.xul | blur 10,slider - got [object XULElement], expected [object HTMLInputElement]

RESOLVED FIXED in mozilla15

Status

()

Product:
Toolkit
Component:
XUL Widgets
Type:
defect
Status:
RESOLVED FIXED
Opened:
7 years ago
Updated:
7 years ago

People

(Reporter: philor, Assigned: mats)

Tracking

({intermittent-failure})

Version:
Trunk
Target:
mozilla15
Platform:
x86
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

fix
886 bytes, patch
philor
: review+
Details | Diff | Splinter Review 
Your guess is as good as mine - could be intermittent and related to bug 575294, intermittent and unrelated, or it could be permaorange on Win PGO only and I just don't know it yet.

https://tbpl.mozilla.org/php/getParsedLog.php?id=12148097&tree=Mozilla-Inbound
Rev3 WINNT 6.1 mozilla-inbound pgo test mochitest-other on 2012-05-28 20:52:56 PDT for push 6d605438199c
slave: talos-r3-w7-074

16258 INFO TEST-START | chrome://mochitests/content/chrome/toolkit/content/tests/chrome/test_hiddenitems.xul
16259 ERROR TEST-UNEXPECTED-FAIL | chrome://mochitests/content/chrome/toolkit/content/tests/chrome/test_hiddenitems.xul | blur 10,slider - got [object XULElement], expected [object HTMLInputElement]
Intermittent, but extremely frequent, apparently.
Okay, that's scary - it wasn't intermittent, it was permanent, but it wasn't counted as a failure, so unless something else in the run failed, it showed as green - https://tbpl.mozilla.org/php/getParsedLog.php?id=12145939&tree=Mozilla-Inbound is the log for one of the "green" runs on your push. Backed out, but, how did that not count as a failure?
Summary: Intermittent test_hiddenitems.xul | blur 10,slider - got [object XULElement], expected [object HTMLInputElement] → Permanent, but intermittent counted as failure test_hiddenitems.xul | blur 10,slider - got [object XULElement], expected [object HTMLInputElement]
One possible explanation - bug 678420 was a test that failed, then navigated back in history, loading the previous test into the current test's context, hiding its failures.
Blocks: 677964
Posted patch fix — — Splinter Review 
There's a bug in the preceding test, test_focus_anons.xul - it doesn't
remove its blur event listener at the end of the test, so it depends
on the bug that part 1 in bug 575294 fixes.

https://tbpl.mozilla.org/?usebuildbot=1&tree=Try&rev=2f33cd615bac
Attachment #628103 - Flags: review?(philringnalda)
BTW, backing out was the right call.  It's really scary that we can have failures
like this and still report the test run as succeeding.  Do you know if we have a
bug open on this?
Assignee: nobody → matspal
Blocks: CVE-2012-3984
Yeah, bug 677964, though so far nobody seems to have had any ideas about it.
Comment on attachment 628103 [details] [diff] [review]
fix

lgtm
Attachment #628103 - Flags: review?(philringnalda) → review+
https://hg.mozilla.org/mozilla-central/rev/2eefd38b71f1
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.