Bug 21548 - JavaScript key events differ if WebKit-using app was linked against older WebKit framework
Summary: JavaScript key events differ if WebKit-using app was linked against older Web...
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 525.x (Safari 3.1)
Hardware: All OS X 10.5
: P2 Normal
Assignee: Nobody
URL: http://tlrobinson.net/misc/keypresses...
Depends on:
Reported: 2008-10-11 19:20 PDT by boucher
Modified: 2010-06-03 15:43 PDT (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description boucher 2008-10-11 19:20:49 PDT
If you download this Cocoa application: 


It contains a webview, which points to to this url:


The page at that URL will show you the events generated when any key is pressed.  If you try this with any of the arrow keys, as well as several others like delete, page up, page down, etc., you'll see that the behavior is different when visiting the URL in Safari and when using the Cocoa application.

This difference should be reconciled. Personally, I believe the technique used in the Cocoa app is the correct one, but I think WebKit changed its behavior to the new behavior seen in Safari intentionally a few months ago. Whichever way you choose, it just needs to be consistent.

In 280 Slides (and all Cappuccino apps) we have to do a WebKit version check to determine the correct behavior of keys, which while not ideal, is acceptable.  The problem arrises for any WebKit based browser that isn't Safari -- unless we specifically know about their UserAgent ahead of time, we'll expect them to use this "remedial key support" behavior, when in fact they use the older, more correct behavior.  The result is that 280 Slides sees two keypresses instead of one.
Comment 1 boucher 2008-10-11 19:30:02 PDT
I neglected to be specific about the difference, so here it is.

In the Cocoa application, keydown, keypress, and keyup are all generated. In Safari proper, only keydown and keyup are generated.
Comment 2 Mark Rowe (bdash) 2008-10-11 19:43:09 PDT
This is not a Safari vs other WebKit app difference, but a difference based on the version of WebKit that the application linked against.  The different behaviour only shows up if you link the test Cocoa application against a version of WebKit from Safari 3.0 or older (eg, against the 10.4u SDK).  It's because of the quirk that was introduced in <http://trac.webkit.org/changeset/28693>.
Comment 3 Mark Rowe (bdash) 2008-10-11 19:46:32 PDT
Alexey, do you happen to know why we decided to leave this quirk in as a linked-on-or-after check?
Comment 4 Alexey Proskuryakov 2008-10-14 03:50:12 PDT
We have added the quirk without having any specific examples of applications that depended on this (other than Safari's own RSS feed reader). But it seems quite possible that there are applications that would be affected by this change.

Is there a better check we could use?
Comment 5 Alexey Proskuryakov 2010-06-03 15:43:51 PDT
The discussion stalled, meaning that existing behavior is fine.