Branch: refs/heads/webkitglib/2.54
Home: https://github.com/WebKit/WebKit
Commit: de7ec7afbe612595ec2c61aea9a587bc2debee4c
https://github.com/WebKit/WebKit/commit/de7ec7afbe612595ec2c61aea9a587bc2debee4c
Author: Nikolas Zimmermann <[email protected]>
Date: 2026-10-02 (Fri, 02 Oct 2026)
Changed paths:
M Source/WebKit/UIProcess/API/wpe/WPEWebViewLegacy.cpp
M Source/WebKit/UIProcess/glib/DisplayVBlankMonitorDRM.cpp
Log Message:
-----------
Cherry-pick 322562@main (814cfe09a43c).
https://bugs.webkit.org/show_bug.cgi?id=326120
[WPE] Restore DRM vblank monitor support for the legacy API
https://bugs.webkit.org/show_bug.cgi?id=326120
Reviewed by Alejandro G. Castro.
The DRM vblank monitor was added for WPE in 268722@main. It stopped
working for the legacy API due to two regressions:
1. 274136@main made DisplayVBlankMonitor::create() fall back to the timer
for display ID 0. The legacy view never sets a display ID, so it always
got the timer since then. Assign a fixed non-zero display ID when creating
the page, so that we get a chance to create the DRM vlank monitor.
2. 303781@main changed the connector loop in the WPE findCrtc() to declare
a new local variable instead of assigning the outer one - shadowing the
outer one -> findCrtc() always failed and a matching connector was leaked.
This went unnoticed because the code was no longer reachable...
With both fixed, the legacy API is driven by the DRM vblank monitor
again instead of a 60 fps timer - and we should be able to handle
non-60 Hz display refresh rates again, even with the legacy API.
* Source/WebKit/UIProcess/API/wpe/WPEWebViewLegacy.cpp:
(WKWPE::ViewLegacy::ViewLegacy):
* Source/WebKit/UIProcess/glib/DisplayVBlankMonitorDRM.cpp:
(WebKit::findCrtc):
Canonical link: https://commits.webkit.org/322562@main
Canonical link: https://commits.webkit.org/317695.393@webkitglib/2.54
Commit: cb3c2c962f053422376aff79963ef773cb0edb16
https://github.com/WebKit/WebKit/commit/cb3c2c962f053422376aff79963ef773cb0edb16
Author: Simon Pena <[email protected]>
Date: 2026-10-02 (Fri, 02 Oct 2026)
Changed paths:
M Tools/TestWebKitAPI/Tests/WebKit/WKWebView/glib/TestInputMethodContext.cpp
Log Message:
-----------
Cherry-pick 322053@main (978866cd7f3e).
https://bugs.webkit.org/show_bug.cgi?id=324703
[GTK][WPE] TestInputMethodContext cannot observe the cursor area,
notification counts or the preedit caret offset
https://bugs.webkit.org/show_bug.cgi?id=324703
Reviewed by Adrian Perez de Castro.
The mock WebKitInputMethodContext that the input method API tests share
cannot observe several
things an input method depends on, so:
- Implement notify_cursor_area in the mock and record the rectangle and a
call count.
- Add a settable preedit caret offset, defaulting to the end of the preedit
so the existing
tests are unaffected.
- Count focus-in, focus-out, cursor area and surrounding notifications, and
content type
notifications.
- Add waitForCursorAreaCount(), which waits for a given number of cursor
area notifications,
in the same shape as the existing waitForSurroundingText().
- Add editableSelectionStart(), which reads the selection start of the
editable element.
- Split waitUntilInputMethodEnabled() and waitUntilInputMethodDisabled()
out of
focusEditableAndWaitUntilInputMethodEnabled() and
unfocusEditableAndWaitUntilInputMethodDisabled(), so a test can focus an
element by clicking
it, or blur an element other than the one those two hardcode. No
behaviour change.
Four tests come with it:
- cursor-area covers the cursor area notifications,
- preedit-cursor covers a caret reported inside the preedit, asserting that
the composition
starts where the input method said its caret was,
- focus-change covers moving focus between two fields with equal state,
- and focus-interaction covers the difference between focusing by click and
by
element.focus().
The last of these documents why the content-type test expects
WEBKIT_INPUT_HINT_INHIBIT_OSK on
every field, including a plain input element.
*
Tools/TestWebKitAPI/Tests/WebKit/WKWebView/glib/TestInputMethodContext.cpp:
(webkitInputMethodContextMockGetPreedit):
(webkitInputMethodContextMockNotifyFocusIn):
(webkitInputMethodContextMockNotifyFocusOut):
(webkitInputMethodContextMockNotifyCursorArea):
(webkitInputMethodContextMockNotifySurrounding):
(webkit_input_method_context_mock_class_init):
(webkit_input_method_context_mock_init):
(testWebKitInputMethodContextCursorArea):
(testWebKitInputMethodContextPreeditCursor):
(testWebKitInputMethodContextFocusChange):
(testWebKitInputMethodContextFocusInteraction):
(beforeAll):
Canonical link: https://commits.webkit.org/322053@main
Canonical link: https://commits.webkit.org/317695.394@webkitglib/2.54
Commit: f97616203a858e09a9797da68414110bc55340e5
https://github.com/WebKit/WebKit/commit/f97616203a858e09a9797da68414110bc55340e5
Author: Simon Pena <[email protected]>
Date: 2026-10-02 (Fri, 02 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 322492@main (53a5080c50e9).
https://bugs.webkit.org/show_bug.cgi?id=325637
[GTK][WPE] Input method is not told the cursor area or surrounding text
again after refocus
https://bugs.webkit.org/show_bug.cgi?id=325637
Reviewed by Adrian Perez de Castro.
InputMethodFilter skips a cursor area that moved less than 10 pixels from
the last one it sent,
and a surrounding text that is the same as the last one. It never cleared
these values. When the
same field was focused again with the caret and the text unchanged, the
input method got focus-in
and nothing else. A new input method context got nothing until the values
changed.
Clear both values when focus leaves and when the context changes. The 10
pixel threshold does not
change.
Test:
Tools/TestWebKitAPI/Tests/WebKit/WKWebView/glib/TestInputMethodContext.cpp
* Source/WebKit/UIProcess/API/glib/InputMethodFilter.cpp:
(WebKit::InputMethodFilter::setContext):
(WebKit::InputMethodFilter::notifyFocusedOut):
*
Tools/TestWebKitAPI/Tests/WebKit/WKWebView/glib/TestInputMethodContext.cpp:
(testWebKitInputMethodContextCursorArea):
Canonical link: https://commits.webkit.org/322492@main
Canonical link: https://commits.webkit.org/317695.395@webkitglib/2.54
Compare: https://github.com/WebKit/WebKit/compare/0eaf398de06f...f97616203a85
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
