132156 - Child elements of auto overflow and scroll overflow don't have correct width

Status: VERIFIED FIXED

(Core :: Layout, defect, P2)

Description

[Sebastian Ferreyra]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9+)
Gecko/20020319
BuildID:    2002031903

Child elemnts of fixed positioning and automatic overflow are not always
displayed with the specified width (See attachment) 

Proper behaviour should be that children elements should always mantain the
explicitly specified width set in the style definition.

The problem dissapears partially if fixed positioning is removed (modify source)
and totally if automatic overflow is removed (weird isn't it? :)

Can't compare to IE, it doesnt support fixed pos.


Reproducible: Always
Steps to Reproduce:
see attachment

Comment 1

[Sebastian Ferreyra]

Attachment: testcase

Comment 2

[Sebastian Ferreyra]

Attachment: sample file with problem

Here you can see that the problem applies to all child elements in both the
menu div and the content div

Comment 3

[Boris Zbarsky [:bzbarsky]]

Attachment: Yet another testcase

Comment 4

[Boris Zbarsky [:bzbarsky]]

Attachment: Yet another testcase, take 2

Comment 5

[Boris Zbarsky [:bzbarsky]]

To layout.

This has strong echoes of bug 124431... The presense of overflow:auto is causing
a scrollframe to be created, right?  And that frame seems to think it has zero
width...

overflow:scroll is broken in the same way as overflow:auto here.  The fixed-pos
thing is not relevant -- this happens to any block which gets a scrollframe

Comment 6

[Marc Attinasi]

Thanks bz - accepting to look at.

Anyone know when the regression happened? Looks like NS 6.2 was OK anyway...

Comment 7

[Boris Zbarsky [:bzbarsky]]

The first reports of issues with scrolling=no in frames are with Nov 9, 2001
builds or so.  So awhile back, if this is the same problem.  :(

Comment 8

[Sebastian Ferreyra]

Attachment: interesting testcase

here it works better by not specifying the scrollframewidth

Comment 9

[Boris Zbarsky [:bzbarsky]]

to layout for real...

Comment 10

[Boris Zbarsky [:bzbarsky]]

re-marking as assigned.

Comment 11

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

Is this specific to fixed positioning?  I remember someone (bz?) making a change
to fixed positioning recently related to fix an incremental reflow problem?

Comment 12

[Boris Zbarsky [:bzbarsky]]

David, look at attachment 75093 [details].  It demonstrates this bug with statically
positioned blocks.  The page looks identical in yesterday's nightly (which has
my fixed-pos fix) and 0.9.8 (which does not).

Comment 13

[Boris Zbarsky [:bzbarsky]]

Some investigation shows:

1)  Works in 2001-12-03-08
2)  Broken in 2001-12-04-08

So this is probably not quite the same as the frame problem.  Bug 132256 acts
just like this one, though....

In that time period, the checkins are:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&sortby=Date&hours=2&date=explicit&mindate=12%2F03%2F2001+06%3A00&maxdate=12%2F04%2F2001+09%3A00&cvsroot=%2Fcvsroot

My bets are on evaughan's rewrite of nsBoxToBlockAdaptor reflow.  In fact, the
following patch "fixes" this bug (and likely breaks other things):

Index: xul/base/src/nsBoxToBlockAdaptor.cpp
===================================================================
RCS file: /cvsroot/mozilla/layout/xul/base/src/nsBoxToBlockAdaptor.cpp,v
retrieving revision 1.38
diff -u -r1.38 nsBoxToBlockAdaptor.cpp
--- xul/base/src/nsBoxToBlockAdaptor.cpp        2002/01/30 02:10:14     1.38
+++ xul/base/src/nsBoxToBlockAdaptor.cpp        2002/03/20 18:22:55
@@ -831,6 +832,11 @@
        // place the child and reflow
     mFrame->WillReflow(aPresContext);
 
+    if (reflowState.mComputedWidth == NS_UNCONSTRAINEDSIZE && 
+        reflowState.availableWidth == NS_UNCONSTRAINEDSIZE) {
+      reflowState.availableWidth = aReflowState.mComputedWidth;
+    }
+    
     mFrame->Reflow(aPresContext, aDesiredSize, reflowState, aStatus);
 
     NS_ASSERTION(NS_FRAME_IS_COMPLETE(aStatus), "bad status");

This feels too much like a hack to be right, and maybe the mFrame _should_ be
handling completely unconstrained width somehow...  but based on my meagre
understanding of reflow, having availableWidth and mComputedWidth both be
unconstrained is sorta whacked...

Comment 14

[Boris Zbarsky [:bzbarsky]]

Attachment: height is whacked as well.

Comment 15

[Boris Zbarsky [:bzbarsky]]

So... adding a clause just like the one for width for height helps not at all. 
The width hack helps _some_ of the dependencies of bug 124431 but not all.

Comment 16

[Kevin McCluskey (gone)]

nsbeta1-. Engineers are overloaded with higher priority bugs.

Comment 17

[Boris Zbarsky [:bzbarsky]]

Just as a guess, I'm almost sure that this needs to get fixed to fix bug 124431...

Comment 18

[Andrew Schultz]

this seems to be working with linux build 20020413 (with bug 119849 fixed)

Comment 19

[Boris Zbarsky [:bzbarsky]]

Yep.  I think jkeiser's waiting until he lands on branch to mark all of these
fixed.  :)

Comment 20

[John Keiser (jkeiser)]

Yep :)  Fixed with bug 119849.

Comment 21

[Boris Zbarsky [:bzbarsky]]

*** Bug 119219 has been marked as a duplicate of this bug. ***

Comment 22

[Chris Petersen]

Verified in the April 22nd build (2002-04-22-03).

Comment 23

[Boris Zbarsky [:bzbarsky]]

*** Bug 132947 has been marked as a duplicate of this bug. ***