Closed Bug 660461 Opened 14 years ago Closed 14 years ago

ERROR TEST-UNEXPECTED-FAIL | chrome://mochitests/content/a11y/accessible/attributes/test_obj_group.xul | Can't get accessible for menu_item2.1, An error occurred - acc is null

Categories

(Core :: Disability Access APIs, defect)

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

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla8
Tracking Flags:
Tracking Status
firefox7 --- fixed

People

(Reporter: mwu, Assigned: surkov)

References

(Blocks 2 open bugs)

Details

(Keywords: intermittent-failure, Whiteboard: [qa-])

Attachments

(1 file)

patch
5.30 KB, patch
tbsaunde
: review+
christian
: approval-mozilla-aurora+
Details | Diff | Splinter Review
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1306544552.1306547991.888.gz s: talos-r3-xp-044 844 ERROR TEST-UNEXPECTED-FAIL | chrome://mochitests/content/a11y/accessible/attributes/test_obj_group.xul | Can't get accessible for menu_item2.1 845 ERROR TEST-UNEXPECTED-FAIL | chrome://mochitests/content/a11y/accessible/attributes/test_obj_group.xul | [SimpleTest/SimpleTest.js, window.onerror] An error occurred - acc is null at chrome://mochitests/content/a11y/accessible/attributes.js:43
Summary: ERROR TEST-UNEXPECTED-FAIL | chrome://mochitests/content/a11y/accessible/attributes/test_obj_group.xul | Can't get accessible for menu_item2.1 → ERROR TEST-UNEXPECTED-FAIL | chrome://mochitests/content/a11y/accessible/attributes/test_obj_group.xul | Can't get accessible for menu_item2.1, An error occurred - acc is null
Blocks: a11yrandomorange
Blocks: 650585
Attached patch patch — — Splinter Review
Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Attachment #547935 - Flags: review?(trev.saunders)
Comment on attachment 547935 [details] [diff] [review] patch why is the popup show event listener running at the wrong time? >+ this.menuNode = getNode(aID), ';' right? or does ',' do something very special? >+ this.menuNode = getNode(aID), same >+ <hbox flex="1" style="overflow: auto;"> nit, why this addition? >+ <vbox flex="1"> same
(In reply to comment #171) > Comment on attachment 547935 [details] [diff] [review] [review] > patch > > why is the popup show event listener running at the wrong time? it doesn't running at wrong time, just accessible tree creation happens async, so you can't rely on DOM events dealing with accessible tree, you should use accessible events. > >+ this.menuNode = getNode(aID), > > ';' right? or does ',' do something very special? right, nothing special > >+ <hbox flex="1" style="overflow: auto;"> > > nit, why this addition? to keep test and test results separately and allow scrolling when content exceed the window size, shortly just be able to see tests results, this construction is used through all XUL tests, except oldies like this one.
(In reply to comment #172) > (In reply to comment #171) > > Comment on attachment 547935 [details] [diff] [review] [review] [review] > > patch > > > > why is the popup show event listener running at the wrong time? > > it doesn't running at wrong time, just accessible tree creation happens > async, so you can't rely on DOM events dealing with accessible tree, you > should use accessible events. ok, fair enough, but I feel like js / xpcom should be able to get an accessible for any existing content, do you think its reasonable that thisn't the case always like this one? > to keep test and test results separately and allow scrolling when content > exceed the window size, shortly just be able to see tests results, this > construction is used through all XUL tests, except oldies like this one. ok, fair enough
Attachment #547935 - Flags: review?(trev.saunders) → review+
(In reply to comment #173) > > it doesn't running at wrong time, just accessible tree creation happens > > async, so you can't rely on DOM events dealing with accessible tree, you > > should use accessible events. > > ok, fair enough, but I feel like js / xpcom should be able to get an > accessible for any existing content, do you think its reasonable that > thisn't the case always like this one? while it may be nice but it's not big deal. Accessibility processing happens async and no way to force it to run in sync mode, 'cause it complicates the code and actually I don't see any consumers for this behavior.
landed - http://hg.mozilla.org/mozilla-central/rev/99644756e69e
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla8
Comment on attachment 547935 [details] [diff] [review] patch can we move this test to aurora (do I need approval for testing at all)?
Attachment #547935 - Flags: approval-mozilla-aurora?
Comment on attachment 547935 [details] [diff] [review] patch Approved for releases/mozilla-aurora
Attachment #547935 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Marco, can you land the patch on aurora please?
qa- for no QA verification necessary
Whiteboard: [orange] → [orange][qa-]
Whiteboard: [orange][qa-] → [qa-]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: