442682 - Unnecessary scrollbars rendered for 2 floating elements, which leads to a reduced viewport breaking the whole layout.

Status: NEW

(Core :: General, defect)

Description

[Johanna V.]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9) Gecko/2008052906 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9) Gecko/2008052906 Firefox/3.0

When opening a html document (see attachment) containing 2 block elements one of which floats left, ff3 renders them not side by side as it should, but one under the other, although the viewport is wide enough to display both elements together. By the way, FF2 displays such documents without problems.
It seems to be that ff3 attempts to render the document with the vertical scrollbar included and afterwards decides whether the scrollbar is actually needed. This is the wrong strategy, because it leads to the use of an unnecessary scrollbar in such situations, where the viewport ist just big enough to display the content, but not big enough if a scrollbar is included: The unnecessary scrollbar makes itself necessary, just because of the width it takes up.

Reproducible: Always

Steps to Reproduce:
See the attachment.

Comment 1

[Johanna V.]

Attachment: Zipped examples reproducing the bug.

After extracting, open the document testStart.html

Comment 2

[Ria Klaassen (not reading all bugmail)]

Regression range is 
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2006-07-20+14%3A00&maxdate=2006-07-20+23%3A00
Caused by Bug 344861 or bug 343192 or Bug 344696 ?

Comment 3

[Boris Zbarsky [:bzbarsky]]

Probably a regression from bug 344861.

Looks like we used to reflow the window initially at a width forced by the toolbars, then set the correct new width and reflow again.

Now we make sure to hide the toolbars before doing that reflow, which means we're reflowing at whatever the intrinsic size of the XUL is... in this case 138px wide.  We do that, then we reset the size to the correct one.  Shouldn't scrollframe be detecting that it's now wide enough that it could remove the vertical scrollbar?

Comment 4

[Boris Zbarsky [:bzbarsky]]

I guess the height isn't tall enough for the two boxes, so once we get the vertical scrollbar it'll stick around (since we try not changing it first).

I wonder whether we can somehow clear that state on a resize reflow of the scrollframe or something.  It would still make tree-dirty reflows due to changes inside the scrollframe fast, but would prevent the hysteresis we see on the testcase right now: we can increase the window width a bit until both things pop up next to each other, then we can narrow it a good bit from there with them staying next to each other, etc.

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Testcase URL:
jar:https://bugzilla.mozilla.org/attachment.cgi?id=327407!/testStart.html

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to comment #4)
> I wonder whether we can somehow clear that state on a resize reflow of the
> scrollframe or something.

I suppose, but that would slow down window resizing considerably on long documents, wouldn't it?

Comment 7

[Boris Zbarsky [:bzbarsky]]

Hmm.  It might, yeah....

On the other hand, if the document is more than 2x the viewport height we could not worry about changing the vertical scrollbar state, since even if part of it moves up we'll still need the scrollbar (as long as we don't have a whole bunch of things all moving up at once).

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I suppose we could do that, but there would still be edge cases, like if you have three elements each 100px wide, start with the window at 100px wide and then instantly make it 300px wide.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Assuming the elements are all the height of a viewport, yeah.  I'm really not sure we can win on that one.  Perhaps we shouldn't worry about this at all.  On the other hand, if most resizes are by a little bit (e.g. user drag, which does a bunch of resizes), we might be able to get away with the simple heuristic....

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

That's true, except that this bug is about staged reflows with the window size change not caused by user drag.

But I'm happy to implement that heuristic if you think it's worth it in general.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Yeah, I'm not completely sure it is.  I'll think about this a bit more.

Comment 12

[Justin [:JW_SoftvisionQA]]

After testing this issue with the zip file attached, it seems as if this bug has been resolved over time. Are you seeing the same thing on your end?

Comment 13

[Boris Zbarsky [:bzbarsky]]

I can quite clearly reproduce the bug in a current-ish (2016-05-02) Mac nightly: load testStart.html and click the "Show test in a 640px wide window" link and the boxed end up stacked vertically.  Note that I have my scrollbars set to not do the weird "disappear when not being used" thing Mac does by default.

Comment 14

[Justin [:JW_SoftvisionQA]]

Ok, I was not sure if that 1 test case was intended to be stacked or not. All other test cases are side by side.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Yes, the bug is precisely that they are not all side by side.  Comment 0 says that clearly.