Closed
Bug 787858
Opened 12 years ago
Closed 11 years ago
XUL textbox context menu inaccessible
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
VERIFIED
FIXED
mozilla28
People
(Reporter: Jamie, Assigned: surkov)
References
(Blocks 2 open bugs)
Details
Attachments
(1 file)
(deleted),
patch
|
tbsaunde
:
review+
|
Details | Diff | Splinter Review |
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.
Updated•12 years ago
|
Blocks: Instantbird
Reporter | ||
Updated•12 years ago
|
Assignee | ||
Comment 1•12 years ago
|
||
we don't allow any children but text leafs under XUL textbox, that was caused the bug
Assignee | ||
Comment 2•11 years ago
|
||
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)
Reporter | ||
Comment 3•11 years ago
|
||
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)
Assignee | ||
Comment 4•11 years ago
|
||
(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?
Assignee | ||
Comment 5•11 years ago
|
||
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?
Reporter | ||
Comment 6•11 years ago
|
||
(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.
Assignee | ||
Comment 7•11 years ago
|
||
(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)
Assignee | ||
Comment 8•11 years ago
|
||
Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Attachment #8338755 -
Flags: review?(trev.saunders)
Comment 9•11 years ago
|
||
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?
Assignee | ||
Comment 10•11 years ago
|
||
(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
Assignee | ||
Comment 11•11 years ago
|
||
(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•11 years ago
|
||
(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.
Assignee | ||
Comment 13•11 years ago
|
||
(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•11 years ago
|
||
(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.
Assignee | ||
Comment 15•11 years ago
|
||
mm, ok, anything to fix here then?
Comment 16•11 years ago
|
||
(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.
Updated•11 years ago
|
Attachment #8338755 -
Flags: review?(trev.saunders) → review+
Assignee | ||
Comment 17•11 years ago
|
||
(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•11 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
Updated•11 years ago
|
Comment 19•11 years ago
|
||
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.
Description
•