[Webkit-unassigned] [Bug 21548] New: JavaScript key events differ between Safari app and Cocoa WebView (WebKit)

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sat Oct 11 19:20:49 PDT 2008


           Summary: JavaScript key events differ between Safari app and
                    Cocoa WebView (WebKit)
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: All
               URL: http://tlrobinson.net/misc/keypresses2.html
        OS/Version: Mac OS X 10.5
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: New Bugs
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: rboucher at gmail.com

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

Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

More information about the webkit-unassigned mailing list