787858 - XUL textbox context menu inaccessible

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect)

Description

[James Teh [:Jamie]]

The context menu for XUL textbox controls does not fire any accessibility events. I don't think it exposes any accessibles at all, but I'm not certain of this.

Str:
1. Visit about:config
2. Focus the Search textbox (@id="textbox").
3. Press the Applications key or shift+f10.
Expected: The context menu should appear and appropriate accessibility events should be fired.
Actual: The context menu appears, but no accessibility events are fired.
4. Press down arrow.
Expected: The first menu item should be focused and appropriate accessibility events should be fired. The textbox accessible should lose its focused state.
Actual: The first menu item is focused, but no accessibility events are fired. The textbox accessible retains its focused state.

My testing reveals that this bug has existed since at least Firefox 3.6.

Comment 1

[alexander :surkov (:asurkov)]

we don't allow any children but text leafs under XUL textbox, that was caused the bug

Comment 2

[alexander :surkov (:asurkov)]

Jamie, if context menu will be a child of entry and thus an embedded character in entry text then would it be ok?

Comment 3

[James Teh [:Jamie]]

Do you mean it would be an embedded object only while the menu is open or always? If only while the menu is open, that's fine. If you mean always, that may cause ATs to try to traverse the object, which is not ideal. Where would it appear in the text? It most definitely shouldn't be reachable with the caret and shouldn't ever be included in any unit offsets (e.g. line/word) associated with the caret.

Comment 4

[alexander :surkov (:asurkov)]

(In reply to James Teh [:Jamie] from comment #3)
> Do you mean it would be an embedded object only while the menu is open or
> always? If only while the menu is open, that's fine. If you mean always,
> that may cause ATs to try to traverse the object, which is not ideal. Where
> would it appear in the text? It most definitely shouldn't be reachable with
> the caret and shouldn't ever be included in any unit offsets (e.g.
> line/word) associated with the caret.

always, if it wasn't presented in text at all but it'd be a child then would it be better solution?

Comment 5

[alexander :surkov (:asurkov)]

Another possible solution is to make XUL textbox having the hierarchy:

section (XUL:textbox)
  menupopup
  entry (HTML:input)

Having an extra section is not a problem for AT, right?

Comment 6

[James Teh [:Jamie]]

