Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 3df5437fcea8f1902bf5728215ee7309d4a4db6d
https://github.com/WebKit/WebKit/commit/3df5437fcea8f1902bf5728215ee7309d4a4db6d
Author: Wenson Hsieh <[email protected]>
Date: 2024-12-03 (Tue, 03 Dec 2024)
Changed paths:
A
LayoutTests/editing/selection/ios/scroll-overflow-container-with-selection-expected.txt
A
LayoutTests/editing/selection/ios/scroll-overflow-container-with-selection.html
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.h
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
M Source/WebKit/UIProcess/ios/WKScrollView.mm
M Source/WebKit/UIProcess/ios/WKTextInteractionWrapper.h
M Source/WebKit/UIProcess/ios/WKTextInteractionWrapper.mm
Log Message:
-----------
[iOS] [SelectionHonorsOverflowScrolling] Overflow containers are unscrollable
when text outside of the container is selected
https://bugs.webkit.org/show_bug.cgi?id=283804
rdar://140308383
Reviewed by Richard Robinson.
On iOS, when `SelectionHonorsOverflowScrolling` is enabled, the text selection
display interaction
can be installed under arbitrary compositing views in the UI-side layer
tree/compositing view
hierarchy. However, this exposes a bug in which the text selection display
interaction's managed
selection views (i.e. native container views that encapsulate the selection
highlight view, range
adjustment handles, and other UI affordances managed by the interaction) will
block hit-testing
underneath the `WKScrollView`, if the compositing view that contains the
selection contains child
scroll views. This prevents UIKit from routing `UITouchEvent`s to the proper
child scroll view under
the gesture location (and therefore prevents scrolling), if the text selection
display interaction
is installed on anything that covers the child scroller.
>From manual testing, it seems generally safe to mark these selection display
>interaction containers
with `userInteractionEnabled := NO`, since their child views (e.g. range
adjustment handles) have
user interaction enabled, and the only other gesture relevant to this
interaction is tapping to
toggle edit menu visibility, which isn't affected by whether or not these
container views are
interactive due to the fact that the text tap gesture is installed over the
content view. To limit
unnecessary bincompat risk (and because this probably uniquely affects WebKit's
integration of the
selection display interaction), we mitigate this by overriding `-[WKScrollView
hitTest:withEvent:]`
and forcing `userInteractionEnabled` to be `NO` for these managed container
views over the scope of
hit-testing.
*
LayoutTests/editing/selection/ios/scroll-overflow-container-with-selection-expected.txt:
Added.
*
LayoutTests/editing/selection/ios/scroll-overflow-container-with-selection.html:
Added.
Add a layout test to exercise the bug, by selecting text in the mainframe and
then attempting to
scroll an overflow container below it via pan gesture.
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.h:
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView makeTextSelectionViewsNonInteractiveForScope]):
Add a helper method that returns a RAII object (`ScopeExit`), which callers can
use to temporarily
make selection container views non-interactive. See above for more details.
* Source/WebKit/UIProcess/ios/WKScrollView.mm:
(-[WKScrollView hitTest:withEvent:]):
Call `-makeTextSelectionViewsNonInteractiveForScope` when hit-testing.
* Source/WebKit/UIProcess/ios/WKTextInteractionWrapper.h:
* Source/WebKit/UIProcess/ios/WKTextInteractionWrapper.mm:
(-[WKTextInteractionWrapper managedTextSelectionViews]):
(-[WKTextInteractionWrapper prepareToMoveSelectionContainer:]):
Add logic to keep track of all the managed views of the text selection display
interaction, by
observing which views were introduced to the target container view as a result
of invoking
`-didMoveToView:`.
Canonical link: https://commits.webkit.org/287294@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
