[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 #16 from Frédéric Wang (:fredw) <fred.wang at free.fr> ---
(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?

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?

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.

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

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?

Thanks

-- 
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/18b91f96/attachment.html>