30397 2009-10-15 10:48:47 -0700 Meta + key should not fire keypress event 2026-03-15 19:57:05 -0700 1 1 1 Unclassified WebKit DOM 528+ (Nightly build) PC OS X 10.5 RESOLVED FIXED https://bugs.webkit.org/show_bug.cgi?id=185971 https://bugs.webkit.org/show_bug.cgi?id=16972 https://bugs.webkit.org/show_bug.cgi?id=28409 https://bugs.webkit.org/show_bug.cgi?id=199475 https://bugs.webkit.org/show_bug.cgi?id=208088 https://bugs.webkit.org/show_bug.cgi?id=32746 https://github.com/web-platform-tests/wpt/pull/58511 https://whsieh.github.io/examples/key-events BrowserCompat, InRadar P2 Normal --- 1 arv karlcow a_protyasha ap asevilla karlcow masayuki tony webkit-bug-importer wenson_hsieh oldest_to_newest 154844 0 arv 2009-10-15 10:48:47 -0700 The general rule is that key(s) should only fire keypress events if they generate content. Also, we are trying to match IE which dos not fire keypress events for ctrl + key (we should still fire repeating keydown events) 190369 1 tony 2010-02-14 20:17:51 -0800 (In reply to comment #0) > The general rule is that key(s) should only fire keypress events if they > generate content. Also, we are trying to match IE which dos not fire keypress > events for ctrl + key (we should still fire repeating keydown events) By meta, do you mean command on mac and the Windows key on win/linux? Or do you mean the alt/option key on mac? Using the test case on bug 28409 https://bug-28409-attachments.webkit.org/attachment.cgi?id=34993 , in Safari 4.0.4 on mac, I see a keypress fired in all cases (ctrl, alt, or command). On Chrome on mac, I see a keypress fired for only ctrl and alt (no keypress event for command). Is this bug Safari specific? 2005802 2 karlcow 2024-01-18 02:48:22 -0800 from https://www.w3.org/TR/uievents/#keypress: > If supported by a user agent, this event MUST be dispatched when a key is pressed down, if and only if that key normally produces a character value. The keypress event type is device dependent and relies on the capabilities of the input devices and how they are mapped in the operating system. 2005803 3 webkit-bug-importer 2024-01-18 02:48:30 -0800 <rdar://problem/121181035> 2005847 4 asevilla 2024-01-18 07:20:08 -0800 *** Bug 208088 has been marked as a duplicate of this bug. *** 2007021 5 a_protyasha 2024-01-23 14:54:24 -0800 (In reply to Karl Dubost from comment #2) > from https://www.w3.org/TR/uievents/#keypress: > > > If supported by a user agent, this event MUST be dispatched when a key is pressed down, if and only if that key normally produces a character value. The keypress event type is device dependent and relies on the capabilities of the input devices and how they are mapped in the operating system. "that key normally produces a character value" is a little vague because the `keypress` events are fired for, say, `V`, and not `⌘`, when a user types `⌘V` to paste something. At any rate, it seems OK for us to align our behavior with the other browser engines here and _not_ dispatch `keypress` if there is a modifier active. 2011960 6 a_protyasha 2024-02-08 15:32:47 -0800 *** Bug 185971 has been marked as a duplicate of this bug. *** 2189777 7 karlcow 2026-03-12 16:18:11 -0700 <rdar://4360235> 2189795 8 karlcow 2026-03-12 16:44:35 -0700 Pull request: https://github.com/WebKit/WebKit/pull/60520 2190456 9 ews-feeder 2026-03-15 19:48:14 -0700 Committed 309300@main (6e8432fe7c28): <https://commits.webkit.org/309300@main> Reviewed commits have been landed. Closing PR #60520 and removing active labels. 2190460 10 karlcow 2026-03-15 19:57:05 -0700 Submitted web-platform-tests pull request: https://github.com/web-platform-tests/wpt/pull/58511