If you download this Cocoa application: http://cappuccino.org/files/WebTest.zip It contains a webview, which points to to this url: http://tlrobinson.net/misc/keypresses2.html 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.
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.
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>.
Alexey, do you happen to know why we decided to leave this quirk in as a linked-on-or-after check?
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?
The discussion stalled, meaning that existing behavior is fine.