334350 - STATE_FOCUS missing on URL bar text box when it's focused

Status: RESOLVED WONTFIX

(Core :: Disability Access APIs, defect)

Description

[parente]

Text boxes in the chrome do not always have STATE_FOCUSED set when they are indeed focused. An AT cannot distinguish text events coming from a focused text control (e.g. where the user is typing) from text events coming from an unfocused text control (e.g. a status bar changing).

Comment 1

[Aaron Leventhal]

On current versions of ATK this is exposed as:
ROLE_COMBOBOX
   ROLE_IMAGE
   ROLE_IMAGE (typically not visible)
   ROLE_TEXT
   ROLE_PUSHBUTTON (typically not visible)
   ROLE_IMAGE (typically not visible)
   ROLE_PUSHBUTTON

On newer versions of ATK we have new roles -- ROLE_AUTOCOMPLETE, ROLE_EDITBAR and ROLE_ENTRY. How should we be exposing the URL bar now and what should actually get focus (an outer or inner object)?

Comment 2

[parente]

From an AT perspective, whatever accessible will be returned as the source of the text events (e.g. object:text-caret-moved, object:text-change:inserted, etc.) should have STATE_FOCUSED set. That way, the AT can just look at the event source and determine if the text event is coming from a focused control or not.

If the focused flag is set on a containing accessible instead, then the AT has to look at the event source, check its state for the focus flag, and if it's not found, start digging up through the accessible hierarchy to locate some ancestor accessible that has STATE_FOCUSED. Way too much processing.

Comment 3

[Aaron Leventhal]

Yes, the STATE_FOCUSED is a problem we're having with this. I just want to make sure that while we fix that we also fix the URL bar to use the correct new role. Part of the problem here is that the text object is embedded in the combobox. On Windows we just say the textbox is focused and use state_focused on that. As we fix this for ATK I want to understand what the structure of this thing should actually be.

I'm not really sure why we have a separate ROLE_EDITBAR vs. ROLE_ENTRY to be honest. There's no ROLE_AUTOCOMPLETEBAR, or ROLE_POPUPBAR, etc. so we do we need ROLE_EDITBAR? As far as I can tell pretty much all EDITBARS *are* autocompletes.

Comment 4

[parente]

gtk combobox widgets set STATE_FOCUSED on the text accessible within the combobox, but not on the combobox. This is the desired solution.

As for what role to use on the containing accessible, I defer to someone who can tell you exactly what each role is supposed to mean.

Comment 5

[David Bolter [:davidb] (NeedInfo me for attention)]

Aaron, you questions about the bar roles in comment #3 is interesting. I think a generic ROLE_BAR would suffice, and an object with this role could perhaps perform typical bar operations (like moving/adding/removing children). I have the feeling Bill or Janina could tell us more though.  (Perhaps worth posting to [e-mail])

Comment 6

[Aaron Leventhal]

(In reply to comment #4)
Actually it seems messed up on Gnome.

For the Alt+F2 "Run application" dialog's autocomplete, there's a ROLE_COMBOBOX with a ROLE_TEXT child.

Problems:
1) I'm getting the focus event for the ROLE_COMBOBOX, even though it doesn't have STATE_FOCUSABLE. 
2) The child ROLE_TEXT doesn't have STATE_FOCUSABLE and does not receive STATE_FOCUSED when the caret is in it. The caret moved events are in this object.

Comment 7

[parente]

Then that combo box is somehow different from the one in gtk-demo. Someone with authority needs to say how it should be done.

Comment 8

[Aaron Leventhal]

(In reply to comment #2)
> If the focused flag is set on a containing accessible instead, then the AT has
> to look at the event source, check its state for the focus flag, and if it's
> not found, start digging up through the accessible hierarchy to locate some
> ancestor accessible that has STATE_FOCUSED. Way too much processing.

You can cache that whenever focus changes or you get a new text event, and there would be ways to minimize the processing. You're going to need to look at ancestors anyway to see if the person moved into a different groupbox or pane, etc. The new section they moved to may have a label or description that needs to be spoken.

So I think the solution is that the focus event goes to the ROLE_COMBOBOX/ROLE_AUTOCOMPLETE which should get STATE_FOCUSABLE and STATE_FOCUSED. The text change events are in the child ROLE_ENTRY (which IMO is a better role to use than ROLE_TEXT).

Uou will run into a similar situation in rich text editing. I'm not sure that in a containment hierarchy that focus will actually be on the object currently being edited. At least in Mozilla focus is on the document itself. I suppose we might change this so that at least ATK things focus is on the text object being edited. I still suspect that you'll run into this again. 

Caching a parent chain when you get an event isn't that much processing, and it will probably be useful to know the context of events better.

Comment 9

[parente]

It is a lot of processing when the equals operator isn't implemented (at-spi? atk? bridge?) and you have to compare accessible properties. Plus every call to get a parent is a cross process call.

What is the advantage of setting STATE_FOCUSED on the container widget? I haven't seen why that's a better a solution.

If you do set STATE_FOCUSED on the container, how can an AT distinguish between actual input focus being on the text box versus on the drop down button versus on the drop down list?

Comment 10

[Aaron Leventhal]

> It is a lot of processing when the equals operator isn't implemented
That's too bad. How will you know when you have moved away from one groupbox into another one after the user presses tab? Isn't that a problem with ATK?

Your argument for putting focus into the ROLE_ENTRY makes sense. Are you going to walk the parent chain then so that you know whether to say it's an autocomplete or not? Or should ROLE_AUTOCOMPLETE be used on the textbox itself?

Comment 11

[parente]

> How will you know when you have moved away from one groupbox
> into another one after the user presses tab? Isn't that a problem with ATK?

Have to resort to comparison for now. I believe we have a feature request/bug report filed to get this fixed.
 
> Your argument for putting focus into the ROLE_ENTRY makes sense. Are you going
> to walk the parent chain then so that you know whether to say it's an
> autocomplete or not?

Yes. We can walk the chain if the user's verbosity settings state that they want to know contextual information. But that's just one walk when the "thing" gets focus or the user explicitly asks for the context. That's OK. What we want to avoid is a walk for every text event received to determine if the source of an event is inside something that has focus. 

(We do deviate from this preferred processing now to handle events from accessibles that are actually private children of accessibles that have STATE_MANAGES_DESCENDANTS and the selection and/or table interfaces. But that doesn't really apply here.)

> Or should ROLE_AUTOCOMPLETE be used on the textbox itself?

The text box should probably be ROLE_ENTRY or ROLE_TEXT. ROLE_AUTOCOMPLETE should probably be on the container widget like you said. 

Of course, I defer judgement to the atk/at-spi experts. I really have no idea how the roles are supposed to be applied. I haven't seen a document making those recommendations.

Comment 12

[Aaron Leventhal]

After talking with AT vendors, marking WONTFIX unless we get a clear indication of how comboboxes, editable comboboxes, autocompletes, autocomplete comboboxes are to be done across the platform. Our current behavior is managable for the AT's.