Closed Bug 35681 Opened 24 years ago Closed 23 years ago
[REGRESSION] HTML is sized too wide
173 bytes, text/html
1.59 KB, text/html
2.77 KB, patch
|Details | Diff | Splinter Review|
193 bytes, text/html
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
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
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. ***
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).
Status: NEW → ASSIGNED
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 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
*** 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
I'm currently working on this one. Hopefully I will have fix tomorrow.
approving for nsbeta2
*** Bug 37374 has been marked as a duplicate of this bug. ***
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.
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: http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/background/ They may be of use.
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 specs...).
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 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.
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?
Status: ASSIGNED → RESOLVED
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. ***
David, 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.
Status: RESOLVED → 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.
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 http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/horizgrowth.html
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? Gerv
Removing mostfreq. I believe all of the duplicates are fixed. Really, a new bug should have been filed rather than reopening this one.
*** 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 ***
Status: REOPENED → RESOLVED
Closed: 24 years ago → 23 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.)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.