490288 - menupopup_start event isn't fired for xul:button@type="menu"

Status: RESOLVED WORKSFORME

(Core :: Disability Access APIs, defect)

Description

[alexander :surkov (:asurkov)]

this stops bug 489549 due to ongoing there  test action reorg

Comment 1

[alexander :surkov (:asurkov)]

Ok, it goes from bug 428915. Marco, what is the reason we don't need to fire menupopup events for comboboxes, autocompletes and MAINLY button with menupopup?

Comment 2

[alexander :surkov (:asurkov)]

Actually, it's bug 407359. Marco, any way your comment is appretiate

Comment 3

[Marco Zehe (:MarcoZ)]

The reason why the popup events were removed from comboboxes etc. are Windows screen readers that get confused if a menu opens inside a combobox. They simply expect items to get the items presented in a list, not a menu. This was especially problematic in the awesome bar, where JAWS and Window-Eyes were not able to follow the selection when there were suggestions. Bug 407359 has a lengthy discussion about this, and also my testing results from try server builds.

Comment 4

[alexander :surkov (:asurkov)]

Ok.

1) Can you look how accessible menus of awesome bar (button@type="menu" on the left, that shows popup containing history, not depending on you typed in awesome bar) and search bar (button@type="menu" on the right, that shows list of possible search engines)?

2) How can AT know menu of button@type="menu" is shown because we fire neither popup show/hide events nor show/destroy events?

Comment 5

[Marco Zehe (:MarcoZ)]

(In reply to comment #4)
> 1) Can you look how accessible menus of awesome bar (button@type="menu" on the
> left, that shows popup containing history, not depending on you typed in
> awesome bar) and search bar (button@type="menu" on the right, that shows list
> of possible search engines)?

These are simply announced as lists, with the currently selected item being announced as "selected" by JAWS. So it sounds like the focus is going from an edit combo to a list in both cases. The menu button itself isn't tabbable, in the Awesome Bar I use down arow to open the list, in the Search field I use Alt+DownArrow to use the list of search engines.

> 2) How can AT know menu of button@type="menu" is shown because we fire neither
> popup show/hide events nor show/destroy events?

I'm actually not sure where these could actually be found being tabbable. There are a few menu buttons in color selections in the Tools/Options dialog, but these open lists IIRC, not menus.

Comment 6

[alexander :surkov (:asurkov)]

(In reply to comment #5)

> > 2) How can AT know menu of button@type="menu" is shown because we fire neither
> > popup show/hide events nor show/destroy events?
> 
> I'm actually not sure where these could actually be found being tabbable. There
> are a few menu buttons in color selections in the Tools/Options dialog, but
> these open lists IIRC, not menus.

What is open lists, and what is difference between them and menus?

Even firefox doesn't use them but they can be used somewhere else :) Therefore it's nice to know what event we should fire. Could you try please to play with xul:button@type="menu" and please compare with dojo menu buttons (http://archive.dojotoolkit.org/nightly/checkout/dijit/tests/form/test_Button.html), (7th button having "Edit" name is menu button).

Comment 7

[Marco Zehe (:MarcoZ)]

Alex, I did a test, and the items of a menupopup under a xul:button @type="menu" are indeed rendered as list items in a list box rather than a menu, whereas the dojo edit menu has a real menu associated with it.

The reason for the change from bug 407359 was that the awesome bar autocompletion would also be rendered as a menu to screen readers, but which did not contain menu items, but list items. Window-Eyes, JAWS and NVDA all did not make sense out of this, so we decided to not render these popups as menus at all. This was also one of the biggest complaints in the Firefox 2 days that the autocompletion came up as a menu, causing often unpredictable behaviour with screen readers.

The lengthy discussion and my test results are all in bug 407359.

Comment 8

[alexander :surkov (:asurkov)]

Marco, the question is do we need to do anything else to make button@type="menu" accessible? I'm ok if we shouldn't fire menupoup events for this element but I think we should fire show/hide events if popup accessible is created or invisible/visible state change if accessible is permanent.

Comment 9

[Marco Zehe (:MarcoZ)]

(In reply to comment #8)
> Marco, the question is do we need to do anything else to make
> button@type="menu" accessible? I'm ok if we shouldn't fire menupoup events for
> this element but I think we should fire show/hide events if popup accessible is
> created or invisible/visible state change if accessible is permanent.

Yes, there *is* a problem that we don't get notified if the list appears. Don't know if focus goes to the list once we press the button, but I definitely only get focus once I press DownArrow.
Agreed, we should fire those show/hide or visible/invisible events, but not menupopup.

Comment 10

[Marco Zehe (:MarcoZ)]

This is still valid in 10.0a1, and it should be fixed alongside bug 653226 when keyboard handling for this widget is fixed.

Comment 11

[James Teh [:Jamie]]

(In reply to Marco Zehe (:MarcoZ) from comment #10)
> and it should be fixed alongside bug 653226
> when keyboard handling for this widget is fixed.

Bug 653226 has been closed now, as type="menu-button" is no longer used in doorhangers. Also, this bug talks about type="menu", not type="menu-button", so I'm not sure these two are related.

type="menu" does seem to fire a menu popup start event. For example, see the "View" button in the History side bar.

Marco, has something changed here to fix this or is there a case I'm missing? Can we close this?

Comment 12

[Marco Zehe (:MarcoZ)]

I actually don't see a View button in my History side bar, only a Sort one, and that works correctly. I think we can close this.