Bug 20103 – Scroll bar spacer appears before scroll bar itself (when height it based on liquid elements)

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: CSS

[Phillip Sauerbeck]

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

[Phillip Sauerbeck]

actually, download the video here: http://www.box.net/shared/mqm7b3sw0s 

[Phillip Sauerbeck]

Created attachment 22476 [details]
Test case for scroll bug

there is also a video of this bug in action here: http://vimeo.com/1366292

[Arne]

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

[Eric Seidel (no email)]

Watching the vimeo video makes the bug clear.  I guess Hyatt is probably the first person to ask to comment on a scrollbar bug?

[Eric Seidel (no email)]

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.

[Dave Hyatt]

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.

[Dave Hyatt]

Also note this algorithm is duplicated on other platforms, so they all need to be changed to be kept in sync.

[Eric Seidel (no email)]

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/

[Phillip Sauerbeck]

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

[Phillip Sauerbeck]

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

[Brent Fulgham]

Safari, Chrome, and Firefox show the same rendering behavior for this test case. I do not believe any further compatibility issue remains.

[Radar WebKit Bug Importer]

<rdar://problem/96849827>