[PATCH] accesskey attribute (#45788)

[Lubos Lunak]

On Monday 26 of January 2004 06:05, Dirk Mueller wrote:
> On Friday 23 January 2004 17:04, Lubos Lunak wrote:

 So, now it should be right hopefully. I've split the changes to 3 patches, so 
that the changes I'm not quite sure about are independent from the main 
accesskey code.

 The main code is in khtml.patch. It's fairly simple, every accesskey is 
translated to click() - Mozilla does it the same way, and this ensures that 
onclick handlers are called. In fact, the old event handling translated some 
of the keyevents to clicks too.

 The status of various elements:
- BUTTON doesn't work - I noticed its support is quite bad in general in KHTML
- LABEL and LEGEND don't work
- TEXTAREA works, but accesskeys don't work when it's focused
- INPUT - only buttons (including submit/reset) and lineedits work
- A, AREA work
- there's code in KHTML that suggests support for accesskey in SELECT was 
planned too (HTMLSelectElementImpl::parseAttribute()), but I don't see it in 
HTML docs, even though it makes sense !?

> > > Furthermore, setFocusNode can trigger something that makes 
> > > NodeImpl* node point to garbage, you don't want that to happen. To fix,
> > > make a Node guard, like
> > >
> > > Node focusguard(node);
> > > m_part->xmlDocImpl()->setFocusNode(node);
> > > ...
> > > emit m_part->nodeActivated(focusguard);
> >  So in other words, KHTMLView::focusNextPrevNode() has this broken as
> > well.
>
> Yes.

 khtmlview.cpp.patch . I hope it's right.

 These two patches are IMHO safe enough to be backported.

>
> >  Is it documented somewhere how this should work? The best docs I could
> > find only explained what the event is, but not when it's generated and so
> > on. I e.g. noticed that if I do <form ...><input type="submit"
> > onclick="alert('kuk')" accesskey=s></form> , clicking or pressing Space
> > on the button shows the alert, by my implementation of accesskey doesn't
> > trigger it (it's triggered in Mozilla).
>
> Well, normally when you click on an element, and it receives the event
> during the capturing phase, it will decide if it can handle the event. that
> means, the element can handle it, is not disabled or anything that would
> prevent event handling.
>
> When the click activates the element, a domactivate event is emitted. event
> listeners can react to that event, and can even block it. if the element
> receives its domactivate event, it does its default action (in case of a
> link, go to the url).
>
> so its a slight mistake for an anchor to react on a click event. instead it
> should produce a activation event, and then react on that one. Feel free to
> fix.

 html_formimpl.cpp.patch - INPUT elements perform the action in activate(), 
key events are transformed to clicks, clicks are transformed to domactivate 
events. I hope I got it right, because it's mostly reshuffling of the stuff, 
but I'm far from being 100% sure about it.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: khtml.patch
Type: text/x-diff
Size: 9217 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20040311/4b185591/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: khtmlview.cpp.patch
Type: text/x-diff
Size: 1029 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20040311/4b185591/attachment-0001.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: html_formimpl.cpp.patch
Type: text/x-diff
Size: 4084 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20040311/4b185591/attachment-0002.patch>