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.
Steps to Reproduce:
1. Go to the website: https://www.uasom.uab.edu/students/selfservice/mygrades.htm
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
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.
Rendered the page correctly.
Does this also happen in Firefox 1.5b1?
(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.
this is a regression from the mozilla1.7 branch. it should be fixed for 1.8
can one of you all provide a simplified testcase for this?
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.
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
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.
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.
Cc-ing some layout folks, maybe they know exactly what should be happening here.
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...
>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
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?"
(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
plussing for now, we need to decide what we're doing here, this is visible on
Windows as well
So I'm looking at bug 295459 comment 6. If we were propagating MEW when
overflow-x is hidden things would work here, right?
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.
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).
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.
can someone enlighten us as to why this should be minused and not fixed?
really this time.
We minused it as a blocker based on the layout experts comments above.
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
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.
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?
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
Minusing and nominating for 1.8.1
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!
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
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.
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.
Really, if this is going to block it should block the RC, not the point release.
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).
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.
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?
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.
For what it's worth, I had fixed this on the reflow branch, but undid it. See bug 359510 for why.
*** Bug 357714 has been marked as a duplicate of this bug. ***
Alright then, I'll make this WONTFIX in sympathy.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008061606 Minefield/3.0pre
The behavior was changed in bug 402567.