When I write a document (https://developer.mozilla.org/en/DOM/Event/UIEvent/KeyEvent#Order_of_key_events), I found an inconsistency issue across platforms. On Windows, CapsLock, NumLock and ScrollLock don't dispatch keypress event. On Linux, CapsLock, NumLock and ScrollLock dispatch keypress event. On Mac, CapsLock dispatches only keydown event, NumLock key (without Fn key, i.e., external keyboard's NumLock key) dispatches keydown, keypress and keyup events. NumLock key with Fn key and ScrollLock key don't dispatch any key events. The CapsLock of Mac doesn't send keyup event is a limitation of platform. I'm not sure the ScrollLock on Mac. But that isn't a matter of this bug. The main issue of this bug is whether we should dispatch keypress event for these keys or not. The keys don't generate any characters, so, we shouldn't dispatch keypress event at that time. http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-type-keypress
Note that NumLock key has been obsoleted on Mac. Please ignore the NumLock issue on Mac mentioned in the comment 0.
This was completely fixed by other bugs.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Do we know when this was fixed? The documentation hasn't been updated for that fix yet.
I don't remember the actual bug#, however, currently, this is guaranteed by TextEventDispatcher class which is an XP level class to dispatch KeyboardEvent and CompositionEvent in same rules (unfortunately, Android widget still doesn't use it, bug 1137567). See also bug 1137560. # Before that, I fixed each platform's widget's behavior, though. Currently, neither modifier keys nor dead keys cause keypress event(s). https://dxr.mozilla.org/mozilla-central/rev/97a52326b06a07930216ebefa5af333271578904/widget/WidgetEventImpl.cpp#494
You need to log in before you can comment on or make changes to this bug.