When the browser window crops a container that has its dimensions based on liquid elements, a scroll bar spacer appears before the scroll bar itself. I have produced a sample test case here: http://pastie.org/236769 there is also an associated video that I have uploaded so that you can see the bug in action: http://vimeo.com/1365917 Many thanks
actually, download the video here: http://www.box.net/shared/mqm7b3sw0s
Created attachment 22476 [details] Test case for scroll bug there is also a video of this bug in action here: http://vimeo.com/1366292
Created attachment 22624 [details] Change in updateScrollers algorithm The current algorithm for calculating if the scrollbars should be shown misbehaves in this case. The page is constructed such that its height is dependent on its with, so when the window is made smaller, the vertical scrollbar is needed. But with a re-layout, the page shrinks, and the vertical scrollbar is no longer needed. But after this, a re-layout is not made, and white bars show up around the page. I have written an algorithm that detects these scrollbar on/off loops explicitly, and then uses all scrollbars needed at each point in the loop. It then re-layouts the page. This will show up as unusable scrollbars in some cases, i.e. no blue part. But I believe this is a better solution than the previous algorithm. Due to this, some testcases have changed their output for me. When I have looked at them, they seem to still be good, but the scrollbar behavior has changed, and therefore their rendertree. On my build they are: accessibility/bounds-for-range.html css2.1/t0803-c5502-mrgn-r-02-c.html css2.1/t0803-c5505-mrgn-02-c.html fast/block/float/013.html fast/flexbox/016.html fast/lists/001.html svg/webarchive/svg-script-subresouces.svg
Watching the vimeo video makes the bug clear. I guess Hyatt is probably the first person to ask to comment on a scrollbar bug?
Comment on attachment 22624 [details] Change in updateScrollers algorithm Assigning to hyatt for comment. Obviously anyone who feels comfortable with this code should feel welcome to review this.
Comment on attachment 22624 [details] Change in updateScrollers algorithm A change to this algorithm will require extensive testing. I can't r+ this without some kind of testing plan / test cases.
Also note this algorithm is duplicated on other platforms, so they all need to be changed to be kept in sync.
I would encourage you to make a DumpRenderTree compatible test case which shows this bug (a single web page which when loaded shows this bug). That's probably possible using an iframe sized to a certain size. The test case should be stand-alone and all the required files should be possible to add to LayoutTests: http://trac.webkit.org/browser/trunk/LayoutTests/ More information about writing tests can be found here: http://webkit.org/quality/testwriting.html I'm sure that we already have some amount of Scrolling test cases. Those will be run whenever you use "run-webkit-tests". Your new test case(s) would also be run by run-webkit-tests when you place them in LayoutTests/
Created attachment 22684 [details] Test case for scroll bug, placed within iframe As requested, here is a test case that demonstrates the scroll-bar bug on page load (without having to resize the page. FYI, FF3 has problems with this as well
When you access the attachment #22684 [details] (2008-08-06) from the link within comment #9, or from the attachment table the bug does not appear and seems resolved. Instead, if you save the page source as html and open it fresh, the bug is correctly demonstrated. go figure. thanks, phillip
Safari, Chrome, and Firefox show the same rendering behavior for this test case. I do not believe any further compatibility issue remains.
<rdar://problem/96849827>