466772 - No events fired on a combo box when it is closed

Status: RESOLVED INCOMPLETE

(Core :: Disability Access APIs, defect)

Description

[James Teh [:Jamie]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081121 Minefield/3.1b2pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081121 Minefield/3.1b2pre

When a combo box is closed, a state change event should be fired via accessibility APIs. When the selection is changed, a value change event should be fired. Currently, Gecko does not fire either when a user closes a combo box.

Reproducible: Always

Steps to Reproduce:
1. Move focus to a combo box. There are plenty on the Bugzilla advanced search page (https://bugzilla.mozilla.org/query.cgi).
2. Press alt+downArrow to open the combo box.
3. Change the selection.
4. Press alt+upArrow or enter to accept the selection and close the combo box.
Actual Results:  
No events are fired on the combo box.

Expected Results:  
Two events should be fired on the combo box:
* A state change should be fired to indicate that the combo box went from expanded to collapsed; and
* A value change should be fired to indicate that the selection in the combo box changed. This is the more important of the two.

Without the value change event, ATs which use virtual buffers are not notified of the change and thus the buffer is not updated.

Note that value change events are fired correctly if the user does not open the combo box before changing the selection.

Comment 1

[Aaron Leventhal]

Three kinds of combos: XUL, HTML and ARIA

Comment 2

[James Teh [:Jamie]]

I was referring to HTML combo boxes; i.e. created by the <select> tag.

Comment 3

[alexander :surkov (:asurkov)]

This is complex bug and it is valid for XUL comboboxes and autocompletes (at least concerning to expand/collapse state changes). I'll split this bug into few small bugs.

Comment 4

[alexander :surkov (:asurkov)]

Btw, bug 467057 doesn't handle expand state changes for HTML comboboxes because HTML comboboxes doesn't fire popupshown event (they fire popupshowing event). So either HTML combobxes should fire poupshown events or we should listen poupshowing event as special case for HTML comboboxes.

Comment 5

[Aaron Leventhal]

I think we used to use popupshowing but changed to popupshown. It will take some code and bug archaeology to figure out how we ended up with popupshown. It's possible that we needed layout to be ready so that we could create an accessible. However, I wonder if using the delayed event mechanism would have worked just as well.

Comment 6

[David Bolter [:davidb] (NeedInfo me for attention)]

Is this now a meta bug or will <select> events be fixed here?

Comment 7

[alexander :surkov (:asurkov)]

(In reply to comment #6)
> Is this now a meta bug or will <select> events be fixed here?

 I would say originally it had a form of meta bug. I guess if you don't want to fix the bug entirely then fire new depended sub bug.

Comment 8

[David Bolter [:davidb] (NeedInfo me for attention)]

I don't see any state change events for either opening or closing. I guess a regression?

Comment 9

[David Bolter [:davidb] (NeedInfo me for attention)]

AUTO-CLOSED. This bug untouched for over 2000 days. Please reopen if you can confirm the bug and help it progress.