Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 081f5360d06e7cacd6f0c523d8428074d1b5680a
https://github.com/WebKit/WebKit/commit/081f5360d06e7cacd6f0c523d8428074d1b5680a
Author: Lily Spiniolas <[email protected]>
Date: 2025-10-07 (Tue, 07 Oct 2025)
Changed paths:
A
LayoutTests/editing/selection/ios/scrolling-after-caret-selection-inside-contenteditable-div-expected.txt
A
LayoutTests/editing/selection/ios/scrolling-after-caret-selection-inside-contenteditable-div.html
M LayoutTests/resources/ui-helper.js
M Source/WebKit/UIProcess/ios/WKTextInteractionWrapper.mm
M Tools/TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl
M Tools/TestRunnerShared/UIScriptContext/UIScriptController.h
M Tools/WebKitTestRunner/ios/UIScriptControllerIOS.h
M Tools/WebKitTestRunner/ios/UIScriptControllerIOS.mm
Log Message:
-----------
[iOS] Cannot scroll on gemini.google.com after sending message
https://bugs.webkit.org/show_bug.cgi?id=300153
rdar://157042896
Reviewed by Wenson Hsieh.
When selection honors overflow scrolling is enabled (specifically after
285350@main,
in which we switched from tracking scroll containers for the selection to
tracking
the graphics layer for the selection), scrolling does not work as expected on
gemini.google.com. After typing a message and hitting the send button, it is not
possible to scroll in the conversation log until the log is tapped. This is the
result of views related to text selection impacting the results of `hitTest:` in
`WKScrollView`. To prevent this from happening, there is existing logic which
calls
`makeTextSelectionViewsNonInteractiveForScope` which ensures that user
interaction
is disabled for all views in `[_textInteractionWrapper
managedTextSelectionViews]`.
However, `managedTextSelectionViews` may be empty even when views related to
text
selection are present in the view hierarchy (this is the case on
gemini.google.com).
In this scenario, `makeTextSelectionViewsNonInteractiveForScope` fails to
disable
user interaction on the text selection views, causing them to impact hit test
results.
The emptiness of `managedTextSelectionViews` is the result of the following:
After the page loads but before user interaction:
1. gemini.google.com programmatically focuses a contenteditable div on page
load (the
message field), causing a selection to be made.
2. `prepareToMoveSelectionContainer:(UIView *)newContainer` is called as a
result
of the selection. `newContainer` is not yet the `superview` of the display
interaction's
highlight view, so `[displayInteraction willMoveToView:_view]` &
`[displayInteraction didMoveToView:_view]` are called to move the views
related to
text selection.
3. To determine which views are related to text selection, we compare the
descendants
of newContainer before calling `willMoveToView` and `didMoveToView` as
mentioned above
to the descendants afterwards. These views are stored in
_managedTextSelectionViews.
4. Critically, UIKit does not actually install any views because the
interaction is not
in the activated state (the focus which got us here was programmatic). There
is no
difference between the before and after state, so _managedTextSelectionViews
remains
empty.
After activating and typing in the message field:
5. The selection/highlight views are installed by UIKit as expected.
`prepareToMoveSelectionContainer:(UIView *)newContainer` is called
afterwards, but the
highlight/selection views have already been appended to the new container.
_managedTextSelectionViews is thus not updated, and remains empty.
After the send button is pressed:
6. The selection is not cleared despite editing ending. This is because the
message field
is a contenteditable div rather than a text input or textarea (see
webkit.org/b/38696).
The highlight views remain installed as a result.
After attempting to scroll:
7. To prevent the selection/highlight views from interfering with the scroll
view's hit test,
we temporarily disable user interaction for all of the selection/highlight
views stored in
_managedTextSelectionViews. In this case, _managedTextSelectionViews is
empty despite the
presence of the views. The hit test breaks, and scrolling does not work as a
result.
To fix this, we simply activate the display interaction before calling
`willMoveToView` and
`didMoveToView`.
Added new UIHelper method `setFocusStartsInputSessionPolicy` to change the
input session policy
during a test. This is important for the newly added layout test because to
mimic the behavior
of a physical device without a hardware keyboard, we must start the test with
the policy set
to `disallow`, and then later restore it to "auto". This is required so that we
can avoid showing
keyboard UI on the initial programmatic focus (which would have started an
actual editing session)
and then later show the keyboard UI after activating the input field, just like
a physical device
without a hardware keyboard attached.
Test:
editing/selection/ios/scrolling-after-caret-selection-inside-contenteditable-div.html
*
LayoutTests/editing/selection/ios/scrolling-after-caret-selection-inside-contenteditable-div-expected.txt:
Added.
*
LayoutTests/editing/selection/ios/scrolling-after-caret-selection-inside-contenteditable-div.html:
Added.
* LayoutTests/resources/ui-helper.js:
(window.UIHelper.setFocusStartsInputSessionPolicy):
* Source/WebKit/UIProcess/ios/WKTextInteractionWrapper.mm:
(-[WKTextInteractionWrapper prepareToMoveSelectionContainer:]):
* Tools/TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl:
* Tools/TestRunnerShared/UIScriptContext/UIScriptController.h:
(WTR::UIScriptController::setFocusStartsInputSessionPolicy):
* Tools/WebKitTestRunner/ios/UIScriptControllerIOS.h:
* Tools/WebKitTestRunner/ios/UIScriptControllerIOS.mm:
(WTR::UIScriptControllerIOS::setFocusStartsInputSessionPolicy):
Canonical link: https://commits.webkit.org/301162@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
