Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 3916421610452cd648ce8e8cbd43bc462f644b8d
https://github.com/WebKit/WebKit/commit/3916421610452cd648ce8e8cbd43bc462f644b8d
Author: Simon Pena <[email protected]>
Date: 2026-09-28 (Mon, 28 Sep 2026)
Changed paths:
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Tools/TestWebKitAPI/Tests/WebKit/WKWebView/glib/TestInputMethodContext.cpp
Log Message:
-----------
[GTK][WPE] Input method delete-surrounding deletes the wrong text in
contenteditable
https://bugs.webkit.org/show_bug.cgi?id=325166
Reviewed by Adrian Perez de Castro.
The input method sends delete-surrounding with an offset relative to the caret.
WebPage::deleteSurrounding
turned it into a position counted from the start of the editable content, but
then looked that position
up in the whole tree scope. For <input> and <textarea> both start at the same
place, because the text is
in the control's own shadow tree. For a contenteditable element in the document
they do not: the position
was shifted by all the text in the page before the element. With <h1>Title</h1>
before the element, a
delete of the last character selected "t" in the heading instead. The heading
is not editable, so
nothing was deleted.
Look the position up in the range from the start to the end of the editable
content. This is the same
range that getPlatformEditorState uses to build the surrounding text sent to
the input method, so the
input method's offsets and the lookup now count from the same place. The range
variables now use the same
names as in getPlatformEditorState: surroundingRange is the whole editable
content, and
cursorPositionRange goes from its start to the caret.
Also return without doing anything if the delete would start before the start
of the editable content.
The caret position is unsigned, so such an offset wrapped round to a very large
position, and the caret
jumped to the end. Bug 206352 fixed a crash in this case with a null check, but
resolveCharacterRange
now always returns a range, so that check no longer had any effect. GtkText in
GTK also rejects a delete
that starts before the start of the text.
Test: Tools/TestWebKitAPI/Tests/WebKit/WKWebView/glib/TestInputMethodContext.cpp
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::deleteSurrounding):
* Tools/TestWebKitAPI/Tests/WebKit/WKWebView/glib/TestInputMethodContext.cpp:
(testWebKitInputMethodContextDeleteSurroundingContentEditable):
(testWebKitInputMethodContextDeleteSurroundingBeforeStart):
(beforeAll):
Canonical link: https://commits.webkit.org/322039@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
