227121 - {inc}overflow auto generates bogus vertical scrollbar when overflow condition vanishes

Status: RESOLVED FIXED

(Core :: Layout: Block and Inline, defect)

Description

[Bernd]

see the attached testcase, where the upper div switches from overflow to non
overflow conditions. IE and Opera don't show the vertical scrollbar.

Comment 1

[Bernd]

Attachment: testcase

Comment 2

[Alfonso Martinez]

This test case is WFM using Firefox 1.5 beta2 in wXP

But I have found a remaining scrollbar if both the inner and outer div have position:absolute and I resize the inner div.

I think that this bug can be resolved and I should file a new one with the new testcase, but it's just too much time without working in bugzilla to be sure that I'm not missing anything.

Comment 3

[Alfonso Martinez]

Attachment: Modified testcase with position:absolute

after the 2 seconds timeout the scrollbars remain in the outer div although the inner div now it is smaller.

Comment 4

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

works for me on trunk (Linux). can you post a screenshot?

Comment 5

[Alfonso Martinez]

Attachment: Fixed testcase with both position:absolute

Sorry, the previous testcase was missing position:absolute in the inner div.
Screenshot coming along.

Comment 6

[Alfonso Martinez]

Attachment: screenshot of last testcase in wXP with firefox 1.5beta2

Comment 7

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

Okay, I see it now.

Comment 8

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

Attachment: fix

I believe this is a regression from all the way back in bug 240276. nsScrollBoxFrame used to call SetIncludeOverflow(PR_FALSE) on its child:
http://lxr.mozilla.org/aviary101branch/source/layout/xul/base/src/nsScrollBoxFrame.cpp#310
This would mean that the final width and height of the scrolled frame did not include its overflow area. But when I refactored scrollframes I made HTML scrollframes set the scrolled frame size to include its overflow area. This was a mistake, plain and simple. This patch corrects the mistake. I'm surprised it hasn't bitten us before...

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This doesn't reduce the area we can scroll to in cases like:

<div style="width: 100px; height:100px">
  <div style="width: 1000px; height: 1000px;border:medium solid green">
  </div>
</div>

right?  It's just changing the size of a frame that contributes to the scrollable area?

Comment 10

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

Correct.

We actually don't use the scrolled frame's rect for much. Borders, background, and padding are computed from the scrollframe. The bug here happens because we set the scrolled block's desired size to its current size in the fast path for incrementally reflowing just the absolute children.

Comment 11

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

checked in.

I wonder if this should go in branch, given that it is a layout regression from FF1.0. The risk is pretty low, given comment #10. OTOH the risk is not as low as other patches for which I've requested approval. And I don't know of any sites that are broken by this.

Comment 12

[Alex Robinson]

Attachment: testcase for anchor links within elements set to overflow:hidden

Behaviour in Gecko/20051102 and before:
Clicking on a link to an anchor in an element with large padding-bottom and negative margin-bottom within an element with overflow:hidden causes the contents of the inner element to shift upwards - in the case of sufficiently large values for the padding/margin-bottoms, all the content before the link will
disappear.

Behaviour in Gecko/20051103
Link works as expected and as per other browsers

Comment 13

[Alex Robinson]

Re: Comment #12

The pre-20051103 behaviour essentially rules out the use of anchors within the equal height columns method sketched out in my article here...

   http://www.positioniseverything.net/articles/onetruelayout/equalheight

...since the core of the method is large padding-bottoms balanced with equal amounts of negative margin-bottom wrapped up in a container element whose overflow is set to hidden.

Part of me wonders though whether it is just a happy accident that the fix for bug 227121 also fixes this problem.

Comment 14

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

If you set up a testcase with your layout which contains DHTML or even just tabbable links that you tab to, does the bug trigger?

Comment 15

[Alex Robinson]

No it doesn't as far as I can tell.

Moreover my remark about it perhaps just being a happy accident seems to be right.

It's not a regression from FF1.0. which I should have spotted in the first place and for which I can only apologise

The regression that causes the problem in my test case took place somewhere between Mozilla 1.5  (Gecko/20031007) and Mozilla 1.6a  (Gecko/20031029)

Comment 16

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

is your bug on the FF1.5 branch or not?

Comment 17

[Alex Robinson]

Sorry, no idea. Every 1.5 since 1.5b2 has crashed on my machine. I can only say that it works for sure in SeaMonkey (Gecko/20051103)

Comment 18

[Alex Robinson]

Attachment: Problems with bug fix for PIE's equal height column method

This screenshot shows the rendering of

    http://www.positioniseverything.net/articles/onetruelayout/example/rounded

in Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051108 Firefox/1.6a1 which incorporates the fix proposed for this bug

As  can be seen at

  http://www.positioniseverything.net/articles/onetruelayout/appendix/exampleresults

all modern browsers including FF1 and FF1.5rc1 (or rc2 as far as I can tell) handle the layout just fine.

I would ask strongly that this not be included in the final release for 1.5

Comment 19

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

Alright, noted. Thanks!

Comment 20

[Samuel Sidler (old account; do not CC)]

This may have caused bug 318425.