Bug 75158 – Access keys do not work for frames that are not focused

• Status: NEW
• Component: UI Events

[Cem Kocagil]

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.

[Cem Kocagil]

Created attachment 120424 [details]
Test case

[Cem Kocagil]

Created attachment 120426 [details]
Patch

[WebKit Review Bot]

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

[Cem Kocagil]

Created attachment 120439 [details]
Patch (skips the layout test)

[Cem Kocagil]

Created attachment 120449 [details]
Patch

Now with changelog; waiting to be reviewed.

[WebKit Review Bot]

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.

[Cem Kocagil]

Created attachment 120452 [details]
Patch

[Cem Kocagil]

Created attachment 120701 [details]
Patch

[Ryosuke Niwa]

Comment on attachment 120701 [details]
Patch

We can't test this?

[Ryosuke Niwa]

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.

[Alexey Proskuryakov]

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.

[Cem Kocagil]

(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.

[Alexey Proskuryakov]

Thanks.

I still feel very uneasy (security-wise) about access keys working across multiple documents.