475869 - Broken relationships between a combo box created with HTML <select> and its popup list under certain circumstances

Status: RESOLVED INVALID

(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.2a1pre) Gecko/20090128 Minefield/3.2a1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090128 Minefield/3.2a1pre

In Windows, the popup list which is created when a combo box is expanded has an actual hwnd. Therefore, oleacc.dll automatically inserts a ROLE_WINDOW accessible for it, which does not know its real parent. In NVDA, we must use accNavigate with NODE_CHILD_OF to get the *real* parent of the popup list; i.e. the parent in terms of the Mozilla object hierarchy. See here for a discussion on this:
http://mozilla-xp.com/news.mozilla-dev-accessibility/strange-behaviour-of-mozilla-combo-boxes-in-windows
This works very nicely in the majority of cases. However, IBM have reported an instance to us where this breaks; NODE_CHILD_OF returns nothing for the popup list.
The problematic instance is inside a Dojo dialog. I haven't yet been able to isolate this problem outside of Dojo.

Reproducible: Always

Steps to Reproduce:
1. Open the URL referenced in this bug.
2. Tab to the combo box on the page.
3. Press alt+downArrow to open it.
4. Observe that the NODE_CHILD_OF relationship on the popup list returns the combo box.
5. Shift+tab to the "Show Dialog" button and activate it.
6. Tab to the combo box in the dialog.
7. Press alt+downArrow to open it.
8. Observe that the NODE_CHILD_OF relationship on the popup list returns nothing.
Actual Results:  
The NODE_CHILD_OF relationship on the popup list activated in step 7 does not exist; it returns nothing.

Expected Results:  
The NODE_CHILD_OF relationship on the popup list activated in step 7 should return its combo box, similar to the observation for the combo box outside the dialog (step 4).

This problem causes NVDA to believe that the entire focus ancestry has changed when moving focus out of the popup list, and thus, the entire ancestry is spoken. This is obviously extremely annoying and makes usage rather difficult.

Comment 1

[James Teh [:Jamie]]

Attachment: Test case: select element with dynamic visibility style.

We've figured out how to reproduce the problem outside of a Dojo dialog. The key is the visibility style. If a <select> element has the "visibility: hidden" style and this is then changed to make it show again, the problem occurs. Steps to reproduce with this test case:
1. Open the test case.
2. Focus on the combo box.
3. Open the combo box by pressing alt+downArrow.
4. Observe that everything is normal. The child of the combo box is the popup list and the popup list's NODE_CHILD_OF points to the combo box.
5. Activate the "Hide" button. The combo box disappears.
6. Activate the "Show" button. The combo box reappears.
7. Focus on the combo box.
8. Open the combo box by pressing alt+downArrow.
9. Observe that the popup list's NODE_CHILD_OF returns nothing.
Also, we found another problem:
10. Try to get the first child of the combo box. Observe that it returns nothing.
11. Now, observe that next and previous on the items in the popup list return nothing and the parent of the items is a defunct object.

Comment 2

[James Teh [:Jamie]]

Attachment: Test case: select element with dynamic innerHTML.

A <select> element for which innerHTML is dynamically rewritten also exhibits similar problems. In this test case:
1. The first time the "populate fruit" button is pressed, the combo box is populated and all is well.
2. The second time it is pressed, the combo box returns nothing as its first child. IN addition, the popup list will not appear automatically when arrowing around as it normally does. Instead, one must explicitly press alt+downArrow.
3. The third time it is pressed, first child on the combo box returns a defunct object. Next and previous on the items in the popup list return nothing and the parent of the items is a defunct object.

These two test cases seem to indicate that when a select is repopulated or is changed from hidden to visible, the relationship between the combo box and its popup list appears to be somewhat broken in either one or both directions.

Comment 3

[James Teh [:Jamie]]

With e10s, this bug is no longer relevant, since there's now no relationship between an expanded combo box and the document at all. While that's not ideal, that's a different bug (bug 1422176, bug 1549202).