Summary: | windowsKeyCodeForKeyEvent should be robust against NSFlagsChanged events | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | John Sullivan <sullivan> | ||||
Component: | WebKit2 | Assignee: | John Sullivan <sullivan> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | ap, darin, sam | ||||
Priority: | P2 | Keywords: | InRadar | ||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Attachments: |
|
Description
John Sullivan
2011-06-14 20:42:02 PDT
Created attachment 97227 [details]
Patch to bail out of windowsKeyCodeForKeyEvent for NSFlagsChanged events
John, is there a particular key combination that produces this exception. If so, we should consider at least documenting it here, and if possible, writing an API test for this. Don’t know of the key code that’s causing the exception, but stack traces from crashes show that it is happening. Wouldn’t a white list be better than a black list for event types? If this is reproducible, can you just post what event causes this, and a stack trace? A switch above this code seems to handle all keys that can cause NSFlagsChanged. And if it misses some, we should find out which ones, and return a proper Windows key code for these, not a zero. Actually, I see this info in Radar, and it seems like the NSEvent is somehow invalid. I don't know how an event could have key code 49808. Are we dealing with some sort of a memory consistency issue here? |