35681 - [REGRESSION] HTML is sized too wide

Status: VERIFIED DUPLICATE of bug 57906

(Core :: Layout, defect, P3)

Description

[troy]

Eric, a fairly recent change to the scrollframe code (I believe) has caused a 
regression where when the BODY has content that extends outside of its content 
area the BODY element's frame is getting sized as wide as the content.

This should not happen. The content that overflows should be subject to the 
'overflow' policy of the parent element

I'm attaching a test case that demonstrates the problem. Size the window narrow 
enough so that the one very large word doesn't fit and you'll see that the BODY 
element's borders go past the width of the window and cover the overflowing 
content as well

That's not how it should work in CSS. Because the BODY's width is specified as 
'auto' it is computed based on the display width, and that is the final value. 
Regardless of whether content overflows

Comment 1

[troy]

Attachment: Test case

Comment 2

[troy]

What I noticed when debugging it is that the first time the BODY is reflowed the 
reflow state has the correct "availableWidth" value. However, what happens is 
that the BODY returns an overflow width that exceeds the window width. The 
canvas frame then sizes itself to that width.

That causes a horizontal scrollbar to be needed and so a second reflow seems to 
happen (why is this happening?), and the next time the BODY is reflowed it is 
given an "availableWidth" that is considerably larger. It looks to be the size 
of the BODY's overflow area

That causes the BODY to ask for all of the available space

Comment 3

[troy]

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

Comment 4

[troy]

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

Comment 5

[Eric Vaughan]

Troy,

I'm a little confused on this one. It looks like the body does NOT have 
overflow: auto so the scrollbars are are outside the body tags borders. But IE 
has the scrollbars inside the body borders. 

So if I understand you correctly. If the body is not auto or scroll and its 
content overflows its text should just splill out of its borders (And of course 
if its overflow hidden it will clip).

Comment 6

[troy]

IE does things wrong, and so does Nav. What browsers used to do is expand the 
width of the BODY (and HTML) elements so they enclosed the width of their widest 
element, i.e., if there is a really big word that is 1000px wide and the display 
width of the viewport is only 750px then the BODY's width is expanded to 1000px

That's wrong according to CSS2, and the element's width is its computed width 
as calculated top-down based on the display width of the viewport

Then the 'overflow' policy is used to determine what happens to content that 
overflows.

It's the viewport that's actually scrolled by default (both 'body' and 'html' 
are 'auto' for 'width'). The canvas frame (currently called "root frame" but 
that name reflects a previous model and I need to change it) is sized as wide as 
the overflow area of the document element's frame

This used to work and was broken recently I think

Comment 7

[troy]

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

Comment 8

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

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

Comment 9

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

This is a major regression that causes lots of pages to be hard to read
(especially when one's browser width is small).  See some of the duplicates. 
Changing severity to major and nominating for beta2.

I think essentially what is supposed to happen is that things should act as
though the viewport has 'overflow: scroll' (although I'm not sure if the
viewport frame is the right one here...).  Therefore, the width of the element
that triggers the scrolling should not be widened by its overflowing content.

This problem occurs for any frames that scroll.  I will attach a testcase that
demonstrates the problem for a DIV element with 'overflow: auto'.  The same
thing holds true for the viewport (or whatever frame it is that picks up the
scrollbars for the document).  (The testcase also shows incorrect height
computation, but that should probably be a separate bug...)

Comment 10

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

Attachment: testcase showing problems on a DIV

Comment 11

[Eric Vaughan]

I'm currently working on this one. Hopefully I will have fix tomorrow.

Comment 12

[msanz]

approving for nsbeta2

Comment 13

[Masatoshi Kimura [:emk]]

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

Comment 14

[Masatoshi Kimura [:emk]]

Attachment: Proposed patch

Comment 15

[Masatoshi Kimura [:emk]]

Description:
* nsBoxToBlockAdaptor.cpp, line 703-719 - we should not reflow when child's
  bounds overflow.
* nsScrollPortFrame.cpp, line 324-328 - we should use scroll area width rather
  than the scrolled content width.

Comment 16

[Eric Vaughan]

Unfortunately this patch won't work because boxes do not work like HTML. If a 
box contains html it will size the child to its size + its overflow. That way 
text in a box won't leak out. But overflow of divs and the body should not 
include the overflow in the same way. They should be size and the overflow 
taken into account in the scrollport only. I did some work on this. The idea it 
to make a switch on the adaptor to tell it which one to do. But I got pulled off 
on higher priority bugs. I'll get back and fix this as soon as I can.

Comment 17

[Eric Vaughan]

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

Comment 18

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

The bug marked as duplicate above is about the root element being too high, so
both issues need to be tested separately when verifying.

Comment 19

[Hixie (not reading bugmail)]

A whole stack of related test cases, including many that fail :-(, are here:
   http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/background/
They may be of use.

Comment 20

[Peter Trudelle]

Mass-moving undated nsbeta2+ bugs to M18

Comment 21

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

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

Comment 22

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

Raising to P1.  This is practically a dogfood issue - it makes it impossible to 
read certain pages in the browser (particularly technical documents, like W3C 
specs...).

Comment 23

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

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

Comment 24

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

What's the status of this bug?  evaughan said he'd have a fix "tomorrow" on 
April 19.  This is probably the most serious CSS compliance bug in the product 
in terms of its practical effect on pages.  This bug makes it very difficult to 
impossible to read pages such as http://www.mozilla.org/status/2000-06-08.html , 
http://www.people.fas.harvard.edu/~dbaron/css/test/results (the top of the 
page), http://www.bath.ac.uk/%7Epy8ieh/cgi/listresults.pl?ID=ETS (the bottom of 
the page), or
http://www.cira.colostate.edu/Special/CurrWx/g8full1.htm in mozilla.

