Closed Bug 606207 Opened 14 years ago Closed 14 years ago

Dojo dropdown buttons are broken

Categories

(Core :: Disability Access APIs, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla2.0b8

People

(Reporter: surkov, Assigned: surkov)

References

()

Details

(Keywords: access, regression)

Attachments

(1 file)

regression from bug 570275. Changes in visibility state treatment makes dojo dropdown button broken. We used to fire menupopup event when menupopup accessible is created. Since we create an accessible regardless its display change but dojo operates with visibility styles then we don't fire menupopup event. The fix depends on the approach that will be taken in bug 606125.
We also have a similar problem on the classic "old" twitter. 1. Login to twitter.com. 2. Bring up someone's profile, e. g. mine http://twitter.com/MarcoInEnglish 3. There's a button inside a list item with classes "action-menu menu". Click it. It does not have an accessible name, I suppose the caption is being created by the list item's CSS class. Expected: After clicking, the items inside this construct should become visible: <div id="prototypes" style="display: none;"> <div id="action_menu" style="display: none;"> <ul class="round" style="display: block;"> ... In Firefox 3.6.12, this becomes visible just fine. Actual: In current nightly builds, the items do not appear in NVDA's virtual buffer, I have to refresh the buffer to see the elements. Note that this is not ARIA enabled, so no menupopup events are expected. But I suspect that something in the visibility styles of these nested divs and the UL confuses us now. If this is a separate issue, please tell me so I can file a new bug.
Marco, are you sure about display style? Isn't it visibility style (at least nested display styles don't make sense because display none on root cancels all display styles in subtree). If they use display style then it sounds like different issue.
Sorry, I meant the display style from the snippet above. The snippet above comes directly from the source code of a profile page in the classic Twitter interface.
(In reply to comment #3) > Sorry, I meant the display style from the snippet above. The snippet above > comes directly from the source code of a profile page in the classic Twitter > interface. Hm, the snippet code shouldn't be visible. What's the point?
It should *become* visible after clicking the button. I think a click handler or the like is being registered via JS, and JS is also used to change the display style so these items become visible. It gets inserted right after the button accessible (at least in Firefox 3.6.x). So in NVDA, I downArrow to that button, press it, and when down arrowing then, I immediately have the options available. Likewise if I press the button again, that list disappears from view again.
(In reply to comment #1) > We also have a similar problem on the classic "old" twitter. > 1. Login to twitter.com. > 2. Bring up someone's profile, e. g. mine http://twitter.com/MarcoInEnglish > 3. There's a button inside a list item with classes "action-menu menu". Click > it. It does not have an accessible name, I suppose the caption is being created > by the list item's CSS class. > Actual: In current nightly builds, the items do not appear in NVDA's virtual > buffer, I have to refresh the buffer to see the elements. > If this is a separate issue, please tell me so I can file a new bug. I can't reproduce on yesterday nightly, I can see two buttons (the first one is doubled due to some reason (button and list)), when I press enter on any button or list then items appear in vb. Marco, please file new bug if you can see it. Anyway this bug is unrelated with this one since these button don't use visibility style.
Attached patch mochitestSplinter Review
Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Attachment #491110 - Flags: review?(marco.zehe)
Comment on attachment 491110 [details] [diff] [review] mochitest >+ this.invoke = function showAlert_invoke() Nit: In this and the other place, replace "showAlert" with "showMenu". Question: Shouldn't we also test for the events that get fired when the menu is hidden, meaning closed?
(In reply to comment #8) > >+ this.invoke = function showAlert_invoke() > > Nit: In this and the other place, replace "showAlert" with "showMenu". ok, thanks > Question: Shouldn't we also test for the events that get fired when the menu is > hidden, meaning closed? we should if we would fire events :) I don't see in the code where we could fire menupopup_end event for aria menus.
Comment on attachment 491110 [details] [diff] [review] mochitest r=me with the above nit fixed. Thanks for the explanation! If at some point we'll fire menu_end events for ARIA menus, we'll add those tests then.
Attachment #491110 - Flags: review?(marco.zehe) → review+
(In reply to comment #6) > I can't reproduce on yesterday nightly, I can see two buttons (the first one is > doubled due to some reason (button and list)), when I press enter on any button > or list then items appear in vb. Marco, please file new bug if you can see it. > Anyway this bug is unrelated with this one since these button don't use > visibility style. This is actually bug 610985 I believe. I had not realized the dependency on "not the first tab", when I filed this bug and wrote the above comment. So ignore that, please.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b8
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: