Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 6d9f68eb11b04d9d3b7ef30f641916beb95a481e
https://github.com/WebKit/WebKit/commit/6d9f68eb11b04d9d3b7ef30f641916beb95a481e
Author: Wenson Hsieh <[email protected]>
Date: 2024-12-17 (Tue, 17 Dec 2024)
Changed paths:
A
LayoutTests/editing/selection/ios/selection-clipped-by-fixed-position-container-expected.txt
A
LayoutTests/editing/selection/ios/selection-clipped-by-fixed-position-container.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] [SelectionHonorsOverflowScrolling] Selection sometimes ignores
clipping/occlusion after pinch-zooming
https://bugs.webkit.org/show_bug.cgi?id=284837
rdar://141635283
Reviewed by Abrar Rahman Protyasha.
It's currently possible for UI-side selection views to get into a state where
they're no longer
correctly occluded by compositing layers (e.g. a fixed-position container that
covers the selection
container). In particular, this happens when zooming in and out in a web view,
which may cause page
tiles to be recreated in such a way, that they're inserted _under_ UIKit's
managed selection views.
We currently have logic that detects when the selection views need to be
reparented (due to the
previous parent view being removed from the view hierarchy), but we don't have
any logic to ensure
that the selection views are reinserted above the tile grid container (but
below page tiles), if
the parent view doesn't change (but the compositing views underneath the same
parent view have
changed).
Fix this by refactoring this aforementioned logic, so that we reinsert all
managed selection views
between the tile grid container and the rest of the compositing views in the
case where the subview
after the tile grid container view isn't the selection highlight view (the
back-most managed
selection view).
*
LayoutTests/editing/selection/ios/selection-clipped-by-fixed-position-container-expected.txt:
Added.
*
LayoutTests/editing/selection/ios/selection-clipped-by-fixed-position-container.html:
Added.
Add a layout test to exercise the change by pinch-zooming in and out, and
verifying that the
selection view remains occluded by the fixed-position banner.
* LayoutTests/resources/ui-helper.js:
(window.UIHelper.async frontmostViewAtPoint):
(window.UIHelper):
Add a testing hook to retrieve the class name of the frontmost native `UIView`
at the given point in
root view coordinates.
* Source/WebKit/UIProcess/ios/WKTextInteractionWrapper.mm:
(-[WKTextInteractionWrapper prepareToMoveSelectionContainer:]):
See above for more details.
* Tools/TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl:
* Tools/TestRunnerShared/UIScriptContext/UIScriptController.h:
(WTR::UIScriptController::frontmostViewAtPoint):
* Tools/WebKitTestRunner/ios/UIScriptControllerIOS.h:
* Tools/WebKitTestRunner/ios/UIScriptControllerIOS.mm:
(-[UIView _wtr_frontmostViewAtPoint:]):
(WTR::UIScriptControllerIOS::frontmostViewAtPoint):
Canonical link: https://commits.webkit.org/287977@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
