Closed
Bug 606207
Opened 14 years ago
Closed 14 years ago
Dojo dropdown buttons are broken
Categories
(Core :: Disability Access APIs, defect)
Core
Disability Access APIs
Tracking
()
RESOLVED
FIXED
mozilla2.0b8
People
(Reporter: surkov, Assigned: surkov)
References
()
Details
(Keywords: access, regression)
Attachments
(1 file)
3.19 KB,
patch
|
MarcoZ
:
review+
|
Details | Diff | Splinter Review |
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.
Comment 1•14 years ago
|
||
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.
Assignee | ||
Comment 2•14 years ago
|
||
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.
Comment 3•14 years ago
|
||
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.
Assignee | ||
Comment 4•14 years ago
|
||
(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?
Comment 5•14 years ago
|
||
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.
Assignee | ||
Comment 6•14 years ago
|
||
(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.
Assignee | ||
Comment 7•14 years ago
|
||
Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Attachment #491110 -
Flags: review?(marco.zehe)
Comment 8•14 years ago
|
||
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?
Assignee | ||
Comment 9•14 years ago
|
||
(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 10•14 years ago
|
||
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+
Comment 11•14 years ago
|
||
(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.
Assignee | ||
Comment 12•14 years ago
|
||
landed on 2.0 - http://hg.mozilla.org/mozilla-central/rev/e8c6b728e90a
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.
Description
•