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

[bugzilla-daemon at webkit.org]

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

            Bug ID: 179735
           Summary: window.scrollTo is initially unclamped on iOS
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: HTML DOM
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: ajuma at chromium.org
                CC: cdumez at apple.com, danyao at chromium.org,
                    fred.wang at free.fr, simon.fraser at apple.com,
                    thorton at apple.com

The inputs to window.scrollTo aren't clamped to the min/max scroll positions by WebCore when ScrollView::delegatesScrolling is true, so window.scrollX and window.scrollY return possibly out-of-bounds values until WebCore receives adjusted values from the UI process. For example:

window.scrollTo(0, 1000000);
var scrollPos = window.scrollY;
// scrollPos is 1000000 even if the page is much smaller than that

window.scrollTo(-100, 0);
scrollPos = window.scrollX;
// scrollPos is -100 even though that's not a valid scroll offset

This behavior comes from the patch for bug 132879, which stopped clamping in ScrollView::setScrollPosition with the justification that the Web process shouldn't be clamping since it might have stale information.

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

-- 
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/20171115/68fea296/attachment-0001.html>