Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: 93150ac19e1a673cbf48627a052b90cb9b7686cc
https://github.com/WebKit/WebKit/commit/93150ac19e1a673cbf48627a052b90cb9b7686cc
Author: Vitor Roriz <[email protected]>
Date: 2026-03-16 (Mon, 16 Mar 2026)
Changed paths:
M Source/WebCore/page/EventHandler.cpp
M Tools/TestWebKitAPI/Tests/ios/KeyboardInputTestsIOS.mm
Log Message:
-----------
Cherry-pick 305914@main (db4847511d66).
https://bugs.webkit.org/show_bug.cgi?id=305666
docs.google.com: Emojis don't show properly
https://bugs.webkit.org/show_bug.cgi?id=305666
rdar://122678873
Reviewed by Wenson Hsieh.
Suppress keypress events for supplementary characters to fix emoji input
Emoji with codepoints > 0xFFFF (like 🥹 U+1F979) are encoded as UTF-16
surrogate pairs. The deprecated KeyboardEvent.charCode property returns
the full 32-bit codepoint (e.g., 129401), but JavaScript's
String.fromCharCode() only uses the lower 16 bits, causing truncation
(129401 & 0xFFFF = 0xF979 = "凉", a Chinese character).
This breaks sites like Google Docs that rely on charCode to insert text.
The fix suppresses keypress events for supplementary characters
(codepoint > 0xFFFF) and manually inserts the text via Editor::insertText,
ensuring beforeinput/input events fire correctly with the proper emoji.
This matches Blink's behavior: Android Chrome routes emoji through IME
(keyCode=229) and suppresses keypress. macOS Safari's emoji picker bypasses
keyboard events entirely.
Regular characters and BMP emoji (codepoint ≤ 0xFFFF) continue to fire
keypress normally, preserving backward compatibility.
Test: Tools/TestWebKitAPI/Tests/ios/KeyboardInputTestsIOS.mm
* Source/WebCore/page/EventHandler.cpp:
(WebCore::EventHandler::internalKeyEvent):
* Tools/TestWebKitAPI/Tests/ios/KeyboardInputTestsIOS.mm:
(TestWebKitAPI::sendKeyEventWithCharacters):
(TestWebKitAPI::TEST(KeyboardInputTests,
SuppressKeypressForSupplementaryCharacterEmoji)):
(TestWebKitAPI::TEST(KeyboardInputTests,
AllowKeypressForRegularCharacters)):
(TestWebKitAPI::TEST(KeyboardInputTests, AllowKeypressForBMPEmoji)):
Canonical link: https://commits.webkit.org/305914@main
Canonical link: https://commits.webkit.org/305877.199@webkitglib/2.52
Commit: 36aa29c821db28ad03e2c92d01779a4c6e3e2f31
https://github.com/WebKit/WebKit/commit/36aa29c821db28ad03e2c92d01779a4c6e3e2f31
Author: Karl Dubost <[email protected]>
Date: 2026-03-16 (Mon, 16 Mar 2026)
Changed paths:
M
LayoutTests/fast/events/ios/key-events-comprehensive/key-events-control-expected.txt
M
LayoutTests/fast/events/ios/key-events-comprehensive/key-events-meta-control-expected.txt
M
LayoutTests/fast/events/ios/key-events-comprehensive/key-events-meta-expected.txt
M
LayoutTests/fast/events/ios/key-events-comprehensive/key-events-meta-option-expected.txt
M
LayoutTests/fast/events/ios/key-events-comprehensive/key-events-meta-shift-expected.txt
A
LayoutTests/imported/w3c/web-platform-tests/uievents/keyboard/keypress-not-fired-for-modifier-shortcuts-expected.txt
A
LayoutTests/imported/w3c/web-platform-tests/uievents/keyboard/keypress-not-fired-for-modifier-shortcuts.html
M Source/WTF/wtf/cocoa/RuntimeApplicationChecksCocoa.h
M Source/WebCore/page/EventHandler.cpp
Log Message:
-----------
Cherry-pick 309300@main (6e8432fe7c28).
https://bugs.webkit.org/show_bug.cgi?id=30397
Suppress keypress events for Meta+key and Ctrl+key shortcuts
https://bugs.webkit.org/show_bug.cgi?id=30397
rdar://4360235
Reviewed by Ryosuke Niwa, Aditya Keerthi, and Abrar Rahman Protyasha.
Per the UI Events spec (https://w3c.github.io/uievents/#keypress), keypress
should only fire for keys that produce a character value. Safari was firing
keypress for modifier shortcuts like Cmd+C and Cmd+V, unlike Chrome and
Firefox.
This caused a webcompat bug on tools.usps.com where pasting a ZIP code with
Cmd+V was blocked because the site's keypress handler saw charCode 118
('v'),
treated it as a non-digit character, and called preventDefault().
Extend shouldAvoidDispatchingKeyPressEvent in
EventHandler::internalKeyEvent to
suppress keypress dispatch when metaKey or controlKey is active. altKey is
not
suppressed because Option+key produces characters (e.g. accents).
This is also gated for the future releases to avoid any breakages for
Cocoa applications with this change of behavior, which has existed for a
long
time.
Test:
imported/w3c/web-platform-tests/uievents/keyboard/keypress-not-fired-for-modifier-shortcuts.html
*
LayoutTests/fast/events/ios/key-events-comprehensive/key-events-control-expected.txt:
*
LayoutTests/fast/events/ios/key-events-comprehensive/key-events-meta-control-expected.txt:
*
LayoutTests/fast/events/ios/key-events-comprehensive/key-events-meta-expected.txt:
*
LayoutTests/fast/events/ios/key-events-comprehensive/key-events-meta-option-expected.txt:
*
LayoutTests/fast/events/ios/key-events-comprehensive/key-events-meta-shift-expected.txt:
*
LayoutTests/imported/w3c/web-platform-tests/uievents/keyboard/keypress-not-fired-for-modifier-shortcuts-expected.txt:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/uievents/keyboard/keypress-not-fired-for-modifier-shortcuts.html:
Added.
* LayoutTests/platform/ios/TestExpectations:
We are excluding the test from iOS for now because there are issues in
the way send_keys() is (not) working on iOS. This should be fixed in a
followup tests.
* Source/WTF/wtf/cocoa/RuntimeApplicationChecksCocoa.h:
* Source/WebCore/page/EventHandler.cpp:
(WebCore::EventHandler::internalKeyEvent):
Canonical link: https://commits.webkit.org/309300@main
Canonical link: https://commits.webkit.org/305877.200@webkitglib/2.52
Commit: 3439945fe67c0e6cb551e7a283eaf5b329265f5d
https://github.com/WebKit/WebKit/commit/3439945fe67c0e6cb551e7a283eaf5b329265f5d
Author: Sosuke Suzuki <[email protected]>
Date: 2026-03-16 (Mon, 16 Mar 2026)
Changed paths:
M Source/JavaScriptCore/wasm/WasmOperations.cpp
Log Message:
-----------
Cherry-pick 309303@main (3118ca3aba21).
https://bugs.webkit.org/show_bug.cgi?id=309995
[JSC] Fix null deref in Wasm operationAllocateResultsArray on OOM
https://bugs.webkit.org/show_bug.cgi?id=309995
Reviewed by Yusuke Suzuki.
When JSArray::tryCreateUninitializedRestricted fails due to OOM,
throwOutOfMemoryError is called but we fall through and dereference
the null result in result->initializeIndex() below.
* Source/JavaScriptCore/wasm/WasmOperations.cpp:
(JSC::Wasm::JSC_DEFINE_JIT_OPERATION):
Canonical link: https://commits.webkit.org/309303@main
Canonical link: https://commits.webkit.org/305877.201@webkitglib/2.52
Commit: 130a6f78de6c8b11f8c6460739c9b039bdcdd7c2
https://github.com/WebKit/WebKit/commit/130a6f78de6c8b11f8c6460739c9b039bdcdd7c2
Author: Philippe Normand <[email protected]>
Date: 2026-03-16 (Mon, 16 Mar 2026)
Changed paths:
M Source/WebCore/platform/mediastream/gstreamer/GStreamerVideoCapturer.cpp
Log Message:
-----------
Cherry-pick 309310@main (08e322cb51cf).
https://bugs.webkit.org/show_bug.cgi?id=308928
[GStreamer][1.28]
fast/mediastream/mediastreamtrack-video-frameRate-clone-increasing.html fails
https://bugs.webkit.org/show_bug.cgi?id=308928
Reviewed by Xabier Rodriguez-Calvar.
When GStreamer 1.28 is used at runtime use videorate with its default
properties, since that works
now in live mode. The previous workaround is kept for older versions.
* Source/WebCore/platform/mediastream/gstreamer/GStreamerVideoCapturer.cpp:
(WebCore::GStreamerVideoCapturer::createConverter):
Canonical link: https://commits.webkit.org/309310@main
Canonical link: https://commits.webkit.org/305877.202@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/76d8a69fb156...130a6f78de6c
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
