Bug 13031 – [Mac] onkeydown prevents keyboard shortcuts from working on this page when the input field had focus.

• Component: Forms
• Status: NEW

[Troy Brandt]

onkeydown prevents keyboard shortcuts from working on this page when the input field had focus. 

Reduction included, when the input field has focus nothing happens when trying to use a keyboard command.

This works in Firefox, however All tested WebKits including Safari 2.0.4 (419.3) fail. This might just be bad code but I thought I'd file it since Firefox is handling it okay.

[Troy Brandt]

Created attachment 13571 [details]
Reduction

[Alexey Proskuryakov]

*** Bug 14343 has been marked as a duplicate of this bug. ***

[Alexey Proskuryakov]

See also: bug 13916.

Microsoft has some documentation about their policy on onkeydown/onkeypress event cancellation, see e.g. <http://msdn2.microsoft.com/en-us/library/ms536938.aspx>.

[Julien Chaffraix]

Created attachment 19411 [details]
First attempt (fix + manual test)

The issue is in WebHTMLView performKeyEquivalent, ret is set to YES which prevent the keyboard shortcut to work. So if WebCore has handled or cancelled the event (ret is YES), force the value to be NO but only for events with the Command flag.

[Darin Adler]

Comment on attachment 19411 [details]
First attempt (fix + manual test)

The code change does not look right to me. I need to understand more of the details of why it's necessary to both handle a key and to tell the caller that we did not handle it.

[Julien Chaffraix]

