The function windowsKeyCodeForKeyEvent() in WebEventFactory.mm does not explicitly check for NSFlagsChanged events before calling -charactersIgnoringModifiers. -[NSEvent charactersIgnoringModifiers] throws an exception for NSFlagsChanged events. We should make this function avoid this possibility.
In Radar as <rdar://problem/9601436>
Created attachment 97227 [details]
Patch to bail out of windowsKeyCodeForKeyEvent for NSFlagsChanged events
Fixed in http://trac.webkit.org/changeset/88903
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?