Closed Bug 466772 Opened 16 years ago Closed 8 years ago

No events fired on a combo box when it is closed

Categories

(Core :: Disability Access APIs, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: Jamie, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: access, Whiteboard: [auto-closed:inactivity])

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.
Keywords: access
Version: unspecified → Trunk
Three kinds of combos: XUL, HTML and ARIA
I was referring to HTML combo boxes; i.e. created by the <select> tag.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Depends on: 467057
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.
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.
Is this now a meta bug or will <select> events be fixed here?
(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.
I don't see any state change events for either opening or closing. I guess a regression?
AUTO-CLOSED. This bug untouched for over 2000 days. Please reopen if you can confirm the bug and help it progress.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
Whiteboard: [auto-closed:inactivity]
You need to log in before you can comment on or make changes to this bug.