Created attachment 316553 [details] 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.
I don't know if it would be possible to detect that scrollbars will always be used in that particular case.
There was only one test (imported/selenium/py/test/selenium/webdriver/common/click_scrolling_tests.py:testShouldBeAbleToClickOnAnElementHiddenByDoubleOverflow) referring this bug in WebDriver/TestExpectations.json. The entry was deleted as part of https://trac.webkit.org/changeset/259791/webkit, since the test was passing. Closing bug.
<rdar://problem/61580604>