Bug 182868

Created attachment 334032 [details] Patch

Created attachment 334033 [details] Patch for EWS (includes 182785 and 173833)

Created attachment 334271 [details] Testcase (frame with padding/border/margin)

Created attachment 334272 [details] Dumped trees for attachment 334271 [details] 23:23:00 - smfr: maybe you could draw some ASCII art in a bug to show how the web process layer tree maps into UIScrollVIews for a subframe, across the frame boundary 23:23:11 - smfr: it's critical to get that part right @Simon: This is how the tree mapping is done for attachment 334271 [details]. I'm attaching an archive with the various dumped trees. Graphics Layer Tree (Web Process) UIView (UI Process) content root (800x600) WKCompositingView (388x454) | | \_RenderView (800x600) \_WKCompositingView (388x454) | | \_Page TiledBacking containment \_WKCompositingView (0x0) | | \_<iframe> (310x210) \_WKCompositingView (310x210) | | \_overflow controls host \_WKCompositingView (0x0) | | \_frame clipping (200x100) \_WKCompositingView (200x100) | | \_frame scrolling (200x100) \_UIScrollView (200x100, content-size: 320x540) | | \_content root (320x540) \_WKCompositingView (320x540) | | \_RenderView (320x540) \_WKCompositingView (320x540)

> 22:56:40 - smfr: RLC owns the m_scrollingLayer so it should be the one to resize it. > 22:56:50 - smfr: i'm not sure why things work now when it's not getting resized > 22:57:14 - smfr: maybe just because that layer doesn't really do anything other than add the scroll position > 22:57:21 - smfr: it could probably be 0 x 0 > 22:57:42 - fredw: I think when it is 0x0 we don't see anything > 22:57:48 - fredw: that's why I need the size > 22:57:55 - smfr: that should only be true if it has masksToBounds set > 23:19:31 - fredw: IIRC it does not have masksToBounds but keeping it to 0x0 does not render anything So regarding this, as I said masksToBounds is not set on the Web Process side. On the UI process side, the UIScrollView "frame scrolling" is created in RemoteLayerTreeHost::createLayer (Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteLayerTreeHostIOS.mm) with layerProperties's masksToBounds set to false but layerProperties is not used at all in that function. The UIScrollView is created by default with masksToBounds == YES. Forcing [[view layer] setMasksToBounds:NO] does allow to display the content of the frame and it is properly clipped thanks to the parent "frame clipping" view. Hit testing and programmatic scrolling works bu user scrolling fails (probably because the UIScrollView has 0x0 size). > 23:08:43 - smfr: so it looks like m_scrollLayer is always zero sized on mac Yes, that's the case now. The patch for bug 173833 changes that for subframes since you asked me try and get rid of #if PLATFORM(IOS).

> 22:58:28 - fredw: https://trac.webkit.org/browser/trunk/Source/WebCore/rendering/RenderLayerCompositor.cpp#L1672 > 22:59:14 - fredw: because hasCoordinatedScrolling() returns true, updateScrollLayerPosition() is not called > 23:00:20 - fredw: on the other hand, we already have some logic to update the scrollLayer in https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/page/scrolling/AsyncScrollingCoordinator.cpp#L405 > 23:00:20 - fredw: on the other hand, we already have some logic to update the scrollLayer in https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/page/scrolling/AsyncScrollingCoordinator.cpp#L405 > 23:00:48 - smfr: right > 23:01:05 - smfr: the code in AsyncScrollingCoordinator is just to sync up the layers with the scrolling tree after a scroll > 23:01:29 - smfr: it's not the "primary" layer geometry-setting mechanism > 23:02:04 - smfr: i'm a bit confused by RenderLayerCompositor::updateScrollLayerPosition() > 23:02:15 - smfr: not sure which platforms actually use that Given the above, attachment 334032 [details] performs the setting of the scroll position in RenderLayerCompositor::frameViewDidScroll() (which is also called from FrameView::scrollPositionChanged) not updateScrollLayerPosition(). Also I have to disable the existing code in AsyncScrollingCoordinator.cpp to avoid conflicts.

Created attachment 334349 [details] Patch

Created attachment 334359 [details] Patch

Created attachment 336850 [details] Patch Rebasing over the dependent bugs.

Created attachment 340072 [details] Patch (applies on top of bugs 182785, 173833 and 183040) Rebasing

Created attachment 348913 [details] Patch (applies on top of bugs 182785, 173833 and 183040)

Created attachment 354930 [details] Patch (applies on top of bugs 182785, 173833 and 183040) Rebasing...

*** Bug 193653 has been marked as a duplicate of this bug. ***

Created attachment 359723 [details] Patch for EWS Rebasing the patch and integrating previous changes from dependent bugs that are not merged yet. Note: I haven't tested the patch yet, this for EWS.

Comment on attachment 359723 [details] Patch for EWS Attachment 359723 [details] did not pass ios-sim-ews (ios-simulator-wk2): Output: https://webkit-queues.webkit.org/results/10836839 New failing tests: fast/scrolling/ios/hit-testing-iframe.html fast/scrolling/ios/mixing-user-and-programmatic-scroll.html compositing/rtl/rtl-iframe-absolute-overflow.html fast/scrolling/ios/programmatic-scroll-iframe.html

Created attachment 359727 [details] Archive of layout-test-results from ews122 for ios-simulator-wk2 The attached test failures were seen while running run-webkit-tests on the ios-sim-ews. Bot: ews122 Port: ios-simulator-wk2 Platform: Mac OS X 10.13.6

@Anttik: Out of curiosity, what is the pass rate of the tests in this patch after bug 193665? (I plan to check it again later anyway).

Remaining tests have been moved to bug 194886, bug 194433 and 194900. And the actual code change is handled elsewhere differently. So I think we can close this bug now.