Bug 32213 – [Chromium] accesskey is not supported on Chromium Mac.

• Status: RESOLVED
• Resolution: FIXED
• Component: Platform

[James Su]

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.

[James Su]

Created attachment 44392 [details]
Patch to fix this issue.

[WebKit Review Bot]

style-queue ran check-webkit-style on attachment 44392 [details] without any errors.

[Darin Fisher (:fishd, Google)]

Can you construct a layout test for this using eventSender?

[James Su]

This fix is chromium specific, should I add a layout test in chromium tree?

[WebKit Commit Bot]

Comment on attachment 44392 [details]
Patch to fix this issue.

Clearing flags on attachment: 44392

Committed r51832: <http://trac.webkit.org/changeset/51832>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Eric Seidel (no email)]

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

[James Su]

There is already a layout test for access key: LayoutTests/fast/forms/access-key.html. I'll check if it works with chromium.

[Hironori Bono]

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

[Nico Weber]

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.

[Hironori Bono]

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

[James Su]

I'm investigating why the test passes on our Mac TestShell. Will give you update asap.

[James Su]

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.

[Surinder Kumar]

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