Summary: | Access keys do not work for frames that are not focused | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Cem Kocagil <cem.kocagil+webkit> | ||||||||||||||
Component: | UI Events | Assignee: | Nobody <webkit-unassigned> | ||||||||||||||
Status: | NEW --- | ||||||||||||||||
Severity: | Normal | CC: | aboxhall, ap, dglazkov, rniwa, sam, webkit.review.bot | ||||||||||||||
Priority: | P2 | ||||||||||||||||
Version: | 528+ (Nightly build) | ||||||||||||||||
Hardware: | All | ||||||||||||||||
OS: | All | ||||||||||||||||
Bug Depends on: | |||||||||||||||||
Bug Blocks: | 19820 | ||||||||||||||||
Attachments: |
|
Description
Cem Kocagil
2011-12-22 19:17:14 PST
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. |