Closed Bug 787858 Opened 7 years ago Closed 6 years ago

XUL textbox context menu inaccessible

Categories

(Core :: Disability Access APIs, defect)

x86_64
Windows 7
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla28

People

(Reporter: Jamie, Assigned: surkov)

References

(Blocks 2 open bugs)

Details

Attachments

(1 file)

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.
Blocks: xula11y
we don't allow any children but text leafs under XUL textbox, that was caused the bug
Blocks: treea11y
Jamie, if context menu will be a child of entry and thus an embedded character in entry text then would it be ok?
Flags: needinfo?(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.
Flags: needinfo?(jamie)
(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?
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?
(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.
(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)
Attached patch patchSplinter Review
Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Attachment #8338755 - Flags: review?(trev.saunders)
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?
(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
(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.
(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.
(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?
(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.
mm, ok, anything to fix here then?
(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.
Attachment #8338755 - Flags: review?(trev.saunders) → review+
(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
https://hg.mozilla.org/mozilla-central/rev/f280e995f56c
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
See Also: → 955066
Keywords: verifyme
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.
Status: RESOLVED → VERIFIED
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.