Branch: refs/heads/webkitglib/2.54
Home: https://github.com/WebKit/WebKit
Commit: 70da7470a97f93585864227eb629f71dfd13f488
https://github.com/WebKit/WebKit/commit/70da7470a97f93585864227eb629f71dfd13f488
Author: Fujii Hironori <[email protected]>
Date: 2026-10-05 (Mon, 05 Oct 2026)
Changed paths:
M Source/WebKit/WebProcess/WebPage/glib/WebPageGLib.cpp
M Tools/TestWebKitAPI/Tests/WebKit/WKWebView/glib/TestInputMethodContext.cpp
Log Message:
-----------
Cherry-pick 322692@main (cc1692eb5646).
https://bugs.webkit.org/show_bug.cgi?id=324966
[GTK][WPE] Respect inputmode as well as type for input elements
https://bugs.webkit.org/show_bug.cgi?id=324966
Reviewed by Carlos Garcia Campos.
inputMethodStateForElement() derived the purpose of an <input> only from its
type, so <input inputmode="numeric"> reported a free-form purpose and
<input inputmode="none"> did not inhibit the on screen keyboard. It already
honored inputmode for <textarea> and contenteditable elements.
Also apply inputmode to <input> elements, as iOS does. A missing or invalid
inputmode keeps the purpose derived from the type. A password field keeps
its
purpose, because InputMethodState cannot express both, but inputmode="none"
still inhibits the on screen keyboard.
* Source/WebKit/WebProcess/WebPage/glib/WebPageGLib.cpp:
(WebKit::inputMethodStateForElement):
*
Tools/TestWebKitAPI/Tests/WebKit/WKWebView/glib/TestInputMethodContext.cpp:
(testWebKitInputMethodContextInputMode):
(beforeAll):
Canonical link: https://commits.webkit.org/322692@main
Canonical link: https://commits.webkit.org/317695.401@webkitglib/2.54
Commit: fcf76b73b72470613ca1c05c27e221b8a7ed26db
https://github.com/WebKit/WebKit/commit/fcf76b73b72470613ca1c05c27e221b8a7ed26db
Author: Simon Pena <[email protected]>
Date: 2026-10-05 (Mon, 05 Oct 2026)
Changed paths:
M Source/WebKit/UIProcess/API/glib/InputMethodFilter.cpp
M Tools/TestWebKitAPI/Tests/WebKit/WKWebView/glib/TestInputMethodContext.cpp
Log Message:
-----------
Cherry-pick 322689@main (253c954e14de).
https://bugs.webkit.org/show_bug.cgi?id=325510
[GTK][WPE] Input method caret inside the preedit is sent as a one-character
selection
https://bugs.webkit.org/show_bug.cgi?id=325510
Reviewed by Adrian Perez de Castro and Carlos Garcia Campos.
The input method reports where its caret is inside the preedit.
InputMethodFilter passed this
to Editor::setComposition as a selection one character long, not as a
caret. When the caret was
inside the preedit, the page then had a one-character selection during the
composition. With the
caret at the end of the preedit this selection did not show, because
Editor::setComposition
clamps it to the end of the composition.
Pass a length of 0, as the Cocoa ports do for a caret. Also pass 0 when the
preedit
finishes. The text is empty there, so the selection is not used, but both
calls now match.
This also changes one thing that pages can see, wherever the caret is. When
a composition starts
over text selected in the page, Editor::setComposition looks at the input
method caret. If the
caret has a length, Editor deletes the selected text as a separate step
first, and the page gets a
beforeinput event with inputType deleteByComposition. If the caret has no
length, the composition
text replaces the selected text when it is inserted, and there is no such
event. The text is the
same either way, and cancelling the composition still leaves the selected
text deleted. The new
preedit-over-selection test checks this.
Test:
Tools/TestWebKitAPI/Tests/WebKit/WKWebView/glib/TestInputMethodContext.cpp
* Source/WebKit/UIProcess/API/glib/InputMethodFilter.cpp:
(WebKit::InputMethodFilter::preeditChanged):
(WebKit::InputMethodFilter::preeditFinished):
*
Tools/TestWebKitAPI/Tests/WebKit/WKWebView/glib/TestInputMethodContext.cpp:
(testWebKitInputMethodContextPreeditCursor):
(testWebKitInputMethodContextPreeditOverSelection):
(beforeAll):
Canonical link: https://commits.webkit.org/322689@main
Canonical link: https://commits.webkit.org/317695.402@webkitglib/2.54
Commit: d742d72446469d77406fc12d7d2c5dc5409246e8
https://github.com/WebKit/WebKit/commit/d742d72446469d77406fc12d7d2c5dc5409246e8
Author: Oliver Bestmann <[email protected]>
Date: 2026-10-05 (Mon, 05 Oct 2026)
Changed paths:
M Source/WebKit/UIProcess/Launcher/glib/BubblewrapLauncher.cpp
Log Message:
-----------
Cherry-pick 322604@main (0589880f3aae).
https://bugs.webkit.org/show_bug.cgi?id=325610
[GTK][WPE] Bind /dev/dxg in the bubblewrap sandbox
https://bugs.webkit.org/show_bug.cgi?id=325610
Reviewed by Philippe Normand and Patrick Griffis.
On WSL2, Mesa's d3d12 driver talks to the GPU through /dev/dxg. The
sandbox only binds /dev/dri, so the web process fails to create a GBM
device and an EGL display, aborts, and gets restarted in a loop.
* Source/WebKit/UIProcess/Launcher/glib/BubblewrapLauncher.cpp:
(WebKit::bindOpenGL):
Canonical link: https://commits.webkit.org/322604@main
Canonical link: https://commits.webkit.org/317695.403@webkitglib/2.54
Commit: 2d883a0c1598fa1745806ae461f74e4db32b4ade
https://github.com/WebKit/WebKit/commit/2d883a0c1598fa1745806ae461f74e4db32b4ade
Author: Fujii Hironori <[email protected]>
Date: 2026-10-05 (Mon, 05 Oct 2026)
Changed paths:
M Source/WebCore/platform/graphics/skia/SkiaCompositingLayer.cpp
Log Message:
-----------
Cherry-pick 320494@main (4af7b773e279).
https://bugs.webkit.org/show_bug.cgi?id=321993
SkiaCompositingLayer: Take the last animation value after animation ended
https://bugs.webkit.org/show_bug.cgi?id=321993
Reviewed by Carlos Garcia Campos.
Take the last animation value after animation ended as well as
TextureMapperLayer does. This has no effect for web, but only for "flush
repaint" feature of WebInspector.
* Source/WebCore/platform/graphics/skia/SkiaCompositingLayer.cpp:
(WebCore::SkiaCompositingLayer::localTransform const):
(WebCore::SkiaCompositingLayer::futureLocalTransform const):
(WebCore::SkiaCompositingLayer::opacityForAnimationsState const):
(WebCore::SkiaCompositingLayer::filter const):
Canonical link: https://commits.webkit.org/320494@main
Canonical link: https://commits.webkit.org/317695.404@webkitglib/2.54
Commit: b8752aabfd96a2e1bb058c11ceb38f91a94ad8d1
https://github.com/WebKit/WebKit/commit/b8752aabfd96a2e1bb058c11ceb38f91a94ad8d1
Author: Lauro Moura <[email protected]>
Date: 2026-10-05 (Mon, 05 Oct 2026)
Changed paths:
M Source/WebKit/CMakeLists.txt
M Source/WebKit/PlatformWPE.cmake
Log Message:
-----------
Cherry-pick 322694@main (9fd8b013bb76).
https://bugs.webkit.org/show_bug.cgi?id=326282
[WPE][CMake] Link failure with ENABLE_LLVM_PROFILE_GENERATION and GNU ld:
undefined ViewGestureController symbols
https://bugs.webkit.org/show_bug.cgi?id=326282
Reviewed by Nikolas Zimmermann.
Since 314180@main, WPE generates and compiles the message receivers for
ViewGestureController and ViewGestureGeometryCollector unconditionally.
This is done to satisfy WebKit_SWIFT_INTEROP_SOURCES also pulling
UIProcess/ViewGestureController.cpp for non-Windows ports when Swift is
enabled. (Windows was excluded in 319588@main).
But, on ports that don't build these classes, like WPE, it results in
undefined references (regardless of Swift support), relying on the
linker dropping them, which might not happen in some scenarios, like
instrumented PGO builds with the bfd linker.
This commit fixes this by making WebKit_SWIFT_INTEROP_SOURCES also skip
pulling ViewGestureController for WPE, alongside making WPE not generate
the now unneeded message receivers anymore.
* Source/WebKit/CMakeLists.txt: Do not pull ViewGestureController for
WPE.
* Source/WebKit/PlatformWPE.cmake: Do not generate the ViewGesture*
message receivers.
Canonical link: https://commits.webkit.org/322694@main
Canonical link: https://commits.webkit.org/317695.405@webkitglib/2.54
Commit: db430fddc4a11be3b220a34097e5735d88107785
https://github.com/WebKit/WebKit/commit/db430fddc4a11be3b220a34097e5735d88107785
Author: Claudio Saavedra <[email protected]>
Date: 2026-10-05 (Mon, 05 Oct 2026)
Changed paths:
M Source/JavaScriptCore/API/glib/JSCCallbackFunction.cpp
Log Message:
-----------
Cherry-pick 322608@main (a7c1eda41a76).
https://bugs.webkit.org/show_bug.cgi?id=326077
REGRESSION(308608@main): [GLib] JSCCallbackFunction::construct() builds the
arguments span with the wrong size
https://bugs.webkit.org/show_bug.cgi?id=326077
Reviewed by Patrick Griffis.
The span over the JSValueRef array is sized by parameterCount, but the
array has argumentCount elements. Every access is guarded by
i < argumentCount so nothing reads past the end today, but the span claims
elements that do not exist. Size it by argumentCount, as call() does.
* Source/JavaScriptCore/API/glib/JSCCallbackFunction.cpp:
(JSC::JSCCallbackFunction::construct):
Canonical link: https://commits.webkit.org/322608@main
Canonical link: https://commits.webkit.org/317695.406@webkitglib/2.54
Compare: https://github.com/WebKit/WebKit/compare/43b70b3fd2db...db430fddc4a1
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
