- Revision
- 248066
- Author
- [email protected]
- Date
- 2019-07-31 13:56:40 -0700 (Wed, 31 Jul 2019)
Log Message
Cherry-pick r248015. rdar://problem/53764191
Can't scroll on yummly.co.uk recipe (scale(0) div covers the content and hit-tests)
https://bugs.webkit.org/show_bug.cgi?id=200263
rdar://problem/53679408
Reviewed by Antti Koivisto.
Source/WebKit:
The content on this page had a scale(0) div overlaying an overflow:scroll element,
and our UI-side hit-testing code would find this scale(0) element, because apparently
-[UIView convertPoint:fromView:] will happily work with non-invertible matrices, and
-[UIView pointInside:withEvent:] just compares the point with the view bounds.
Since the view frame takes the transform into account, we can look for an empty frame
to detect these non-invertible transforms.
* UIProcess/RemoteLayerTree/ios/RemoteLayerTreeViews.mm:
(WebKit::collectDescendantViewsAtPoint):
LayoutTests:
* fast/scrolling/ios/non-invertible-transformed-over-scroller-expected.txt: Added.
* fast/scrolling/ios/non-invertible-transformed-over-scroller.html: Added.
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248015 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Modified Paths
Added Paths
Diff
Modified: branches/safari-608-branch/LayoutTests/ChangeLog (248065 => 248066)
--- branches/safari-608-branch/LayoutTests/ChangeLog 2019-07-31 20:56:37 UTC (rev 248065)
+++ branches/safari-608-branch/LayoutTests/ChangeLog 2019-07-31 20:56:40 UTC (rev 248066)
@@ -1,5 +1,46 @@
2019-07-31 Alan Coon <[email protected]>
+ Cherry-pick r248015. rdar://problem/53764191
+
+ Can't scroll on yummly.co.uk recipe (scale(0) div covers the content and hit-tests)
+ https://bugs.webkit.org/show_bug.cgi?id=200263
+ rdar://problem/53679408
+
+ Reviewed by Antti Koivisto.
+
+ Source/WebKit:
+
+ The content on this page had a scale(0) div overlaying an overflow:scroll element,
+ and our UI-side hit-testing code would find this scale(0) element, because apparently
+ -[UIView convertPoint:fromView:] will happily work with non-invertible matrices, and
+ -[UIView pointInside:withEvent:] just compares the point with the view bounds.
+
+ Since the view frame takes the transform into account, we can look for an empty frame
+ to detect these non-invertible transforms.
+
+ * UIProcess/RemoteLayerTree/ios/RemoteLayerTreeViews.mm:
+ (WebKit::collectDescendantViewsAtPoint):
+
+ LayoutTests:
+
+ * fast/scrolling/ios/non-invertible-transformed-over-scroller-expected.txt: Added.
+ * fast/scrolling/ios/non-invertible-transformed-over-scroller.html: Added.
+
+ git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248015 268f45cc-cd09-0410-ab3c-d52691b4dbfc
+
+ 2019-07-29 Simon Fraser <[email protected]>
+
+ Can't scroll on yummly.co.uk recipe (scale(0) div covers the content and hit-tests)
+ https://bugs.webkit.org/show_bug.cgi?id=200263
+ rdar://problem/53679408
+
+ Reviewed by Antti Koivisto.
+
+ * fast/scrolling/ios/non-invertible-transformed-over-scroller-expected.txt: Added.
+ * fast/scrolling/ios/non-invertible-transformed-over-scroller.html: Added.
+
+2019-07-31 Alan Coon <[email protected]>
+
Cherry-pick r247936. rdar://problem/53764217
YouTube search field shows RTL text outside its border on iPadOS
Added: branches/safari-608-branch/LayoutTests/fast/scrolling/ios/non-invertible-transformed-over-scroller-expected.txt (0 => 248066)
--- branches/safari-608-branch/LayoutTests/fast/scrolling/ios/non-invertible-transformed-over-scroller-expected.txt (rev 0)
+++ branches/safari-608-branch/LayoutTests/fast/scrolling/ios/non-invertible-transformed-over-scroller-expected.txt 2019-07-31 20:56:40 UTC (rev 248066)
@@ -0,0 +1,12 @@
+Tests hit-testing of layers over scrollers with odd transforms
+
+On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE".
+
+
+PASS scrollTopWithScale0Overlay is 100
+PASS scrollTopWithScaledOverlayHitOverlay is 0
+PASS scrollTopWithScaledOverlayHitScroller is 100
+PASS successfullyParsed is true
+
+TEST COMPLETE
+
Added: branches/safari-608-branch/LayoutTests/fast/scrolling/ios/non-invertible-transformed-over-scroller.html (0 => 248066)
--- branches/safari-608-branch/LayoutTests/fast/scrolling/ios/non-invertible-transformed-over-scroller.html (rev 0)
+++ branches/safari-608-branch/LayoutTests/fast/scrolling/ios/non-invertible-transformed-over-scroller.html 2019-07-31 20:56:40 UTC (rev 248066)
@@ -0,0 +1,99 @@
+<!DOCTYPE html> <!-- webkit-test-runner [ internal:AsyncOverflowScrollingEnabled=true ] -->
+<html>
+<head>
+ <meta name="viewport" content="width=device-width">
+ <style>
+ div {
+ box-sizing: border-box;
+ }
+ .container {
+ position: relative;
+ width: 200px;
+ height: 200px;
+ margin: 10px;
+ border: 1px solid black;
+ }
+
+ .scroller {
+ overflow: scroll;
+ }
+
+ .content {
+ width: 100%;
+ height: 300%;
+ background-image: repeating-linear-gradient(white, silver 200px);
+ }
+
+ .overlay {
+ transform-origin: top left;
+ background-color: rgba(0, 0, 0, 0.25);
+ }
+
+ .container > div {
+ position: absolute;
+ width: 100%;
+ height: 100%;
+ }
+ </style>
+ <script src=""
+ <script src=""
+ <script>
+ var scrollTopWithScale0Overlay;
+ var scrollTopWithScaledOverlayHitOverlay;
+ var scrollTopWithScaledOverlayHitScroller;
+
+ window.addEventListener('load', async () => {
+
+ let scrollers = document.querySelectorAll('.scroller');
+ let bounds = scrollers[0].getBoundingClientRect();
+
+ await UIHelper.immediateScrollElementAtContentPointToOffset(bounds.left + 10, bounds.top + 10, 0, 100);
+ scrollTopWithScale0Overlay = scrollers[0].scrollTop;
+
+ // In case the previous scroll failed.
+ document.scrollingElement.scrollTop = 0;
+ scrollers[1].scrollTop = 0;
+
+ bounds = scrollers[1].getBoundingClientRect();
+ // Hit the overlay
+ await UIHelper.immediateScrollElementAtContentPointToOffset(bounds.left + 10, bounds.top + 10, 0, 100);
+ scrollTopWithScaledOverlayHitOverlay = scrollers[1].scrollTop;
+
+ // In case the previous scroll failed.
+ document.scrollingElement.scrollTop = 0;
+ scrollers[1].scrollTop = 0;
+
+ // Hit the scroller
+ await UIHelper.immediateScrollElementAtContentPointToOffset(bounds.left + bounds.width / 2 + 10, bounds.top + 10, 0, 100);
+ scrollTopWithScaledOverlayHitScroller = scrollers[1].scrollTop;
+
+ description('Tests hit-testing of layers over scrollers with odd transforms');
+ shouldBe('scrollTopWithScale0Overlay', '100');
+ shouldBe('scrollTopWithScaledOverlayHitOverlay', '0');
+ shouldBe('scrollTopWithScaledOverlayHitScroller', '100');
+
+ finishJSTest();
+
+ }, false);
+
+ var successfullyParsed = true;
+ var jsTestIsAsync = true;
+ </script>
+ <script src=""
+</head>
+<body>
+ <div class="container">
+ <div class="scroller">
+ <div class="content"></div>
+ </div>
+ <div class="overlay" style="transform: scale(0)"></div>
+ </div>
+
+ <div class="container">
+ <div class="scroller">
+ <div class="content"></div>
+ </div>
+ <div class="overlay" style="transform: scale(0.5)"></div>
+ </div>
+</body>
+</html>
Modified: branches/safari-608-branch/Source/WebKit/ChangeLog (248065 => 248066)
--- branches/safari-608-branch/Source/WebKit/ChangeLog 2019-07-31 20:56:37 UTC (rev 248065)
+++ branches/safari-608-branch/Source/WebKit/ChangeLog 2019-07-31 20:56:40 UTC (rev 248066)
@@ -1,60 +1,90 @@
2019-07-31 Alan Coon <[email protected]>
- Cherry-pick r247936. rdar://problem/53764217
+ Cherry-pick r248015. rdar://problem/53764191
- YouTube search field shows RTL text outside its border on iPadOS
- https://bugs.webkit.org/show_bug.cgi?id=200253
- <rdar://problem/53680603>
+ Can't scroll on yummly.co.uk recipe (scale(0) div covers the content and hit-tests)
+ https://bugs.webkit.org/show_bug.cgi?id=200263
+ rdar://problem/53679408
- Reviewed by Beth Dakin.
+ Reviewed by Antti Koivisto.
Source/WebKit:
- Limits code added in r238939 to respect the current keyboard's writing mode to only editable web views. This
- behavior was only intended for Mail, and isn't generally compatible with web content.
+ The content on this page had a scale(0) div overlaying an overflow:scroll element,
+ and our UI-side hit-testing code would find this scale(0) element, because apparently
+ -[UIView convertPoint:fromView:] will happily work with non-invertible matrices, and
+ -[UIView pointInside:withEvent:] just compares the point with the view bounds.
- While the call to -setInitialDirection is correctly gated on an web view editability check, it appears that
- other changes in iOS 13 now cause -setBaseWritingDirection:forRange: to be invoked directly from keyboards code.
- This means that -setBaseWritingDirection:forRange: should additionally be guarded with the same check.
+ Since the view frame takes the transform into account, we can look for an empty frame
+ to detect these non-invertible transforms.
- * UIProcess/ios/WKContentViewInteraction.mm:
- (-[WKContentView setBaseWritingDirection:forRange:]):
+ * UIProcess/RemoteLayerTree/ios/RemoteLayerTreeViews.mm:
+ (WebKit::collectDescendantViewsAtPoint):
LayoutTests:
- * editing/input/ios/rtl-keyboard-input-on-focus-in-editable-page-expected.txt: Renamed from LayoutTests/editing/input/ios/rtl-keyboard-input-on-focus-expected.txt.
- * editing/input/ios/rtl-keyboard-input-on-focus-in-editable-page.html: Renamed from LayoutTests/editing/input/ios/rtl-keyboard-input-on-focus.html.
+ * fast/scrolling/ios/non-invertible-transformed-over-scroller-expected.txt: Added.
+ * fast/scrolling/ios/non-invertible-transformed-over-scroller.html: Added.
- Rename an existing test, rtl-keyboard-input-on-focus.html, to rtl-keyboard-input-on-focus-in-editable-page.html
- to emphasize the fact that it requires an editable web view.
-
- * editing/input/ios/rtl-keyboard-input-on-focus-in-non-editable-page-expected.txt: Added.
- * editing/input/ios/rtl-keyboard-input-on-focus-in-non-editable-page.html: Added.
-
- Add a new layout test to ensure that we don't automatically apply an RTL attribute when focusing fields in a
- non-editable web view.
-
-
- git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247936 268f45cc-cd09-0410-ab3c-d52691b4dbfc
+ git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248015 268f45cc-cd09-0410-ab3c-d52691b4dbfc
- 2019-07-29 Wenson Hsieh <[email protected]>
+ 2019-07-31 Alan Coon <[email protected]>
- YouTube search field shows RTL text outside its border on iPadOS
- https://bugs.webkit.org/show_bug.cgi?id=200253
- <rdar://problem/53680603>
+ Cherry-pick r247936. rdar://problem/53764217
- Reviewed by Beth Dakin.
+ YouTube search field shows RTL text outside its border on iPadOS
+ https://bugs.webkit.org/show_bug.cgi?id=200253
+ <rdar://problem/53680603>
- Limits code added in r238939 to respect the current keyboard's writing mode to only editable web views. This
- behavior was only intended for Mail, and isn't generally compatible with web content.
+ Reviewed by Beth Dakin.
- While the call to -setInitialDirection is correctly gated on an web view editability check, it appears that
- other changes in iOS 13 now cause -setBaseWritingDirection:forRange: to be invoked directly from keyboards code.
- This means that -setBaseWritingDirection:forRange: should additionally be guarded with the same check.
+ Source/WebKit:
- * UIProcess/ios/WKContentViewInteraction.mm:
- (-[WKContentView setBaseWritingDirection:forRange:]):
+ Limits code added in r238939 to respect the current keyboard's writing mode to only editable web views. This
+ behavior was only intended for Mail, and isn't generally compatible with web content.
+ While the call to -setInitialDirection is correctly gated on an web view editability check, it appears that
+ other changes in iOS 13 now cause -setBaseWritingDirection:forRange: to be invoked directly from keyboards code.
+ This means that -setBaseWritingDirection:forRange: should additionally be guarded with the same check.
+
+ * UIProcess/ios/WKContentViewInteraction.mm:
+ (-[WKContentView setBaseWritingDirection:forRange:]):
+
+ LayoutTests:
+
+ * editing/input/ios/rtl-keyboard-input-on-focus-in-editable-page-expected.txt: Renamed from LayoutTests/editing/input/ios/rtl-keyboard-input-on-focus-expected.txt.
+ * editing/input/ios/rtl-keyboard-input-on-focus-in-editable-page.html: Renamed from LayoutTests/editing/input/ios/rtl-keyboard-input-on-focus.html.
+
+ Rename an existing test, rtl-keyboard-input-on-focus.html, to rtl-keyboard-input-on-focus-in-editable-page.html
+ to emphasize the fact that it requires an editable web view.
+
+ * editing/input/ios/rtl-keyboard-input-on-focus-in-non-editable-page-expected.txt: Added.
+ * editing/input/ios/rtl-keyboard-input-on-focus-in-non-editable-page.html: Added.
+
+ Add a new layout test to ensure that we don't automatically apply an RTL attribute when focusing fields in a
+ non-editable web view.
+
+
+ git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247936 268f45cc-cd09-0410-ab3c-d52691b4dbfc
+
+ 2019-07-29 Wenson Hsieh <[email protected]>
+
+ YouTube search field shows RTL text outside its border on iPadOS
+ https://bugs.webkit.org/show_bug.cgi?id=200253
+ <rdar://problem/53680603>
+
+ Reviewed by Beth Dakin.
+
+ Limits code added in r238939 to respect the current keyboard's writing mode to only editable web views. This
+ behavior was only intended for Mail, and isn't generally compatible with web content.
+
+ While the call to -setInitialDirection is correctly gated on an web view editability check, it appears that
+ other changes in iOS 13 now cause -setBaseWritingDirection:forRange: to be invoked directly from keyboards code.
+ This means that -setBaseWritingDirection:forRange: should additionally be guarded with the same check.
+
+ * UIProcess/ios/WKContentViewInteraction.mm:
+ (-[WKContentView setBaseWritingDirection:forRange:]):
+
2019-07-31 Alan Coon <[email protected]>
Cherry-pick r247933. rdar://problem/53764069
@@ -318,7 +348,26 @@
2019-07-29 Alan Coon <[email protected]>
Cherry-pick r247672. rdar://problem/53449739
+2019-07-29 Simon Fraser <[email protected]>
+ Can't scroll on yummly.co.uk recipe (scale(0) div covers the content and hit-tests)
+ https://bugs.webkit.org/show_bug.cgi?id=200263
+ rdar://problem/53679408
+
+ Reviewed by Antti Koivisto.
+
+ The content on this page had a scale(0) div overlaying an overflow:scroll element,
+ and our UI-side hit-testing code would find this scale(0) element, because apparently
+ -[UIView convertPoint:fromView:] will happily work with non-invertible matrices, and
+ -[UIView pointInside:withEvent:] just compares the point with the view bounds.
+
+ Since the view frame takes the transform into account, we can look for an empty frame
+ to detect these non-invertible transforms.
+
+ * UIProcess/RemoteLayerTree/ios/RemoteLayerTreeViews.mm:
+ (WebKit::collectDescendantViewsAtPoint):
+
+
Micro-optimize HashMap & String IPC decoding
https://bugs.webkit.org/show_bug.cgi?id=199967
Modified: branches/safari-608-branch/Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteLayerTreeViews.mm (248065 => 248066)
--- branches/safari-608-branch/Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteLayerTreeViews.mm 2019-07-31 20:56:37 UTC (rev 248065)
+++ branches/safari-608-branch/Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteLayerTreeViews.mm 2019-07-31 20:56:40 UTC (rev 248066)
@@ -52,8 +52,13 @@
// It is currently only needed for scroll views.
if (!view.isUserInteractionEnabled)
return false;
+
+ if (CGRectIsEmpty([view frame]))
+ return false;
+
if (![view pointInside:subviewPoint withEvent:event])
return false;
+
if (![view isKindOfClass:[WKCompositingView class]])
return true;
auto* node = RemoteLayerTreeNode::forCALayer(view.layer);
