[Webkit-unassigned] [Bug 149264] IFrame scrolling=yes is ignored in iOS Safari

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=149264

--- Comment #17 from Simon Fraser (smfr) <simon.fraser at apple.com> ---
(In reply to Frédéric Wang (:fredw) from comment #16)
> (In reply to Simon Fraser (smfr) from comment #13)
> > There's a bunch of work that has to happen to make frames/iframes
> > scrollable, involving educating the scrolling state tree & scrolling tree
> > about scrollable frames (we don't even do that on Mac yet), making latching
> > work correctly etc. Then the UI process has to be fixed to make
> > UIScrollViews for scrollable frames.
> > 
> > I think the best course of action would be to make iframes fast-scrollable
> > on Mac first, to set up that infrastructure.
> 
> @Simon: I did more analysis on this (see
> https://people.igalia.com/fwang/ios/class-hierarchy/ for my notes) and I
> have some questions/comments:
> 
> 0) Can you elaborate on what you mean by "iframe fast-scrollable on Mac"? I
> understand it means creating scrolling node for the iframe in order to
> handle user interaction in a separate process/thread. Is that correct?

This involves:
1. Creating the right layer hierarchy with tiled backing store for the iframe contents, as we do for the main frame.
2. Creating ScrollingStateFrameScrollingNodes for them
3. Making sure the scrolling tree handles nested ScrollingStateFrameScrollingNodes properly
4. Not putting iframe's ScrollableAreas into the non-fast scrollable region
4. Teaching the scrolling thread to direct a mouse wheel at the appropriate ScrollingTreeFrameScrollingNode
5. Making sure that scroll latching works
6. Probably more

> 1) There are RenderFrame/RenderIFrame::requiresLayer and
> RenderLayerCompositor::requiresCompositingForFrame functions involved in the
> decision of whether the frame will have a RenderLayer or RenderLayerBacking
> attached to the iframe/frame renderer. I believe we should change these
> functions somehow to force that attachment?

Yes, those fast-scrollable frames/iframes will need to be composited in their parent document.

> 2) Similarly, it seems that the condition
> RenderLayer::hasTouchScrollableOverflow (iOS) or
> RenderLayer::needsCompositedScrolling (Mac) to create a scrolling node
> should be changed to take into consideration the frame/iframe.

Those are more for overflow:scroll. I think scrollable frames/iframes would not use this code.

> 3) Repeating comment 14, should we add another ScrollingNodeType for
> iframe/frame? Or re-using an existing one?

Scrolling{State|Tree}FrameScrollingNode should suffice.

> 4) One hesitation I have is whether we want the scrolling node for the
> iframe/frame's renderer itself, or for RenderView attached to the document
> loaded into that iframe/frame?

The scrolling node should get hooked up with the layers inside the frame/iframe, just like for the main page.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170503/335a33b8/attachment.html>