Closed Bug 1318569 Opened 8 years ago Closed 8 years ago

Intermittent accessible/tests/browser/e10s/browser_treeupdate_imagemap.js | { image map: [ link: [ ] ] } is expected to have a child at index 0 : { link: [ ] }, original tested: [DOM node id: imgmap, role: image map, address: 0x125c14180]...

Categories

(Core :: Disability Access APIs, defect)

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

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla54
Tracking Flags:
Tracking Status
firefox52 --- disabled
firefox53 --- disabled
firefox54 --- disabled

People

(Reporter: intermittent-bug-filer, Assigned: yzen)

References

Details

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

Attachments

(2 files)

disable_a11y_intermittent.patch
(deleted), patch
gbrown
: review+
Details | Diff | Splinter Review
1318569 patch
(deleted), patch
eeejay
: review+
Details | Diff | Splinter Review
Assignee: nobody → yzenevich
Assignee: yzenevich → nobody
:jaws -- This failure started shortly after your change in https://hg.mozilla.org/mozilla-central/rev/496f18cd01fe, bug 1316135. I know it was a minor change, but could you double-check that you didn't introduce a problem?
Flags: needinfo?(jaws)
At the time of jaws' change, this test wasn't running: it wasn't enabled for e10s for another week, until https://hg.mozilla.org/integration/mozilla-inbound/rev/0371c68cb129 landed. So while it's possible that the test worked 100% of the time with the patches from bug 1270916 but intermittently fails with the changes from bug 1316135, I think it's much more likely that tbsaunde just didn't notice that although he made this test work sometimes, he didn't make it work often enough.
Blocks: 1270916
Flags: needinfo?(tbsaunde+mozbugs)
Thanks philor -- that makes more sense now.
Flags: needinfo?(jaws)
This failure is, uh, frequent; half the Mac debug tests are hitting it on a try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=021588ee3153d7f868e429e2741e0aa07c72d759
not terribly useful, but as a status update I tried to reproduce this yesterday and today under rr, but haven't had any success yet. So something is probably different between my machine and linux / mac automation.
Flags: needinfo?(tbsaunde+mozbugs)
interesting, looking at a screenshot of a failure: http://mozilla-releng-blobs.s3.amazonaws.com/blobs/mozilla-inbound/sha512/d053ca8bc6c1e70d7856952be262283eab0dea1b93a89b7c2c4a630d3fff72b4aa31514d2fc5c9c3644db4ad441357c801d44983d0e48cb69030258cfe3b82fb I see a dialog/notification in the foreground for osx: What's new in OS X Yosemite Take a tour now or view it later from the finder help menu I honestly don't know what this should look like, but I don't think a popup like that is going to help us be more accurate in our tests. Maybe this is a focus issue?
That's always there and has been since something like 10.8, so it doesn't explain it being intermittent, or only e10s.
good point :philor, I had overlooked that fact. Maybe we can get tbsaunde an osx loaner and he can try to reproduce on there. :tbsaunde, when you tried to reproduce this, did you run the entire directory of tests, or just the specific test case? Quite possibly this is related to some other test causing troubles.
Flags: needinfo?(tbsaunde+mozbugs)
I see 18 tests listed before this one in the manifest- possibly that could be related: https://dxr.mozilla.org/mozilla-central/source/accessible/tests/browser/e10s/browser.ini
I did a bunch of try pushes and running the test by itself on try (no other tests in that directory), I still get 40-50% failures on try.
:tbsaunde, would you have any objections to disabling this test for osx debug e10s?
(In reply to Joel Maher ( :jmaher) from comment #25) > :tbsaunde, would you have any objections to disabling this test for osx > debug e10s? no, and sorry about delay.
Flags: needinfo?(tbsaunde+mozbugs)
Attached patch disable_a11y_intermittent.patch (deleted) — — Splinter Review
this patch will disable this in the one scenario that is causing us frequent intermittents- I will mark this bug as leave-open so we can still keep this around.
Attachment #8821488 - Flags: review?(tbsaunde+mozbugs)
Keywords: leave-open
Whiteboard: [test-disabled]
Comment on attachment 8821488 [details] [diff] [review] disable_a11y_intermittent.patch Review of attachment 8821488 [details] [diff] [review]: ----------------------------------------------------------------- r=gbrown, if you like, since tbsaunde is likely holidaying and won't mind. :)
Attachment #8821488 - Flags: review?(tbsaunde+mozbugs) → review+
Flags: needinfo?(tbsaunde+mozbugs)
Pushed by jmaher@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/bb9b53d15183 disable browser_treeupdate_imagemap.js on OSX e10s for high intermittent. r=gbrown
This is basically permafailing on Linux since 52 was uplifted to Beta yesterday. Since we're not shipping a11y+e10s in 52 anyway, I'm inclined to just skip the test there as well, but I'm worried we'll just see the same issues again when 53 goes to Beta. We should probably work on finding a real culprit here.
(In reply to Ryan VanderMeulen [:RyanVM] from comment #40) > This is basically permafailing on Linux since 52 was uplifted to Beta > yesterday. Since we're not shipping a11y+e10s in 52 anyway, I'm inclined to > just skip the test there as well, but I'm worried we'll just see the same > issues again when 53 goes to Beta. We should probably work on finding a real > culprit here. yeah, I agree we should figure this out, but at the moment security bugs are more important I think.
Flags: needinfo?(tbsaunde+mozbugs)
Pushed by gbrown@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/3ea843fdab52 Skip browser_treeupdate_imagemap.js on e10s across all platforms; r=me
So it looks like the problem is that sometimes the accessible for the image is first created as ImageAccessible and recreated as a ImageMapAccessible, which mochitests deal with with a waitForImageMap() function, but this test doesn't appear to do the same sort of thing. SO we should probably do something like that here.
Flags: needinfo?(yzenevich)
Attached patch 1318569 patch (deleted) — — Splinter Review
Flags: needinfo?(yzenevich)
Attachment #8834485 - Flags: review?(eitan)
Comment on attachment 8834485 [details] [diff] [review] 1318569 patch Review of attachment 8834485 [details] [diff] [review]: ----------------------------------------------------------------- ::: accessible/tests/browser/e10s/browser_treeupdate_imagemap.js @@ +173,5 @@ > +function* waitForImageMap(browser, accDoc) { > + const id = 'imgmap'; > + const acc = findAccessibleChildByID(accDoc, id); > + if (acc.firstChild) { > + return; This first confused me. I forgot how generator functions worked, and what happens when you return. I guess it just means you passed all the yields. So this is fine.
Attachment #8834485 - Flags: review?(eitan) → review+
Pushed by yura.zenevich@gmail.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/c9bd66498f9c waiting for image map before running tests in browser_treeupdate_imagemap.js. r=eeejay
Assignee: nobody → yzenevich
Status: NEW → ASSIGNED
Keywords: leave-open
https://hg.mozilla.org/mozilla-central/rev/c9bd66498f9c
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
Whiteboard: [test-disabled] → [test-disabled][stockwell disabled]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: