[Webkit-unassigned] [Bug 179735] window.scrollTo is initially unclamped on iOS

[bugzilla-daemon at webkit.org]

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

--- Comment #4 from Ali Juma <ajuma at chromium.org> ---
(In reply to Frédéric Wang (:fredw) from comment #3)
> (In reply to Ali Juma from comment #0)
> > I wonder if a better approach might be to continue sending an unclamped
> > scroll offset to the UI process, but in the meanwhile use a clamped scroll
> > offset to update FrameView's scroll position. That would mean changing
> > AsyncScrollingCoordinator::requestScrollPositionUpdate to take both a
> > clamped and an unclamped offset, so that it can use the clamped version for
> > the call to updateScrollPositionAfterAsyncScroll (which is what updates
> > FrameView's scroll offset).
> 
> @Ali: How about just putting back the clamping for programmatic scroll? i.e.
> 
> -    ScrollPosition newScrollPosition = !delegatesScrolling() ?
> adjustScrollPositionWithinRange(scrollPosition) : scrollPosition;
> +    ScrollPosition newScrollPosition = (!delegatesScrolling() ||
> inProgrammaticScroll()) ? adjustScrollPositionWithinRange(scrollPosition) :
> scrollPosition;
> 
> What would be the problem if programmatically-set position overrides the one
> in the UI process?

The problem would be that the WebProcess may not have up-to-date information about the size of the view, so we might clamp incorrectly. For example, the view might have shrunk, increasing the maximum scroll offset. I think you're right that for JS-driven scroll, we're fine to clamp since JS can't make assumptions about when resize happens in the UI, but I'm not sure that extends to all programmatic scrolls, since inProgrammticScroll() seems to be broader than just JS-driven scroll. The use case in the bug that removed the clamping (bug 132879) sounds like a programmatic scroll.

-- 
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/20180214/cf416755/attachment-0001.html>