Last Comment Bug 309110 - Shrinkwrap width of 'auto' width block with overflow:hidden is 0
: Shrinkwrap width of 'auto' width block with overflow:hidden is 0
: regression, testcase
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: All All
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: 357714 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2005-09-18 21:24 PDT by Travis
Modified: 2008-06-27 05:04 PDT (History)
14 users (show)
mconnor: blocking1.8b5-
asa: blocking1.8rc1-
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

This is the code from the affect page. (76.07 KB, text/html)
2005-09-23 14:20 PDT, Travis
no flags Details
Testcase (551 bytes, text/html)
2005-09-25 06:04 PDT, Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( )
no flags Details
Testcase2, using overflow:hidden (550 bytes, text/html)
2005-09-25 06:09 PDT, Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( )
no flags Details
testcase3, using overflow:visible (551 bytes, text/html)
2005-09-25 06:19 PDT, Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( )
no flags Details

Description Travis 2005-09-18 21:24:52 PDT
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050914 Camino/1.0a1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050914 Camino/1.0a1

In the page at,
the spreadsheet-like report is compressed on the left side of the browser
window.  This page loads correctly using Camino 0.84.

Reproducible: Always

Steps to Reproduce:
1. Go to the website:
2. Log in with my user name/Password (can give to an appropriate Mozilla
employee if contacted directly).
3. Click the link:
4.  Page is rendered incorrectly

Actual Results:  
Page renders, but the entire output is compressed onto the left side of the
page, and is unreadable.  Would not be a problem if this had not worked in
Camino 0.84 also.

