Strange behaviour of Mozilla combo boxes in Windows

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Strange behaviour of Mozilla combo boxes in Windows

James Teh-2
Hi all,

There is some seemingly strange behaviour regarding Mozilla combo boxes
in Windows. I was considering filing a bug, but wanted to check that I
am not missing something first.

When a combo box is expanded, the combo box items are exposed as a list
and the list item corresponding to the selected item in the combo box is
focused. This allows item count to be announced properly, etc. However,
the parent of the list is the desktop object; i.e. it is as if it is a
top level window. Is there a reason for this? This does not seem logical
to me; the parent of the list should be the combo box with which it is
associated.

This causes problems for us in NVDA for two reasons. First, we speak
changes in the ancestors of the focus. This informs the user when he/she
is moving into a new hierarchy; e.g. moving into a new grouping.
Unfortunately, this behaviour of Mozilla combo boxes means that when
tabbing out of an expanded combo box, the entire ancestry of the object
next to receive focus is read, including the application and document
objects. Second, we use the ancestors of the focus to determine whether
it is part of the document and should thus be handled by our virtual
buffers. Due to the fact that the combo box list is not beneath the
document, exiting form filling mode does not work properly until the
user tabs out of the combo box because NVDA believes that the combo box
is not part of the document.

I also notice an inconsistency between combo boxes in web documents and
in XUL. In web documents, when a cursor key is pressed while focused on
a combo box, the list is exposed as described above, even though the
combo box was not expanded with alt+downArrow/upArrow. In this case, the
list items are invisible. This is not really a problem, but the
behaviour is different for XUL combo boxes. These are not expanded (the
list is not exposed) until explicitly expanded by the user.

Any thoughts appreciated.

Jamie

--
James Teh
Email: [hidden email]
WWW: http://www.jantrid.net/
MSN Messenger: [hidden email]
Jabber: [hidden email]
Yahoo: jcs_teh
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Strange behaviour of Mozilla combo boxes in Windows

Steve Lee-3
James Teh wrote:

> However,
>  the parent of the [combo] list is the desktop object; i.e. it is as if it is a
>  top level window. Is there a reason for this? This does not seem logical
>  to me; the parent of the list should be the combo box with which it is
>  associated.

I can't answer directly but AFAIR in Windows the popup window
containing the combo list has the desktop as its parent and it might
well be for that reason and so a11y reflects the true status.

As to why this is I really don't know. Perhaps it is related to
clipping as a window is clipped to it's parent and the combo list is
not clipped by anything except the desktop. The confusion may come
from the fact there are several parent/child relationships going on,
the visual hierarchy and the 'object' hierarchy.

--
Steve Lee
--
Open Source Assistive Technology Software
www.fullmeasure.co.uk
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Strange behaviour of Mozilla combo boxes in Windows

Aaron Leventhal-3
In reply to this post by James Teh-2
There is an actual HWND for the combo box list. oleacc.dll automatically
inserts a ROLE_WINDOW for them. We need those in the hierarchy otherwise
WindowFromAccessibleObject() breaks.

Those inserted ROLE_WINDOW objects don't know their parent. That's why
in other similar cases like frame/iframe we've implemented the
NODE_CHILD_OF relation to skip the ROLE_WINDOW object and go to the next
ancestor in the Mozilla hierarchy.

Perhaps we could fix it if Mozilla handled OBJID_WINDOW and created it's
own ROLE_WINDOW object that knows its place in the hierarchy. However, I
don't know if WindowFromAccessibleObject() would still work in that
case, and that's also not a simple fix for this stage of Firefox.

We could also use NODE_CHILD_OF again and NVDA would probably have to
check that first whenever it wants the parent.

- Aaron


James Teh wrote:

> Hi all,
>
> There is some seemingly strange behaviour regarding Mozilla combo boxes
> in Windows. I was considering filing a bug, but wanted to check that I
> am not missing something first.
>
> When a combo box is expanded, the combo box items are exposed as a list
> and the list item corresponding to the selected item in the combo box is
> focused. This allows item count to be announced properly, etc. However,
> the parent of the list is the desktop object; i.e. it is as if it is a
> top level window. Is there a reason for this? This does not seem logical
> to me; the parent of the list should be the combo box with which it is
> associated.
>
> This causes problems for us in NVDA for two reasons. First, we speak
> changes in the ancestors of the focus. This informs the user when he/she
> is moving into a new hierarchy; e.g. moving into a new grouping.
> Unfortunately, this behaviour of Mozilla combo boxes means that when
> tabbing out of an expanded combo box, the entire ancestry of the object
> next to receive focus is read, including the application and document
> objects. Second, we use the ancestors of the focus to determine whether
> it is part of the document and should thus be handled by our virtual
> buffers. Due to the fact that the combo box list is not beneath the
> document, exiting form filling mode does not work properly until the
> user tabs out of the combo box because NVDA believes that the combo box
> is not part of the document.
>
> I also notice an inconsistency between combo boxes in web documents and
> in XUL. In web documents, when a cursor key is pressed while focused on
> a combo box, the list is exposed as described above, even though the
> combo box was not expanded with alt+downArrow/upArrow. In this case, the
> list items are invisible. This is not really a problem, but the
> behaviour is different for XUL combo boxes. These are not expanded (the
> list is not exposed) until explicitly expanded by the user.
>
> Any thoughts appreciated.
>
> Jamie
>

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility