Closed Bug 537936 Opened 15 years ago Closed 14 years ago

[orange] test_events_coalescence.html | test with ID = 'hide child and then hide parent' failed. No hide event.

Categories

(Core :: Disability Access APIs, defect)

Product:
Core
Component:
Disability Access APIs
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: benjamin, Assigned: davidb)

References

Details

(Keywords: intermittent-failure, Whiteboard: [test disabled])

Orange appeared on Linux with Dao's latest push: s: moz2-linux-slave131942 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/a11y/accessible/test_events_coalescence.html | test with ID = 'hide child and then hide parent' failed. No hide event. 1943 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/a11y/accessible/test_events_coalescence.html | test with ID = 'hide child and then hide parent' failed. No reorder event. 1948 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/a11y/accessible/test_events_doc.html | [SimpleTest/SimpleTest.js, window.onerror] An error occurred - this.mEventSeq is null at chrome://mochikit/content/a11y/accessible/events.js:434 http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1262680334.1262688039.31830.gz http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1262681190.1262683745.15591.gz This appeared on the Linux Eo and Ed tests. The only two checkins in the range are: http://hg.mozilla.org/mozilla-central/rev/4f3e5df9b2cd http://hg.mozilla.org/mozilla-central/rev/8b2c716b1532
I was unable to recreate locally on Mac or Linux and Alexander couldn't recreate on Windows.
(In reply to comment #2) > You tested tip with Dao's checkins? Yes, I updated the tree before firefox build.
(In reply to comment #2) > You tested tip with Dao's checkins? Yes.
Blocks: 438871
Not sure this should block 'randomorange' since this hasn't passed on tinderboxen yet, despite passing locally. Crazy as it might sound there must be something uncovered by http://hg.mozilla.org/mozilla-central/rev/8b2c716b1532. Dao, Alexander, did you guys get anywhere this morning in triaging this over IRC? Maybe a timing issue? Our options seem to be either backout that patch, or to disable the tests. I'd be more comfortable with the latter if I could recreate this locally.
(In reply to comment #5) > Not sure this should block 'randomorange' Note that [orange] has exactly the same meaning. > Dao, Alexander, did you guys get anywhere this morning in triaging this over > IRC? Maybe a timing issue? Maybe. I'm having a hard time following what the test is exactly doing. > Our options seem to be either backout that patch, or to disable the tests. I'd > be more comfortable with the latter if I could recreate this locally. I think a backout would only make sense if we had an idea of how the landing could have broken something in this area. Without that, it seems more likely that a) the failure is bogus, because the test is fragile, or b) the failure is real, but the underlying issue was there before and got somehow uncovered now. Given the local passes, I'm leaning towards the first suspicion.
(In reply to comment #6) > (In reply to comment #5) > > Our options seem to be either backout that patch, or to disable the tests. I'd > > be more comfortable with the latter if I could recreate this locally. > > I think a backout would only make sense if we had an idea of how the landing > could have broken something in this area. This seems reasonable to me. > Without that, it seems more likely > that a) the failure is bogus, because the test is fragile, or b) the failure is > real, but the underlying issue was there before and got somehow uncovered now. > Given the local passes, I'm leaning towards the first suspicion. OK so an option is to disable the failing tests, and then hopefully recreate via tryserver so that we can fix -- Dão did you happen to do a tryserver run on that patch?
Hmm we just had a green on: OS X 10.5.2 mozilla-central test everythingelse on 2010/01/05 12:00:18 http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1262721618.1262723455.15955.gz
(In reply to comment #7) > OK so an option is to disable the failing tests, and then hopefully recreate > via tryserver so that we can fix -- Dão did you happen to do a tryserver run on > that patch? I submitted several revisions to the tryserver, but not the latest one. Also http://hg.mozilla.org/mozilla-central/rev/613b4bf6bc6f was on mozilla-central in mid-December (backed out because of a perf issue). I've never seen that failure before.
(In reply to comment #6) > (In reply to comment #5) > > Dao, Alexander, did you guys get anywhere this morning in triaging this over > > IRC? Maybe a timing issue? > > Maybe. I'm having a hard time following what the test is exactly doing. It is one of our more complicated tests that covers the generation of accessibility events, and the order of them, for cases where the DOM mutates (e.g. nodes are removed or added).
http://hg.mozilla.org/mozilla-central/rev/106fa9dc5896 -> davidb so that this doesn't get forgotten
Assignee: nobody → bolterbugz
(In reply to comment #10) > It is one of our more complicated tests that covers the generation of > accessibility events, and the order of them, for cases where the DOM mutates > (e.g. nodes are removed or added). Yeah, I get that goal, but the implementation isn't exactly straightforward.
(In reply to comment #11) > http://hg.mozilla.org/mozilla-central/rev/106fa9dc5896 > > -> davidb so that this doesn't get forgotten Fixed?
Whiteboard: [orange] → [orange][test disabled]
(In reply to comment #13) > (In reply to comment #11) > > http://hg.mozilla.org/mozilla-central/rev/106fa9dc5896 > > > > -> davidb so that this doesn't get forgotten > > Fixed? Yep, now to fix the tests themselves. The error in test_events_doc is puzzling (this.mEventSeq is null) http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1262681190.1262683745.15591.gz#err2
Re-enabled all but one test in test_events_coalesce. http://hg.mozilla.org/mozilla-central/rev/b222b5207f69
(In reply to comment #15) > Re-enabled all but one test in test_events_coalesce. > http://hg.mozilla.org/mozilla-central/rev/b222b5207f69 Not sure if this was meant to fix it or if it was a science experiment, but there are still failures. This was the build for that checkin. http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1262797359.1262800225.31652.gz OS X 10.5.2 mozilla-central test everythingelse on 2010/01/06 09:02:39
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1262798556.1262802495.24613.gz Linux mozilla-central opt test everythingelse on 2010/01/06 09:22:36
Sorry for noise -- the right test to disable: http://hg.mozilla.org/mozilla-central/rev/598d000c5e52 (Wish I could recreate this orange locally)
(In reply to comment #18) > Sorry for noise -- the right test to disable: > http://hg.mozilla.org/mozilla-central/rev/598d000c5e52 > (Wish I could recreate this orange locally) David, not sure you disabled right test. It sounds it should be hideChildNParent.
(In reply to comment #19) > (In reply to comment #18) > > Sorry for noise -- the right test to disable: > > http://hg.mozilla.org/mozilla-central/rev/598d000c5e52 > > (Wish I could recreate this orange locally) > > David, not sure you disabled right test. It sounds it should be > hideChildNParent. Yes I agree. I'm dealing with a corrupt local hg repos right now.
Sorry for the noise folks. http://hg.mozilla.org/mozilla-central/rev/50cc2fc43635 Disabling most likely test failures in bulk to reduce noise. We had a couple of different failures; hopefully this covers us and we can fine tune during a quieter tree.
After that: Eleven instances of 2167 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/a11y/accessible/test_events_coalescence.html | test with ID = 'show parent and then show child' failed. No show event. 2168 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/a11y/accessible/test_events_coalescence.html | test with ID = 'show parent and then show child' failed. No reorder event. and four instances of 2164 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/a11y/accessible/test_events_coalescence.html | test with ID = 'add child and then add parent' failed. No show event. 2165 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/a11y/accessible/test_events_coalescence.html | test with ID = 'add child and then add parent' failed. No reorder event.
http://hg.mozilla.org/mozilla-central/rev/d437e5d268e4 Yep, sigh, re-disabled the whole test file due to the new failures.
I can't recreate the failures on try server.
Situation: 1. we get the fails on the central tboxen. 2. we don't get them on local test runs. 3. we don't get them on try server test runs. cc'ing release for advice. Does central have a special config?
Note: further evidence that these tests are fragile at bug 538594 comment 4
mozilla-central builds aren't identical to the try server but they should not be hugely different. Try server does opt+refcount style unit tests, while m-c does tests on opt+codesighs and debug+refcount (linux and windows exclusively so, mac is doing all three builds for the moment). The underlying VMs are kept in sync.
test is enabled on trunk, no failures, close as worksforme
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
Whiteboard: [orange][test disabled] → [test disabled]
You need to log in before you can comment on or make changes to this bug.