[PATCH] accesskey attribute (#45788)

Dirk Mueller mueller at kde.org
Fri Jan 23 00:59:32 GMT 2004


On Thursday 22 January 2004 13:44, Lubos Lunak wrote:

>  please review the attached khtml.patch for adding support for the
> accesskey attribute. I based the searching and focusing code on the one
> used for tabbing to next element, so I hope I got it right.

the html_inlineimpl patch is okay. The other patch has a few faults: 

> -    case ATTR_ACCESSKEY:
>        // ### ignore for the moment
>         break;
>+    case ATTR_ACCESSKEY:
>+        break;

That code is entirely redundant. with your implementation, all those case 
statements you added (and which were already there) can be removed. I planned 
to add a "registerAccessKey" method to DocumentImpl thats why those place 
holders where there. 

+    // Set focus node on the document
+    m_part->xmlDocImpl()->setFocusNode(node);
+    emit m_part->nodeActivated(Node(node));
+    node->dispatchUIEvent(EventImpl::DOMACTIVATE_EVENT, 1);

I think the activation should be done before you emit the activate_d_ signal. 
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);

>  The second, more important problem I have is how to actually trigger the
> action in the HTML element.
> http://lists.w3.org/Archives/Public/www-dom/2002AprJun/0137.html makes me
> believe just dispatching DOMActivate event like the patch currently does
> should do, but it doesn't really work for most elements. As I lack any
> serious knowledge of KHTML/DOM, I have no idea if this is KHTML bug or if
> it should be done differently.

Its mostly a KHTML bug, or rather, a missing feature. 

>  PS: Who can I annoy about adding accesskey's for next/previous at
> bugs.kde.org ;) ?

cvs co bugs/template


Dirk




More information about the kfm-devel mailing list