Bug 13031 - [Mac] onkeydown prevents keyboard shortcuts from working on this page when the input field had focus.
Summary: [Mac] onkeydown prevents keyboard shortcuts from working on this page when th...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: 523.x (Safari 3)
Hardware: Macintosh OS X 10.4
: P2 Normal
Assignee: Alexey Proskuryakov
URL: https://www.cingular.com/olam/loginAc...
Keywords:
: 14343 19440 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-03-09 17:29 PST by Troy Brandt
Modified: 2010-06-10 17:45 PDT (History)
7 users (show)

See Also:


Attachments
Reduction (1.71 KB, text/html)
2007-03-09 17:30 PST, Troy Brandt
no flags Details
First attempt (fix + manual test) (3.55 KB, patch)
2008-02-27 15:09 PST, Julien Chaffraix
ap: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Troy Brandt 2007-03-09 17:29:45 PST
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.
Comment 1 Troy Brandt 2007-03-09 17:30:40 PST
Created attachment 13571 [details]
Reduction
Comment 2 Alexey Proskuryakov 2007-06-24 01:22:39 PDT
*** Bug 14343 has been marked as a duplicate of this bug. ***
Comment 3 Alexey Proskuryakov 2007-06-24 01:26:39 PDT
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>.
Comment 4 Julien Chaffraix 2008-02-27 15:09:01 PST
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.
Comment 5 Darin Adler 2008-02-29 10:10:10 PST
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.
Comment 6 Julien Chaffraix 2008-02-29 15:45:08 PST
(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).
Comment 7 Darin Adler 2008-03-02 18:45:58 PST
Alexey, do you think this is correct?
Comment 8 Alexey Proskuryakov 2008-03-03 06:35:50 PST
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.
Comment 9 opendarwin 2008-03-03 15:55:18 PST
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.
Comment 10 Alexey Proskuryakov 2008-03-03 23:11:03 PST
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.
Comment 11 Alexey Proskuryakov 2008-03-05 08:28:50 PST
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.
Comment 12 opendarwin 2008-03-05 18:42:49 PST
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.
Comment 13 Rene Trost 2008-03-17 13:28:36 PDT
Pressing the cursor keys doesn't fire onKeyPress in BODY in an IFRAME in WebKit r31090. This breaks enterprise web apps like TravelDesk. 

Comment 14 Alexey Proskuryakov 2008-03-17 13:41:19 PDT
(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.
Comment 15 Alexey Proskuryakov 2008-06-09 20:34:46 PDT
*** Bug 19440 has been marked as a duplicate of this bug. ***
Comment 16 opendarwin 2008-08-12 23:07:46 PDT
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.
Comment 17 Simone Manganelli 2009-02-01 22:39:25 PST
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.
Comment 18 Simone Manganelli 2009-02-02 00:07:02 PST
I have to say, after reading the discussion, I agree with opendarwin@lapcatsoftware.com .  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.
Comment 19 Simone Manganelli 2009-07-01 18:05:52 PDT
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.