Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: b8cacf190ad60d1d602a3b40509bb52d9ec4b5fb
https://github.com/WebKit/WebKit/commit/b8cacf190ad60d1d602a3b40509bb52d9ec4b5fb
Author: Wenson Hsieh <wenson_hs...@apple.com>
Date: 2024-03-13 (Wed, 13 Mar 2024)
Changed paths:
M Source/WebCore/editing/VisibleUnits.cpp
M Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm
M Tools/TestRunnerShared/spi/UIKitSPIForTesting.h
M Tools/TestWebKitAPI/Tests/WebKitCocoa/DocumentEditingContext.mm
Log Message:
-----------
[iOS 17.4] 21+ layout tests assert under
WebPage::requestDocumentEditingContext
https://bugs.webkit.org/show_bug.cgi?id=270899
rdar://123028247
Reviewed by Abrar Rahman Protyasha.
As a part of BrowserEngineKit adoption in iOS 17.4, UIKit began issuing
document editing context
requests to grab 2 sentences worth of context before and after the selection
while the keyboard is
shown. This triggers a frequent debug assertion when running tests on iOS 17.4,
due to the fact that
the current implementation of `nextSentenceBoundaryInDirection` frequently
returns a position that
ends up being upstream of the initial `vp` when the `direction` is downstream,
or downstream of the
`vp` when the given `direction` is upstream. For instance, this can happen when
we're trying to find
the next downstream sentence boundary when the `vp` is anchored to a cell in a
table; we end up
first moving to the end of the table with `nextSentencePosition`, but then
`startOfSentence` takes
us back up to before the table, leaving us at a position before the initial
`vp` (despite the fact
that we wanted to go downstream). To fix this, we make
`nextSentenceBoundaryInDirection` more
robust with some minor adjustments:
1. When moving downstream, if the start of the next sentence is before `vp`,
then move to the end
of the next sentence instead (and vice versa when moving upstream).
2. Repeat the process of moving to the next `startOfSentence` or
`endOfSentence` until the `result`
is in the requested `direction` relative to the initial `vp`.
This ensures that we'll find the closest visible position that satisfies the
following constraints:
1. It is the result of either `startOfSentence` or `endOfSentence`.
2. It is downstream of the initial `vp` when the `direction` is downstream,
and vice versa when the
`direction` is upstream.
* Source/WebCore/editing/VisibleUnits.cpp:
(WebCore::nextSentenceBoundaryInDirection):
* Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::moveByGranularityRespectingWordBoundary):
Also, remove an unnecessary assertion here. This assertion can fire in the case
where the given
`position` already denotes the end of the last (if moving downstream) or the
start of the first (if
moving upstream) sentence in the document or editable root, in which case
`positionOfNextBoundaryOfGranularity` will just return the null position. This
scenario is already
handled gracefully.
* Tools/TestRunnerShared/spi/UIKitSPIForTesting.h:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/DocumentEditingContext.mm:
(makeRequest):
Remove staging for `UITextDocumentRequest` / `UITextDocumentContext`, since the
rename from
`UIWKDocument*` to `UITextDocument*` never ended up happening (and we
alternatively went with
introducing these objects in BrowserEngineKit, as `BETextDocument*`).
(-[TestWKWebView synchronouslyRequestDocumentContext:]):
(TEST):
(-[UITextDocumentContext markedTextRects]): Deleted.
(-[UITextDocumentContext contextBeforeLength]): Deleted.
(-[UITextDocumentContext markedTextLength]): Deleted.
(-[UITextDocumentContext markedTextRange]): Deleted.
(-[UITextDocumentContext textRects]): Deleted.
(-[UITextDocumentContext boundingRectForCharacterRange:]): Deleted.
Also fix these failing API tests on iOS 17.4 (which currently expect
`UIWKDocumentContext` instead
of a `BETextDocumentContext`, and therefore throw ObjC exceptions at runtime
when attempting to
access `contextBefore` and other methods).
Canonical link: https://commits.webkit.org/276067@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
