423570 - Combo boxes should not have read-only state

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect, P2)

Description

[James Teh [:Jamie]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008030607 Minefield/3.0b5pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008030607 Minefield/3.0b5pre

Currently, combo boxes are exposed to IAccessible 2 with the read-only state set. This has been done to accomodate the possibility of edit combos. IN a combo box, the text cannot be edited, whereas an edit combo allows for text editing. The read-only state has been used to differentiate these two cases.

Unfortunately, while these reasons are valid, the read-only state on a combo box does not make sense for other reasons. The read-only state infers that a node cannot be changed; e.g. a read-only text node refers to a piece of static text. This is not true for combo boxes, as the value can be changed by the user, even though the content of the value itself cannot be edited. Also, it is inconsistent with all other accessibility implementations in Windows; the read-only state is never set on a combo box. Therefore, I believe that the read-only state should not be set on combo boxes.

The reason for this request is that it is useful to have a simple method to distinguish form fields from other document content. For example this is used in NVDA when jumping to the next form field. If the read-only state is not set on any form field (which would be the case except for combo boxes currently), the read-only state can be used to make this distinction, which is extremely simple, both programmatically and logically. Currently, we cannot include combo boxes when jumping to form fields because we have to handle the fact that combo boxes have the read-only state set, which would make the code extremely complicated. This would not be a problem if there was an interactive state which could be used, but this is not the case.

Reproducible: Always

Comment 1

[alexander :surkov (:asurkov)]

Since we won't expose textfield as a child for combobox accessible then we should set state readonly/editable on combobox itself, otherwise how you will get know if combobox is editable? Should we expose EXT_STATE_EDITABLE on editable comboboxes but shouldn't expose STATE_READONLY in any way?

Comment 2

[James Teh [:Jamie]]

(In reply to comment #1)
> Since we won't expose textfield as a child for combobox accessible ...
Ah. I thought that edit combos always had a child text field to allow editing? This seems to be the case in any edit combos that I have found in Mozilla apps, including the location bar. However, I must confess that i have never seen an edit combo on an actual web page. How does one create one of these so I can test?

> should set state readonly/editable on combobox itself, otherwise how you will
> get know if combobox is editable? Should we expose EXT_STATE_EDITABLE on
> editable comboboxes but shouldn't expose STATE_READONLY in any way?
This would seem to make sense to me, although perhaps Mick can comment further.

Comment 3

[alexander :surkov (:asurkov)]

(In reply to comment #2)
> (In reply to comment #1)
> > Since we won't expose textfield as a child for combobox accessible ...
> Ah. I thought that edit combos always had a child text field to allow editing?

I don't remember exactly but we shouldn't expose text leaf accessible on linux.

> This seems to be the case in any edit combos that I have found in Mozilla apps,
> including the location bar. However, I must confess that i have never seen an
> edit combo on an actual web page. How does one create one of these so I can
> test?

There is only XUL for this :) <xul:menulist editable="true"/> Though location bar is exposed as combobox but it's different widget than original xul:menulist, so they should be tested separately.

Comment 4

[Aaron Leventhal]

Now that we have IA2_STATE_EDITABLE we dont' really need STATE_SYSTEM_READONLY to differentiate. However I'm not sure if this will break existing screen readers to make this change.

Comment 5

[Marco Zehe (:MarcoZ)]

As Mick said, there are no other comboboxes in Windows that have a system_readonly state. Firefox is unique in that respect.
If the patch is easy, gimme a tryserver build. :-)

Comment 6

[Aaron Leventhal]

Attachment: No readonly state for combos

Comment 7

[Marco Zehe (:MarcoZ)]

Comment on attachment 310296 [details] [diff] [review]
No readonly state for combos

r=me. Tried a combobox on a web page, and the combobox and editcombox in Tools/Options, Main page, and all is OK.

Comment 8

[Marco Zehe (:MarcoZ)]

No negative affect on Window-Eyes. This patch is good to go in.

Comment 9

[Mike Beltzner [:beltzner, not reading bugmail]]

TM --> mozilla1.9, this won't block beta 5. If you disagree, please reset the TM to beta5 and explain why it needs to block beta.

Comment 10

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 310296 [details] [diff] [review]
No readonly state for combos

a1.9=beltzner

Comment 11

[alexander :surkov (:asurkov)]

Checking in accessible/src/html/nsHTMLSelectAccessible.cpp;
/cvsroot/mozilla/accessible/src/html/nsHTMLSelectAccessible.cpp,v  <--  nsHTMLSelectAccessible.cpp
new revision: 1.96; previous revision: 1.95
done
Checking in accessible/src/xul/nsXULSelectAccessible.cpp;
/cvsroot/mozilla/accessible/src/xul/nsXULSelectAccessible.cpp,v  <--  nsXULSelectAccessible.cpp
new revision: 1.57; previous revision: 1.56
done

Comment 12

[Marco Zehe (:MarcoZ)]

Verified fixed using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008032005 Minefield/3.0b5pre

Comment 13

[alexander :surkov (:asurkov)]

in-testsuite?