[Webkit-unassigned] [Bug 174902] New: Incorrect scroll position when using a overflow auto and non-overlay scrollbars

[bugzilla-daemon at webkit.org]

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

            Bug ID: 174902
           Summary: Incorrect scroll position when using a overflow auto
                    and non-overlay scrollbars
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Layout and Rendering
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: cgarcia at igalia.com
                CC: bburg at apple.com, bfulgham at webkit.org,
                    simon.fraser at apple.com, thorton at apple.com,
                    zalan at apple.com

Created attachment 316553

  --> https://bugs.webkit.org/attachment.cgi?id=316553&action=review

Test case

I've noticed this with the attached file, that is used in selenium WebDriver tests (I modified it only to do scrollIntoView on load). In GTK+ port loading the test with non-overlay scrollbars the link ends up under the horizontal scrollbar. When using the Mac MiniBroeser, the links is at the right position on load, but just resizing the window a little makes it disappear. This is because in the case of GTK+, for some reason, after the RenderLayer::scrollTo() that uses the right offset, there's another layout, that causes the main frame contents size to be recalculated and then a second RenderLayer::scrollTo() is called now with the wrong offset. In the case of Mac, resizing the window causes the second layout needed to trigger the bug. The problem seems to be that the first time the frame view contents size doesn't take into account the scrollbars space, and then the offset needed to make the link visible is correct. But after the scrollbars are shown, the frame view contents size is updated taking into account the scrollbars space making it fit into the full visible area. That causes the scrollbars to be destroyed, so when the scroll offset is calculated again, there aren't scrollbars and the offset we get is without the scrollbars. At some point the contents size is updated again, and the scrollbars are added again.

-- 
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/20170727/5b4c5b21/attachment.html>