If the element targeted by the accesskey is not in a focused frame, it doesn't get selected (tested on Chromium and Safari). IE, Firefox and Opera focus on the item. This behavior depends on port-specific code. This bug report is intended to represent the Chromium part of the problem and should block 19820. See the attachment to reproduce the bug.
Created attachment 120424 [details] Test case
Created attachment 120426 [details] Patch
Comment on attachment 120426 [details] Patch Attachment 120426 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/10939163 New failing tests: fast/dom/access-key-iframe.html
Created attachment 120439 [details] Patch (skips the layout test)
Created attachment 120449 [details] Patch Now with changelog; waiting to be reviewed.
Attachment 120449 [details] did not pass style-queue: Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'LayoutTests/ChangeLog', u'LayoutTests/plat..." exit_code: 1 LayoutTests/ChangeLog:10: Need whitespace between colon and description [changelog/filechangedescriptionwhitespace] [5] Total errors found: 1 in 4 files If any of these errors are false positives, please file a bug against check-webkit-style.
Created attachment 120452 [details] Patch
Created attachment 120701 [details] Patch
Comment on attachment 120701 [details] Patch We can't test this?
Comment on attachment 120701 [details] Patch I don't think it's right to only change the behavior of Chromium port given that all other major browsers exihit the same behavior and the code is shared in WebCore (handleAccessKey). We should modify handleAccessKey so that it'll go through all frames instead.
This looks security sensitive. What guarantees that this doesn't introduce XSS? A frame could dispatch a keyboard event to another frame this way, or it could fool a user into pressing the access key combo, triggering an action in a different origin frame.
(In reply to comment #11) > This looks security sensitive. > > What guarantees that this doesn't introduce XSS? A frame could dispatch a keyboard event to another frame this way, or it could fool a user into pressing the access key combo, triggering an action in a different origin frame. It doesn't look like dispatched events can trigger WebViewImpl::charEvent and my simple tests verified this (I'm not quite sure though). It would be strange if that was the case since it's a method of the webview itself, not the Page or a Frame. The calls to EventHandler::handleAccessKey does not send events to other frames, it only finds the element corresponding to that accesskey and invokes accessKeyAction on that element.
Thanks. I still feel very uneasy (security-wise) about access keys working across multiple documents.