Expected Results:  
Rendered the page correctly.
Comment 1 Smokey Ardisson (offline for a while; not following bugs - do not email) 2005-09-19 11:24:28 PDT
Does this also happen in Firefox 1.5b1?
Comment 2 Travis 2005-09-19 17:19:04 PDT
(In reply to comment #1)
> Does this also happen in Firefox 1.5b1?

This also happens in Firefox 1.5b1, but does not happen in Firefox 1.0.6.
Comment 3 Wevah 2005-09-19 19:33:34 PDT
-> Core
Comment 4 Mike Pinkerton (not reading bugmail) 2005-09-20 07:21:19 PDT
this is a regression from the mozilla1.7 branch. it should be fixed for 1.8
Comment 5 Mike Pinkerton (not reading bugmail) 2005-09-20 07:21:44 PDT
-> core
Comment 6 Asa Dotzler [:asa] 2005-09-22 10:58:41 PDT
can one of you all provide a simplified testcase for this?
Comment 7 Travis 2005-09-23 14:20:15 PDT
Created attachment 197207 [details]
This is the code from the affect page.

This is the code that renders incorrectly in Camino 1.0a1 and Firefox 1.5b1,
but renders correctly in Camino 0.8.4 and Firefox 1.0.6.
Comment 8 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2005-09-25 06:04:02 PDT
Created attachment 197325 [details]

This is a minimal testcase based on that code.
The only reason why this regressed is because Mozilla1.7 doesn't support
Comment 9 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2005-09-25 06:09:05 PDT
Created attachment 197328 [details]
Testcase2, using overflow:hidden

So, when using overflow:hidden, you get similar results in Mozilla1.7 and
IE6 is doing things differently, it does show the text (but that might very
well be a bug).

But I think I see a bug with testcase1, I don't see the small table cell with
1px solid black border on the left, like I see it in testcase2.
Comment 10 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2005-09-25 06:19:12 PDT
Created attachment 197330 [details]
testcase3, using overflow:visible

But then, testcase3 does show the text in current trunk builds, and I see no
reason why testcase1 or testcase2 should render differently.
Comment 11 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2005-09-25 06:25:16 PDT
Cc-ing some layout folks, maybe they know exactly what should be happening here.
Comment 12 Boris Zbarsky [:bz] 2005-09-25 07:54:09 PDT
This looks like the div is reporting a different min-width depending on whether
it's got a scrollframe or not, basically.  So if there is no scrollframe we have
a min-width equal to the width of the longest word, and if there is a
scrollframe we get a min-width of 0.

I'm pretty sure we already have a bug on that...
Comment 13 Bernd 2005-09-25 08:01:07 PDT
>I'm pretty sure we already have a bug on that...

Its not a bug its a feature.

How much can we squeze a auto scrollable around some content?
Down to 0, I believe, as it can scroll the content. I checked this in with bug
Comment 14 Boris Zbarsky [:bz] 2005-09-25 08:12:13 PDT
Hmm..  But we can squeeze a non-scrollable down too -- the content will just
overflow.  I guess this is the cell trying to prevent overflow out of itself, huh?

I hate to ask this, but "what does IE do?"
Comment 15 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2005-09-25 09:18:22 PDT
(In reply to comment #14)
> I hate to ask this, but "what does IE do?"
IE6 is doing in all 3 testcase the same as Mozilla is doing in "testcase3, using
Comment 16 Mike Connor [:mconnor] 2005-09-26 22:34:16 PDT
plussing for now, we need to decide what we're doing here, this is visible on
Windows as well
Comment 17 Boris Zbarsky [:bz] 2005-09-27 06:36:15 PDT
So I'm looking at bug 295459 comment 6.  If we were propagating MEW when
overflow-x is hidden things would work here, right?
Comment 18 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-09-27 10:28:28 PDT
We deliberately set the MEW of overflow:hidden to zero, for compatibility with
1.7/FF1.0.6. Martijn says in comment #8 this only appears to be a regression
because we didn't support overflow-x before. Changing this decision would reopen
bug 295459 and possibly bug 292690. I don't see any other rational way to fix this.

It appears Opera 8.5 is also setting overflow:hidden MEW to zero.

I propose we do not change this unless the CSS WG hands down a decision
resolving the issue differently.
Comment 19 Boris Zbarsky [:bz] 2005-09-27 10:49:37 PDT
If we decide we really want to hack this, we could propagate the MEW only if
horizontal overflow is hidden and vertical is not...  But that would be only if
this becomes a huge compat issue (which I'm not seeing thus far).
Comment 20 Hixie (not reading bugmail) 2005-09-28 13:25:20 PDT
Bug 295459 comment 6 is right as far as I can tell. The 'overflow' property
shouldn't affect layout in cases like this. Why would it? I don't understand
what in the CSS spec would suggest that the shrink-wrap width of a block would
change based on its 'overflow' property.
Comment 21 Mike Pinkerton (not reading bugmail) 2005-09-28 16:04:07 PDT
can someone enlighten us as to why this should be minused and not fixed?

requesting re-triage.
Comment 22 Mike Pinkerton (not reading bugmail) 2005-09-28 16:04:26 PDT
really this time.
Comment 23 Asa Dotzler [:asa] 2005-09-29 11:49:59 PDT
We minused it as a blocker based on the layout experts comments above.
Comment 24 Hixie (not reading bugmail) 2005-09-29 16:40:32 PDT
Well I don't know if it should be a blocker, but IMHO the layout experts above
were wrong (as dbaron stated in the comment cited above by myself and bz).

roc, could you take a look at my comment above and let me know if we're missing
something? Thanks...
Comment 25 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-09-30 11:09:23 PDT
I agree that in principle we should be propagating the MEW. That's what I did
originally when I rewrote scrollframes. But I don't think we should change it
now for the FF1.5 release. I'm willing to revert back for the trunk and then we
can reopen and readdress bug 295459 and any others.
Comment 26 Mike Pinkerton (not reading bugmail) 2005-09-30 11:47:25 PDT
regardless of the timing of FF1.5, i'm just concerned about sites that used to
work now no longer working. That's not the kind of thing that will improve
adoption. Is there any way to help this in the short term?
Comment 27 Mike Connor [:mconnor] 2005-09-30 12:47:19 PDT
Per triage meeting: 

There really isn't time to really take a shot at trying to fix this for 1.8,
given the size of the original patch, and the fallout from that, and that roc is
travelling at present.  Feedback from reporter and other tools suggests this is
quite low-impact.

Minusing and nominating for 1.8.1
Comment 28 Hixie (not reading bugmail) 2005-09-30 13:28:48 PDT
Here I was thinking we were trying to ship a quality product, but it turns out
we're just a date-driven development team. My bad!
Comment 29 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-09-30 13:31:54 PDT
AFAIK This is only a "regression" for pages that use overflow-x and overflow-y
(not overflow) on elements that rely on the MEW being propagated. In FF1.0 those
properties were just ignored so it's as likely such sites got better rather than
Comment 30 Hixie (not reading bugmail) 2005-09-30 14:02:02 PDT
The bug appears on any page that has something with overflow:hidden in a table
cell. I agree that this isn't really a regression, but it's sad that we are
going to release a product that renders some pages worse than it used to. 1.5
has very few new features as it is, I don't know how much we can afford to be
breaking pages. And IMHO it's especially sad that the main reason given for
shipping with this is related to scheduling.

Resummarising in light of comments.
Comment 31 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-09-30 14:41:14 PDT
It's inevitable that 1.5 will render a few pages worse than 1.0 did. However, it
renders very many pages much better than 1.0 did.

If you want to make the case to branch-drivers that it's worth changing this for
FF, be my guest. I'll be able to work on it late next week.
Comment 32 Samuel Sidler (old account; do not CC) 2005-10-07 12:10:53 PDT
Really, if this is going to block it should block the RC, not the point release.

Requesting blocking1.8rc1.
Comment 33 Asa Dotzler [:asa] 2005-10-11 16:31:26 PDT
not going to block on this. not a critical problem for 1.5. we have a number of
issues where we don't render the same as 1.0 (some that impact many more pages
or higher profile pages than this).
Comment 34 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2006-02-14 09:31:20 PST
I think I agree that 'overflow' shouldn't affect the intrinsic width, at least in this simple a way (it has more complex effects because of the establishment of a block formatting context), but that is a pretty big change from what we've done in the past.
Comment 35 Eli Friedman 2007-06-18 13:47:25 PDT
Fixing this would be relatively easy at this point... it's just a matter of changing the implementation of nsHTMLScrollFrame::GetMinWidth.  The question here is what behavior we want.  Do we want an implementation like nsHTMLScrollFrame::GetPrefWidth?
Comment 36 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2007-06-20 12:06:16 PDT
It's entirely a spec question. On balance I think we should follow Hixie (and apparently, IE, which gives me confidence that web compat will be OK) and pass through the intrinsic width, the way that GetPrefWidth does.
Comment 37 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2007-06-23 13:37:45 PDT
For what it's worth, I had fixed this on the reflow branch, but undid it.  See bug 359510 for why.
Comment 38 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2007-06-23 13:39:49 PDT
*** Bug 357714 has been marked as a duplicate of this bug. ***
Comment 39 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2007-06-24 15:26:01 PDT
Alright then, I'll make this WONTFIX in sympathy.
Comment 40 Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m) 2008-06-17 05:38:58 PDT
Currently WFM.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008061606 Minefield/3.0pre
Comment 41 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2008-06-27 05:04:57 PDT
The behavior was changed in bug 402567.

Note You need to log in before you can comment on or make changes to this bug.