278623 - Refactor accesskey Element code

Status: NEW

(Core :: Layout, enhancement)

Description

[Mats Palmgren (inactive)]

Followup from bug 81481 comment 21:

Additional Comment #21 From Boris Zbarsky  2004-12-29 22:09 PST:
I really wish we could factor this accesskey stuff out into
nsGenericHTMLFormElement or something... right now it's handled in a mix of
content nodes and frames with code copy/pasted all over.

Additional Comment #22 From Aaron Leventhal  2005-01-03 10:31 PST:
Agree on moving all the duplicate accesskey code into a base class. Most of the
time we just need to check if an item IsFocsable() to know whether we should
support accesskey on it. We can move the accessKey property into
nsIDOMNSHTMLElement.idl, the same way we moved tabIndex there.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Again, the problem is that some of the elements don't implement accesskeys in
the node, but in the frame.  For example, text inputs do this (presumably
because the accesskey is meaningless if the frame is not existent).

Aaron, is that the right behavior for those nodes?  Or should the accesskey just
always be implemented by the node?

Comment 2

[Aaron Leventhal]

I can't see any reason not to be consistent, and either always put it in the
frame or always in the content. But maybe I'm not thinking of something.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Well... accesskeys on links, which trigger the link, make perfect sense on
content even if there is no frame.  But do we really want them to trigger then?

Accesskeys on text inputs, which focus the text input, would be a no-op when
there is no frame.  This is not to say that doing a no-op is a bad thing.

I agree that we should pick one and stick with it; the question is which one.

Comment 4

[[e-mail]]

I'd go with frames, because it seems to me that a frame is more likely to know
when it's being hidden or shown, so that we can finally register multiple access
keys in a single set of tabpanels :-)