(In reply to alexander :surkov from comment #4)
> > Do you mean it would be an embedded object only while the menu is open or
> > always?
> always
So what happens if you examine the object while the menu is closed? Wouldn't it be invisible? I didn't think Gecko usually included invisibles in the object hierarchy.

> if it wasn't presented in text at all but it'd be a child then would
> it be better solution?
That should be fine.

(In reply to alexander :surkov from comment #5)
> Another possible solution is to make XUL textbox having the hierarchy:
> section (XUL:textbox)
>   menupopup
>   entry (HTML:input)
> Having an extra section is not a problem for AT, right?
That's fine. I think I'd prefer this personally, but the other option is also okay.

Comment 7

[alexander :surkov (:asurkov)]

(In reply to James Teh [:Jamie] from comment #6)
> (In reply to alexander :surkov from comment #4)
> > > Do you mean it would be an embedded object only while the menu is open or
> > > always?
> > always
> So what happens if you examine the object while the menu is closed? 

It'd be

entry
  menupopup
  text leaf

> Wouldn't
> it be invisible? I didn't think Gecko usually included invisibles in the
> object hierarchy.

yes but not in case of menus, once they were shown they are in hierarchy

> (In reply to alexander :surkov from comment #5)
> > Another possible solution is to make XUL textbox having the hierarchy:
> > section (XUL:textbox)
> >   menupopup
> >   entry (HTML:input)
> > Having an extra section is not a problem for AT, right?
> That's fine. I think I'd prefer this personally, but the other option is
> also okay.

me too, it should be plain and easy solution (simpler logic => less bugs)

Comment 8

[alexander :surkov (:asurkov)]

Attachment: patch

Comment 9

[Trevor Saunders (:tbsaunde)]

So, some reason to do the XULWidgetElm() thing instead of standard widgets interface?

I assume all the test changes are because of the weird stuff on XULTextBox going away?

Comment 10

[alexander :surkov (:asurkov)]

(In reply to Trevor Saunders (:tbsaunde) from comment #9)
> So, some reason to do the XULWidgetElm() thing instead of standard widgets
> interface?

it makes sense (let me see if it works nice), originally I tried the approach of inaccessible XUL textbox element.

> I assume all the test changes are because of the weird stuff on XULTextBox
> going away?

right

Comment 11

[alexander :surkov (:asurkov)]

(In reply to alexander :surkov from comment #10)
> (In reply to Trevor Saunders (:tbsaunde) from comment #9)
> > So, some reason to do the XULWidgetElm() thing instead of standard widgets
> > interface?
> 
> it makes sense (let me see if it works nice), originally I tried the
> approach of inaccessible XUL textbox element.

on the other hand, XUL textbox element is a simple container. It doesn't manage the focus of internal HTML input accessible, so Widget interface is not too right.

Comment 12

[Trevor Saunders (:tbsaunde)]

(In reply to alexander :surkov from comment #11)
> (In reply to alexander :surkov from comment #10)
> > (In reply to Trevor Saunders (:tbsaunde) from comment #9)
> > > So, some reason to do the XULWidgetElm() thing instead of standard widgets
> > > interface?
> > 
> > it makes sense (let me see if it works nice), originally I tried the
> > approach of inaccessible XUL textbox element.
> 
> on the other hand, XUL textbox element is a simple container. It doesn't
> manage the focus of internal HTML input accessible, so Widget interface is
> not too right.

I wonder how much that should be true.  It seems to me even if html input handles focus all the accessibles are still sort of one thing although integrating menu with text box maybe not.  Either way the name stuff seems pretty hacky.

Comment 13

[alexander :surkov (:asurkov)]

(In reply to Trevor Saunders (:tbsaunde) from comment #12)

> I wonder how much that should be true.  It seems to me even if html input
> handles focus all the accessibles are still sort of one thing although
> integrating menu with text box maybe not.  Either way the name stuff seems
> pretty hacky.

when we have autocomplete role and entry under it then we say it's a widget, if we have section (XUL:textbox) and entry under it (HTML:input) then it's not so much widget. Thus I wouldn't jump into Widget interface implementation (especially taking into account the container may be excepted to implement some methods).

I'm fine to rename it to anything you'd like more though. Suggestions?

Comment 14

[Trevor Saunders (:tbsaunde)]

(In reply to alexander :surkov from comment #13)
> (In reply to Trevor Saunders (:tbsaunde) from comment #12)
> 
> > I wonder how much that should be true.  It seems to me even if html input
> > handles focus all the accessibles are still sort of one thing although
> > integrating menu with text box maybe not.  Either way the name stuff seems
> > pretty hacky.
> 
> when we have autocomplete role and entry under it then we say it's a widget,
> if we have section (XUL:textbox) and entry under it (HTML:input) then it's
> not so much widget. Thus I wouldn't jump into Widget interface
> implementation (especially taking into account the container may be excepted
> to implement some methods).

yeah I guess that's reasonable.

> I'm fine to rename it to anything you'd like more though. Suggestions?

the name isn't really what I dislike, its more the changes to name calculation as a whole, but I don't really have a proposal that doesn't mean doing more work for no real purpose.

Comment 15

[alexander :surkov (:asurkov)]

mm, ok, anything to fix here then?

Comment 16

[Trevor Saunders (:tbsaunde)]

(In reply to alexander :surkov from comment #15)
> mm, ok, anything to fix here then?

I guess not if you don't have nicer idea.

Comment 17

[alexander :surkov (:asurkov)]

(In reply to Trevor Saunders (:tbsaunde) from comment #16)
> (In reply to alexander :surkov from comment #15)
> > mm, ok, anything to fix here then?
> 
> I guess not if you don't have nicer idea.

probably not this time

Comment 18

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/f280e995f56c

Comment 19

[Bogdan Maris, Desktop QA]

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0		

Reproduced the initial issue on a nightly from 2012-09-02 and verified that the issue is fixed in latest Aurora 28.0a2.