Nominating for dogfood.

Comment 25

[Jay Patel [:jay]]

Putting on [nsbeta2+][dogfood-] radar.  Does not need a fix
ASAP for daily work, but we should fix this for beta2. 

Comment 26

[Blake Ross]

eric, you checked this in right?

Comment 27

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

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

Comment 28

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

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

Comment 29

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

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

Comment 30

[Chris Petersen]

David,

Your attached DIV test case appears to render correctlty in the July 10th build 
(2000071008). Can you verify this as well ?

Comment 31

[Chris Petersen]

Looks like problem has been fixed in the July 11th builds. Marking verified.

Comment 32

[Hixie (not reading bugmail)]

Attachment: Test case showing the problem on the root element (HTML)

Comment 33

[Hixie (not reading bugmail)]

REOPENing. This is still happening for the HTML element. Chris Waterson just 
ran into it for some DOM bug on which he is working.

Nominating nsbeta3, as this got nsbeta2+ and is a serious spec compliance issue.

Comment 34

[Peter Trudelle]

agreed, plussing and cc'ing jrgm 

Comment 35

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

Ian - I think the new case is a different problem and is not specific to BODY. 
We take the 'min-width' rules in the spec loosely and expand blocks if *inline*
content overflows.  Perhaps we shouldn't do it, or shouldn't do it just for the
root element?

Comment 36

[Hixie (not reading bugmail)]

We should never be changing the size of static, in-flow block level elements
based on their contents, ever, should we???

If we do do this then it is very invalid. But I don't think we do, as can be
seen on http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/horizgrowth.html

Comment 37

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

Ian - that test doesn't have any really long words.  I think we expand for
inline content (including images?), but not block content.  I also think this is
what Haakon thinks is the right thing to do, although he probably hasn't
considered this case.

See also bug 12750.

Comment 38

[Hixie (not reading bugmail)]

That test case has white-space:pre content, which is the same as a long word.
See the PRE test.

Comment 39

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

I'm trying to say that it's not the same.  Try adding the test...

Comment 40

[leger]

Per PDT PR2 bug review, this reopened bug set to [nsbeta2-], [nsbeta3+] already
on radar.

Comment 41

[Peter Trudelle]

Changing priority to P3 (please note: assigned engineering team owns the
priority field).  Eric, if this is correctly assigned, please Accept it,
otherwise, please reassign it.  

Comment 42

[Peter Trudelle]

No time left for this, will have to fix in Beta5, aks 6.0.1.  nsbeta3-/future.  

Comment 43

[Henri Sivonen (:hsivonen)]

11 duplicates: mostfreq

Minusing this one doesn't look at all good. :-(

Comment 44

[Gervase Markham [:gerv]]

I can't add this bug to the mostfreq list without an up-to-date summary, as I 
can't work out what it's now about. Henri?

Gerv

Comment 45

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

Removing mostfreq.  I believe all of the duplicates are fixed.  Really, a new
bug should have been filed rather than reopening this one.

Comment 46

[Asa Dotzler [:asa]]

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

Comment 47

[Hixie (not reading bugmail)]

To remove any confusion that was reigning above, I have filed bug 57906 with
some new test cases. Marking this as DUP.

*** This bug has been marked as a duplicate of 57906 ***

Comment 48

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

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

Comment 49

[Hixie (not reading bugmail)]

setting QA to dbaron for rubber-stamp verify

Comment 50

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

OK, verified as duplicate.  (Although it's really fixed, since the regression
this bug describes is fixed.)