(In reply to comment #5)
> (From update of attachment 19411 [details] [edit])
> The code change does not look right to me. I need to understand more of the
> details of why it's necessary to both handle a key and to tell the caller that
> we did not handle it.
> 

The method is called directly from Cocoa and its return value will tell whether the library has to handle the key (which is the case for shortcut keys).
If we have handled it in WebCore (ret = YES) and we just return that value to Cocoa, the keyboard shortcut will never be executed (previous behaviour). This is why we have to pretend that it was not handled in WebCore.
The change is limited to the case where WebCore has handled the event and only covers event using the Command key to prevent messing with the processing of other type of event (like shift or control).

[Darin Adler]

Alexey, do you think this is correct?

[Alexey Proskuryakov]

Comment on attachment 19411 [details]
First attempt (fix + manual test)

I think that handling the key and reporting that it was not handled is OK, but it needs to be more fine-grained. Sites need to be able to override most command-key equivalents - if anything, they want more complete control than they have now.

As far as keyboard event handling goes, we aim to match IE more closely than Firefox. In IE, most Control-key shortcuts are blocked on this test page.

In addition, I think that it is really an application-level decision on which shortcuts to enforce despite site desires, so Safari needs to be changed in parallel. I'm not yet sure what the right way to achieve this would be.

[Jeff Johnson]

There are innumerable applications that use WebKit; a selection is listed at <http://trac.webkit.org/projects/webkit/wiki/Applications%20using%20WebKit>.  Are they all supposed to modify their code because a few web sites want to eat every keyboard shortcut?  How would application developers even know to do that, unless they saw this bug?  It's a WebKit implementation detail, not part of the API.

I believe that this is a platform issue as well as an application-level issue.  Mac OS X users have expectations about keyboard shortcuts, and they're going to be mad if they can't command-w or command-q, for example.  Also, users can define custom keyboard shortcuts, both system-wide and application-specific, in System Preferences.  I'm not sure that it's appropriate for 'web standards' to be the ultimate arbiter here, as if Mac OS X were just one giant web app.

[Alexey Proskuryakov]

Most of these applications are not browsers, so they really need maximum customization, and don't care about random Web pages. That said, Cmd+W and Cmd+Q should probably be exceptions (just like Ctrl+F4 and several other shortcuts are in IE and in Safari for Windows).

Furthermore, please consider that there are keyboard shortcuts that do not even use the Command key. One critically important example is Ctrl-key shortcuts used by Kotoeri input method.

> Also, users can define custom keyboard shortcuts, both system-wide and application-specific, 
> in System Preferences.

Native applications can override those, so I think that Web applications should be able to, as well.

[Alexey Proskuryakov]

Assigning to myself, as I'm going to work on a fix that involves Safari at some point in the future. Keeping this bug open for ongoing discussion.

[Jeff Johnson]

Alexey, thanks. Since you're keeping it open, I'll add some comments. Please take them as part of a friendly discussion, no animosity intended.

I think that there are some relevant differences here between native apps and web apps. We certainly don't want a web app to have all of the capabilities of a native app. For example, a native app can delete your entire home directory without asking. That's why there is more security surrounding a native app -- Mac OS X won't launch one for the first time without the user's consent. 

Note that these web apps are not actually 'overriding' the keyboard shortcuts. They're not using the shortcuts for other purposes. They're simply eating our keystrokes, perhaps unintentionally. It would be madness for a web developer to design behavior around command-key shortcuts, for example, because the web app would completely fail in many popular web browsers.

There is also the matter of user expectations. The majority of native Mac applications are designed to meet the expectations of Mac users. A native app is capable of ignoring all your keyboard shortcuts, ignoring the HIG, ignoring standard OS X behavior, but such an app will become a pariah on the platform. On the other hand, the majority of web applications are not designed to meet the expectations of Mac users. In the larger web universe, Mac users are a small minority, dwarfed by the Windows horde. Many web sites give little or no thought to Mac users, and some are even explicitly anti-Safari. This is why WebKit needs to preserve and protect the Mac experience for Mac users.

[Rene Trost]

Pressing the cursor keys doesn't fire onKeyPress in BODY in an IFRAME in WebKit r31090. This breaks enterprise web apps like TravelDesk. 

[Alexey Proskuryakov]

(In reply to comment #13)
> Pressing the cursor keys doesn't fire onKeyPress in BODY in an IFRAME in WebKit
> r31090. This breaks enterprise web apps like TravelDesk. 

Please file a new bug for this - onkeydown preventing application keyboard shortcuts is not related to arrow keys and onkeypress.

[Alexey Proskuryakov]

*** Bug 19440 has been marked as a duplicate of this bug. ***

[Jeff Johnson]

I ran across another example of this problem at <http://abcnews.go.com/Technology/AheadoftheCurve/story?id=5537944>. I was trying to use command-c to copy a line of text, but typing command-c always made it scroll to the top of the page and give me an NSBeep. I was absolutely perplexed until I remembered this bug. Then I finally figured out that as a workaround I could successfully use the "Copy" menu item instead -- which of course is labeled in the menu as having the command-c keyboard shortcut.

Mac users who try to use command-c but aren't aware of this bug will just continue to be perplexed and annoyed. Not a good user experience.

[Simone Manganelli]

Google Documents is another example of a text field intercepting Safari's keyboard shortcuts.  When composing a document, the text field is frontmost, preventing the shortcuts from working.

[Simone Manganelli]

I have to say, after reading the discussion, I agree with [e-mail] .  It's dangerous to allow web sites to override application keyboard shortcuts for their own purposes, *especially* when it's practically guaranteed that the various websites will not agree on standard keyboard shortcuts for their own apps.  I can imagine a very plausible scenario where one website would capture keyboard shortcuts but still use Command-C for copy, while another website also captures keyboard shortcuts, but uses Ctrl-C for copy instead.

Why should we allow website designers to trample all over the expected behavior and general consistency of Mac apps for their own whims?  It seems like a very bad idea.

[Simone Manganelli]

Here's another example of why this is a bad idea -- visit this page: http://www.metrolyrics.com/ive-seen-enough-lyrics-cold-war-kids.html .  This page completely disallows *any* keyboard shortcuts whatsoever, even when no input field has focus.  It eats up Cmd-R to refresh the page, Cmd-L to highlight Safari's URL field, Cmd-A to prevent select all, Cmd-C to prevent copy/paste, etc.

When I first visited this page, I really thought that Safari had hung, because none of my keyboard shortcuts were working.  It took me half a minute to figure out that I could actually still interact with Safari, just because I figured I needed to wait for Safari to un-hang.

Allowing web developers to hijack keyboard shortcuts like this is unacceptable, and worsens the user experience.  Application keyboard shortcuts should always take precedence.