Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 2aa41ea14b83de5fc8af2827129307dd821a5233
https://github.com/WebKit/WebKit/commit/2aa41ea14b83de5fc8af2827129307dd821a5233
Author: Wenson Hsieh <[email protected]>
Date: 2024-12-22 (Sun, 22 Dec 2024)
Changed paths:
A
LayoutTests/editing/selection/ios/selection-after-reparenting-view-and-becoming-first-responder-expected.txt
A
LayoutTests/editing/selection/ios/selection-after-reparenting-view-and-becoming-first-responder.html
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
M Source/WebKit/UIProcess/ios/WKTextInteractionWrapper.h
M Source/WebKit/UIProcess/ios/WKTextInteractionWrapper.mm
Log Message:
-----------
[iOS] [SelectionHonorsOverflowScrolling] Selection rects are sometimes offset
after switching back to a tab
https://bugs.webkit.org/show_bug.cgi?id=285072
rdar://141885834
Reviewed by Abrar Rahman Protyasha.
When `SelectionHonorsOverflowScrolling` is enabled, it's possible to get the
text selection
highlight view into a state where it's in the wrong place after switching away
and then back to a
tab in Safari. When performing this workflow (switching from web view A to B,
and then back to A)…
1. Safari removes A from the view hierarchy, replacing it with B. Underlying
compositing views
(one of which may contain selection views) are also removed from the view
hierarchy in the
process. The text interaction is also deactivated, as a result of the view
no longer being
parented.
2. When switching back, Safari reinserts A in the view hierarchy, and
immediately proceeds to call
`-becomeFirstResponder` on the web view. In `-[WKContentView
becomeFirstResponderForWebView]`,
this causes us to activate the selection right away, which leads to UIKit
regenerating
selection highlight views by mapping from `WKContentView` coordinates to
selection container
coordinates. However, when `SelectionHonorsOverflowScrolling` is enabled,
the selection is in a
compositing view that still hasn't been reparented in the view hierarchy at
this point, so the
coordinate space mapping produces an incorrect result.
3. After the first presentation update that follows, the compositing views are
reinserted. However,
because the text selection display interaction is already active and UIKit
has already laid out
selection rects, we bail early on updating native selection views because
we think we're already
up to date.
Consequently, the selection ends up being offset until the next selection
change (or any other
layout change that forces the selection display interaction to update again).
To fix this, we simply
defer the selection activation until the next presentation update (when the
layer tree is up to
date), and also call `-setNeedsSelectionUpdate` to ensure that UIKit lays out
selection views using
up-to-date selection geometry.
*
LayoutTests/editing/selection/ios/selection-after-reparenting-view-and-becoming-first-responder-expected.txt:
Added.
*
LayoutTests/editing/selection/ios/selection-after-reparenting-view-and-becoming-first-responder.html:
Added.
Add a layout test to exercise the bug, by simulating switching away and then
back to a tab in
Safari and verifying that the selection highlight rect appears in the same
place.
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView becomeFirstResponderForWebView]):
See above for more details.
(-[WKContentView _shouldActivateSelectionAfterBecomingFirstResponder]):
* Source/WebKit/UIProcess/ios/WKTextInteractionWrapper.h:
* Source/WebKit/UIProcess/ios/WKTextInteractionWrapper.mm:
(-[WKTextInteractionWrapper setNeedsSelectionUpdate]):
Add a helper method to call `-setNeedsSelectionUpdate` on the underlying text
selection display
interaction.
Canonical link: https://commits.webkit.org/288232@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
