See chromium issue: http://crbug.com/23221 URLs (if applicable) : http://djmitche.github.com/buildbot/docs/0.7.11/ OS version : 10.5.8 Behavior in Safari 3.x/4.x (if applicable): Correct (use ctrl+alt) Behavior in Firefox 3.x (if applicable): Correct (use ctrl) Behavior in Chrome for Windows: Correct (use alt or shift+alt) What steps will reproduce the problem? 1. Open above URL. 2. Press ctrl+alt+# (1 to 9) in the webpage. 3. What is the expected result? Jumps to corresponding section. eg. ctrl+alt+1 to introduction, ctrl+alt+2 to installation, etc. What happens instead? Nothing happens.
Created attachment 44392 [details] Patch to fix this issue.
style-queue ran check-webkit-style on attachment 44392 [details] without any errors.
Can you construct a layout test for this using eventSender?
This fix is chromium specific, should I add a layout test in chromium tree?
Comment on attachment 44392 [details] Patch to fix this issue. Clearing flags on attachment: 44392 Committed r51832: <http://trac.webkit.org/changeset/51832>
All reviewed patches have been landed. Closing bug.
Since chromium tests are eventually moving into svn.webkit.org I'm not sure why the test wouldn't just go there. I guess since the chromium test results aren't in svn.webkit.org yet, maybe it makes sense to just put it in svn.chromium.org for now...
There is already a layout test for access key: LayoutTests/fast/forms/access-key.html. I'll check if it works with chromium.
(In reply to comment #8) > There is already a layout test for access key: > LayoutTests/fast/forms/access-key.html. I'll check if it works with chromium. This test has been passing on our Mac test_shell with or without this change. So, I think we need another test that fails without this change but passes with this change, right? Nevertheless, I'm not a WebKit guru and I may be wrong.
WebKit tests are executed using testshell. To test for this patch, we need to test the plumbing between chrome and webkit, which can't be done with a layout test (at least not until we run layout tests using chrome, which is currently not planned i believe). This would have to be tested in a browser test as far as I understand.
(In reply to comment #10) > WebKit tests are executed using testshell. To test for this patch, we need to > test the plumbing between chrome and webkit, which can't be done with a layout > test (at least not until we run layout tests using chrome, which is currently > not planned i believe). I'm afraid I don't think so. Our EventSendingController calls WebViewImpl::handleInputEvent() to send a key event. So, if we add a new modifier string "systemKey" so eventSender.keyDown() can manually set/reset the isSystemKey value of a WebInputEvent, I think we can write a new layout test that fails without this change but passes with this change. That is, we need to change DumpRenderTree of WebKit as well as our test_shell. I sometimes changes DumpRenderTree (or TestShell) to write layout tests for such cases. Am I doing something wrong?
I'm investigating why the test passes on our Mac TestShell. Will give you update asap.
Ok, it's a bug of chromium's test_shell, which wrongly marks keys with ctrl+alt modifiers as system keys. It's correct on Windows and Linux, but not Mac. I'll submit a CL to fix it.
Hi All, I am using Webkit5.8 with annulen webkit5.212.1 Mac OS X Yosemite 10.10.2 I am still experiencing issues with accesskeys not working. The last comment of this post is dated "2009-12-09 00:39:57 PST". So i guess this issue would have been resolved. Can someone please clarify whether this issue is fixed or not with latest Webkit version? If it is still not fixed. Any workaround or patch for the same will be helpful Thanks, Surinder