Closed Bug 352522 Opened 15 years ago Closed 15 years ago

In-page comboboxes use entry, do not show current text

Categories

(Core :: Disability Access APIs, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: parente, Assigned: aaronlev)

References

Details

(Keywords: access)

Attachments

(3 files)

Inspecting the combobox near the top of the page at http://live.gnome.org, the role hierarchy appears to be:

combobox
 -> entry (<blank>)
 -> push button ("Open")
 -> list (<blank>)
   -> list items (<named appropriately>)

Two problems/questions:

1) The entry field doesn't have a name or text indicating the currently selected list item. Is this by design because the combobox does not allow text entry? Should an AT check for the EditableText interface to make this determination? Or should the entry (or combobox) implement the Text interface always?

2) Role "entry" is a misnomer when entering text is disallowed. The role "text" would be more appropriate in the no-entry case. Is the entry box supposed to be ignored if it does not implement EditableText?

In gtk/gail, comboboxes have a child accessible with role "text" which implements the EditableText or Text interface to indicate the visible text of the current selection in the combobox.
Blocks: newatk
Keywords: access
Assignee: aaronleventhal → gaomingcn
Mike, can you work to test this and see what else it needs?

Once we inherit from nsHTMLTextFieldAccessible we should no longer need to implement nsHTMLComboboxTextFieldAccessible::GetValue() anymore. The text field's GetValue() should work. So part of this patch is to remove code we longer need by inheriting it instead. We might not need ::GetState() either if READONLY works, you'll need to test.
(In reply to comment #1)
> Created an attachment (id=240650) [edit]
> WIP -- not sure if this works or not
> 
> Mike, can you work to test this and see what else it needs?
> 
> Once we inherit from nsHTMLTextFieldAccessible we should no longer need to
> implement nsHTMLComboboxTextFieldAccessible::GetValue() anymore. The text
> field's GetValue() should work. So part of this patch is to remove code we
> longer need by inheriting it instead. We might not need ::GetState() either if
> READONLY works, you'll need to test.
> 
seems fine except nsHTMLFormControl.h should be included in the header file
read-only is only supported with INPUT and TEXTAREA. so we don't need change current GetState()
(In reply to comment #2)
> seems fine except nsHTMLFormControl.h should be included in the header file
> read-only is only supported with INPUT and TEXTAREA. so we don't need change
> current GetState()
> 

Do you mean nsHTMLFormControlAccessible.h? Is it not already there?

Yes, if we remove GetState() also, it will become "EDITABLE". But "READONLY" is not listed in the states field of at-poke, is this by design?
> Yes, if we remove GetState() also, it will become "EDITABLE". But "READONLY" is
> not listed in the states field of at-poke, is this by design?

I believe things that aren't STATE_EDITABLE are considered read-only. There is no   read only state. 
(In reply to comment #0)
 
> 2) Role "entry" is a misnomer when entering text is disallowed. The role "text"
> would be more appropriate in the no-entry case. Is the entry box supposed to be
> ignored if it does not implement EditableText?
> 

What is the no-entry case? I am not very sure about this.
(In reply to comment #5)
> 
> What is the no-entry case? I am not very sure about this.
> 

Should combobox in html alway be no-entry?

Maybe we should keep GetRole() and Change it to TEXT.
Attachment #242179 - Flags: review?(aaronleventhal)
Comment on attachment 242179 [details] [diff] [review]
keep GetRole() and change the role to TEXT.

See comment 1. Why didn't you change the inheritance, but still got rid of GetValue()?
> Once we inherit from nsHTMLTextFieldAccessible we should no longer need to
> implement nsHTMLComboboxTextFieldAccessible::GetValue() anymore. 

Have you tested this patch to see if text is now exposed?
Attachment #242179 - Flags: review?(aaronleventhal) → review-
At the face to face we decided ROLE_ENTRY does make sense for the entry field in the combo box.
Assignee: gaomingcn → aaronleventhal
Status: NEW → ASSIGNED
Attachment #243511 - Flags: review?(ginn.chen)
Attachment #243511 - Flags: review?(ginn.chen) → review+
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
is this testable from JS?
You need to log in before you can comment on or make changes to this bug.