Bug 182868 – [iOS] Handle update of scroll layer positions for subframes

• Component: Frames
• Status: RESOLVED MOVED

[Frédéric Wang (:fredw)]

Extracted from bug 173833.

[Frédéric Wang (:fredw)]

Created attachment 334032 [details]
Patch

[Frédéric Wang (:fredw)]

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

[Frédéric Wang (:fredw)]

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

[Frédéric Wang (:fredw)]

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)

[Frédéric Wang (:fredw)]

> 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).

[Frédéric Wang (:fredw)]

> 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.

[Frédéric Wang (:fredw)]

Created attachment 334349 [details]
Patch

[Frédéric Wang (:fredw)]

Created attachment 334359 [details]
Patch

[Frédéric Wang (:fredw)]

Created attachment 336850 [details]
Patch

Rebasing over the dependent bugs.

[Frédéric Wang (:fredw)]

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

Rebasing

[Frédéric Wang (:fredw)]

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

[Frédéric Wang (:fredw)]

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

Rebasing...

[Frédéric Wang (:fredw)]

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

[Frédéric Wang (:fredw)]

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.

[EWS Watchlist]

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

[EWS Watchlist]

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

[Frédéric Wang (:fredw)]

@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).

[Frédéric Wang (:fredw)]

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.