See upcoming testcase. This worked in 2005-04-28 build, it fails in 2005-04-29 build: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-04-28+07%3A00%3A00&maxdate=2005-04-29+10%3A00%3A00&cvsroot=%2Fcvsroot I think this behavior changed because of the fix for bug 240276.

Comment on attachment 184517 [details] [diff] [review] patch IMHO the code from bug 240276 and the fixup from bug 292370 is wrong. A scrollframe can be squezed if it is not fixed width and should not pay attention to its content MEW.

Martijn, could you test this patch?

The patch works great. It fixes this testcase, and all the testcases of bug 292690. Also the various url's mentioned in that bug also seem fixed. I've not seen any problems with the patch with some marquee examples on the internet. And "GMail Compose mail" still looks good with the patch.

So, I really think we should be propagating MEW through for normal 'overflow' cases. What sites are broken by this problem that don't have MARQUEE? Does WinIE's behavior differ between values of 'overflow'? I'd be surprised if it doesn't propagate MEW through 'overflow:hidden'.

So the testcase matrix shows that this patch reverts the MEW behaviour back to what it was before (see the testcases with FF 1.04). I heavily doubt that we should follow the IE path which shows for *non* of the blocks in the testcases a scrollbar. BTW the FF 1.04 and Opera rendering is interoperable. Essentially what the patch does, it reinforces the patch that went in for bug 234593. I am confident that the patch for bug 234593 was correct and that the current behaviour is a) wrong b) that it is not possible to fix it consistently as soon at the content MEW plays a role for auto width blocks. At least a partially follow of the IE path seems to me very prone of illogical results. At least we probably need to reopen a lot of the dupes and dependencies of bug 234593, if the MEW of a scroll frame becomes content dependent.

just a note the patch for bug 234593 is not on the aviary branch but it was needed to fix regressions on the trunk

Comment on attachment 184517 [details] [diff] [review] patch I'm still not sure whether this is right or not according to a pure interpretation of the spec, but while there's doubt, the right thing to do is to be consistent with our earlier behaviour.

Comment on attachment 184517 [details] [diff] [review] patch Requesting 1.8b3 approval, this patch fixes some visible layout regressions

Comment on attachment 184517 [details] [diff] [review] patch a=shaver

This patch has been checked in, and I tested with a build that was made after the checkin - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050603 Firefox/1.0+ ID:2005060300. Here are the results: All of the testcases posted in this bugs PASS, except the following: * overflow visible * overflow: auto width:auto * overflow:hidden width:auto * overflow:scroll width:auto * overflow:visible width: auto

Thats a question of the definition of passed. The text in the testcases is misleading aka Copy&Paste from the original. The question here is reverting a regression, so the testcases should look identical in ff 1.0 and current trunk. Which they do for me. Martijn, did it completely revert the behaviour? Thats at least one of the main goals.

(In reply to comment #25) > Martijn, did it completely revert the behaviour? Thats at > least one of the main goals. I've checked all the testcase attached here and compared with Mozilla1.7. They all look identical. So it seems completely fixed to me.