Closed Bug 35681 Opened 25 years ago Closed 24 years ago

[REGRESSION] HTML is sized too wide


(Core :: Layout, defect, P3)






(Reporter: troy, Assigned: eric)




(Keywords: css1, regression, testcase, Whiteboard: [nsbeta2-][dogfood-][nsbeta3-])


(4 files)

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
Attached file Test case
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
Keywords: regression
Summary: Body is sized too wide → [REGRESSION] Body is sized too wide
*** Bug 35572 has been marked as a duplicate of this bug. ***
*** Bug 34731 has been marked as a duplicate of this bug. ***

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).
Target Milestone: --- → M16
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 

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
*** Bug 36338 has been marked as a duplicate of this bug. ***
*** Bug 35369 has been marked as a duplicate of this bug. ***
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...)
Severity: normal → major
Keywords: nsbeta2
I'm currently working on this one. Hopefully I will have fix tomorrow.
Whiteboard: [nsbeta2+]
approving for nsbeta2
*** Bug 37374 has been marked as a duplicate of this bug. ***
* 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.
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.

*** Bug 15405 has been marked as a duplicate of this bug. ***
The bug marked as duplicate above is about the root element being too high, so
both issues need to be tested separately when verifying.
A whole stack of related test cases, including many that fail :-(, are here:
They may be of use.
Keywords: testcase
Blocks: 40158
Mass-moving undated nsbeta2+ bugs to M18
Target Milestone: M16 → M18
*** Bug 41410 has been marked as a duplicate of this bug. ***
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 
Priority: P3 → P1
*** Bug 42790 has been marked as a duplicate of this bug. ***
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 , (the top of the 
page), (the bottom of 
the page), or in mozilla.

Nominating for dogfood.
Keywords: dogfood
Putting on [nsbeta2+][dogfood-] radar.  Does not need a fix
ASAP for daily work, but we should fix this for beta2. 
Whiteboard: [nsbeta2+] → [nsbeta2+][dogfood-]
eric, you checked this in right?
Closed: 24 years ago
Resolution: --- → FIXED
*** Bug 44287 has been marked as a duplicate of this bug. ***
*** Bug 43181 has been marked as a duplicate of this bug. ***
*** Bug 40407 has been marked as a duplicate of this bug. ***

Your attached DIV test case appears to render correctlty in the July 10th build 
(2000071008). Can you verify this as well ?
Looks like problem has been fixed in the July 11th builds. Marking verified.
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.
Keywords: nsbeta3
OS: Windows NT → All
QA Contact: petersen → py8ieh=bugzilla
Hardware: PC → All
Resolution: FIXED → ---
agreed, plussing and cc'ing jrgm 
Whiteboard: [nsbeta2+][dogfood-] → [nsbeta2+][dogfood-][nsbeta3+]
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?
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
Summary: [REGRESSION] Body is sized too wide → [REGRESSION] HTML is sized too wide
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.
That test case has white-space:pre content, which is the same as a long word.
See the PRE test.
I'm trying to say that it's not the same.  Try adding the test...
Per PDT PR2 bug review, this reopened bug set to [nsbeta2-], [nsbeta3+] already
on radar.
Whiteboard: [nsbeta2+][dogfood-][nsbeta3+] → [nsbeta2-][dogfood-][nsbeta3+]
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.  
Priority: P1 → P3
No time left for this, will have to fix in Beta5, aks 6.0.1.  nsbeta3-/future.  
Whiteboard: [nsbeta2-][dogfood-][nsbeta3+] → [nsbeta2-][dogfood-][nsbeta3-]
Target Milestone: M18 → Future
11 duplicates: mostfreq

Minusing this one doesn't look at all good. :-(
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?

Removing mostfreq.  I believe all of the duplicates are fixed.  Really, a new
bug should have been filed rather than reopening this one.
Keywords: mostfreq
*** Bug 51197 has been marked as a duplicate of this bug. ***
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 ***
Closed: 24 years ago24 years ago
Resolution: --- → DUPLICATE
*** Bug 36338 has been marked as a duplicate of this bug. ***
setting QA to dbaron for rubber-stamp verify
QA Contact: ian → dbaron
OK, verified as duplicate.  (Although it's really fixed, since the regression
this bug describes is fixed.)
You need to log in before you can comment on or make changes to this bug.