Summary: | JavaScript key events differ if WebKit-using app was linked against older WebKit framework | ||
---|---|---|---|
Product: | WebKit | Reporter: | boucher <rboucher> |
Component: | New Bugs | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED WONTFIX | ||
Severity: | Normal | CC: | ap, mrowe |
Priority: | P2 | ||
Version: | 525.x (Safari 3.1) | ||
Hardware: | All | ||
OS: | OS X 10.5 | ||
URL: | http://tlrobinson.net/misc/keypresses2.html |
Description
boucher
2008-10-11 19:20:49 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. 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. |