Bug 62693 – windowsKeyCodeForKeyEvent should be robust against NSFlagsChanged events

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit2

[John Sullivan]

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>

[John Sullivan]

Created attachment 97227 [details]
Patch to bail out of windowsKeyCodeForKeyEvent for NSFlagsChanged events

[John Sullivan]

Fixed in http://trac.webkit.org/changeset/88903

[Sam Weinig]

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.

[John Sullivan]

Don’t know of the key code that’s causing the exception, but stack traces from crashes show that it is happening.

[Darin Adler]

Wouldn’t a white list be better than a black list for event types?

[Alexey Proskuryakov]

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.

[Alexey Proskuryakov]

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?