356660 - element with tabindex isn't accessible via accesskey

Status: NEW

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[alexander :surkov (:asurkov)]

If xhtml element like span has @tabindex and @accesskey attributes then it's not focused when accesskey is pressed.

Comment 1

[alexander :surkov (:asurkov)]

Attachment: testcase

Comment 2

[alexander :surkov (:asurkov)]

I can assume that accesskey is not registered in nsEventStateManger.

Comment 3

[Adam Guthrie]

This is "you need to hold shift to use an access key in page content" fun, right?

Comment 4

[Adam Guthrie]

Please disregard my comment 3. I misunderstood the bug. What Alexander is saying is that the <span> gets focused when you click it, so why shouldn't it get focused when you access it via an access key? 

Comment 5

[Mats Palmgren (inactive)]

Accesskey (un)registration is scattered all over the place currently.
http://lxr.mozilla.org/seamonkey/search?string=RegUnRegAccessKey

I think we can remove all of that and instead:
  1. centralize (un)registration -or-
  2. not register accesskeys at all (as roc suggested in bug 143065)
     and instead let ESM::HandleAccessKey traverse the content tree.

I explored 1. yesterday (hacked nsGenericElement/nsXULElement::
BindToTree/UnbindFromTree/SetAttr) and I think it can be made to work -
with the fix in bug 143065 and a few additional minor changes.
I think 2. is even cleaner if it has acceptable performance.

Comment 6

[alexander :surkov (:asurkov)]

(In reply to comment #5)
> Accesskey (un)registration is scattered all over the place currently.
> http://lxr.mozilla.org/seamonkey/search?string=RegUnRegAccessKey
> 
> I think we can remove all of that and instead:
>   1. centralize (un)registration -or-
>   2. not register accesskeys at all (as roc suggested in bug 143065)
>      and instead let ESM::HandleAccessKey traverse the content tree.

I like more 1 because some elements with accesskey probably will like to set element that will be activated. For example, xul:label can do it instead of registering itself.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Should accesskeys on display:none content trigger?

Comment 8

[alexander :surkov (:asurkov)]

(In reply to comment #7)
> Should accesskeys on display:none content trigger?
> 

I guess no. At least xul code has check for this http://lxr.mozilla.org/mozilla/source/content/events/src/nsEventStateManager.cpp#1223

Comment 9

[Mats Palmgren (inactive)]

(In reply to comment #6)
> I like more 1 because some elements with accesskey probably will like to set
> element that will be activated. For example, xul:label can do it instead of
> registering itself.

I don't think labels are harder to solve for 2.
ESM already handles this today:
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/content/events/src/nsEventStateManager.cpp&rev=1.667&root=/cvsroot&mark=1194-1209#1171

or if we move the "action" code out of ESM to nsGenericElement, 
nsXULElement, nsIXTFElementWrapper as you discussed in bug 339287,
the label element's action would be to make a call to the controlled
element's action method.


(In reply to comment #7)
> Should accesskeys on display:none content trigger?

No, but I don't see a problem with having frame-less content registered
(if we choose alt. 1) - ESM should just ignore them (1 and 2).

Comment 10

[Boris Zbarsky [:bzbarsky]]

> No, but I don't see a problem with having frame-less content registered

As long as pages don't have multiple content nodes sharing an accesskey, sure.  Do XUL <wizard>s have separate documents per page?

Comment 11

[alexander :surkov (:asurkov)]

(In reply to comment #9)
> (In reply to comment #6)
> > I like more 1 because some elements with accesskey probably will like to set
> > element that will be activated. For example, xul:label can do it instead of
> > registering itself.
> 
> I don't think labels are harder to solve for 2.
> ESM already handles this today:
> http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/content/events/src/nsEventStateManager.cpp&rev=1.667&root=/cvsroot&mark=1194-1209#1171

Really I haven't big preferences. Just why should label search accessed element every time when access key is pressed?

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

If the code for searching every time is simpler, and the performance difference doesn't matter, we should do the simple thing.

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.