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 https://dados.uasom.uab.edu/Reportserver?%2fUASOM+Student+Self+Service%2frpt009&rs:Command=Render, 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: 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: https://dados.uasom.uab.edu/Reportserver?%2fUASOM+Student+Self+Service%2frpt009&rs:Command=Render 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.

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.

-> Core

this is a regression from the mozilla1.7 branch. it should be fixed for 1.8

-> core

can one of you all provide a simplified testcase for this?

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.

This is a minimal testcase based on that code. The only reason why this regressed is because Mozilla1.7 doesn't support overflow-x:hidden.

So, when using overflow:hidden, you get similar results in Mozilla1.7 and Opera8.5 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.

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 295459

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 overflow:visible".

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? requesting re-triage.

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 something? Thanks...

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 quite low-impact. 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 worse.

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. Requesting blocking1.8rc1.

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.

Alright then, I'll make this WONTFIX in sympathy.

Currently WFM. 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.