400406 - Layout badly broken in 2.0.0.8, CSS issue with floats or negative margins or display property...

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Marcus Rodriguez]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8

Layouts based on this technique fine prior to 2.0.0.8, now  the footer no longer clears, border colours don't appear. Seems to be related to the float + negative margins + display property, although no combinations of changing these cause the layout to function correctly.

Other Sites based on this design methodology also fail to render in the same way.

Fine in Firefox 2.0.0.7 and earlier, Safari 3, Opera 8, IE6, IE7

Reproducible: Always

Steps to Reproduce:
1.Visit Website
2.Observe broken layout
Actual Results:  
Footer not clearing and border colours not appearing

Expected Results:  
As Firefox 2.0.0.7/IE/Opera/Safari -- ie coloured borders and footer at the bottom.

Affects sites using adaptation of this technique:
http://www.jml-villas.com
http://www.latenightengineer.com/play/three-column-layout-pearce

Comment 1

[Mats Palmgren (inactive)]

WFM in Firefox 2.0.0.7 on Linux.  Bug occurs in 2.0.0.8 and 2.0.0.8rc1.
Looks like a branch regression to me.  I'll try to find the range...

Comment 2

[Victor Welling]

It seems this bug only occurs if the negative margin is equal or greater than the width of the floated element.

Comment 3

[Mats Palmgren (inactive)]

Regression range: 2007-10-03-03 -- 2007-10-04-03
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-10-03+02%3A00&maxdate=2007-10-04+04%3A00&cvsroot=%2Fcvsroot

Comment 4

[Mats Palmgren (inactive)]

Testing with a local SeaMonkey branch debug build indicates bug 387201
(which seems logical: changes to nsSpaceManager.cpp => float problems).
However, this tree is not fully up-to-date so I'll
update/rebuild/backout 387201 to confirm...

Comment 5

[Mats Palmgren (inactive)]

Confirmed regression from bug 387201 by local backout in an up-to-date tree.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Hmm.  Is this not an issue on trunk?  Bug 387201 landed there too, right?

If this is not a problem on trunk, do we know why not?

Maybe it's time to try running reftests on branch.  :(

Comment 7

[Mats Palmgren (inactive)]

(In reply to comment #6)
> Hmm.  Is this not an issue on trunk?  Bug 387201 landed there too, right?

Well, it was an issue also on trunk -- the bug occurs in 2007-08-01-04
for example.  A regression bug was filed (bug 391412) but that only
landed on trunk... 

Applying the patch in 391412 locally fixes this bug.

Comment 9

[Boris Zbarsky [:bzbarsky]]

> A regression bug was filed (bug 391412) but that only landed on trunk... 

Gah!

I seem to recall this technique being pretty common.  Is it common enough, and does this break it badly enough, that we need to expedite 1.8.1.9?

Comment 11

[Dirk Jesse]

> Is it common enough, and does this break it badly enough, that we need to expedite 1.8.1.9?

Yes, this technique is well known and whidely used for modern css layouts. So please, fix this because alot of pages seem to have problems.

Comment 12

[Steve England [:stevee]]

Attachment: testcase by Dirk Jesse

From blog post at http://blog.highresolution.info/index.php?/highresolution/comments/firefox_2008_float_containing_clearing_bug/ and actual testcase at http://www.highresolution.info/webdesign/testcases/ff_floatingbug.htm

Comment 13

[Jason Knight]

Noticed it within five minutes of letting the blasted update run... since this breaks close to 80% of the sites I've coded... AND I'm now getting flooded with people complaining about it.

THANKS.

For now you can get away with using "clearfix" instead - but that's not a real solution.

Comment 14

[Jason Knight]

(In reply to comment #9)
> I seem to recall this technique being pretty common.  Is it common enough, and
> does this break it badly enough, that we need to expedite 1.8.1.9?
Being that it's what makes ALA's 'holy grail' layout work, is behind all the designs on Alessandro Fulciniti's 'layout gala', is in a good number of gallery CMS', relied upon for a number of CSS only dropdown menus and the cornerstone of almost EVERY SEO center column first non-table layout...

I'm AMAZED this made it into a main branch release as it should have shown up in this thing called 'testing' PDQ.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Testing on the branch is always fun.  Very few people apparently bother to test the (always available) branch builds until they ship.  The automated layout test infrastructure postdates branch.  So the testing that happens on branch is, in the end, done by a very small number of people (order of 10-20 at the most, I would guess).  None of these loaded any of the sites in question during their normal browsing, apparently.

The real issue is that this _was_ found on trunk, during testing, and that the fix didn't make it to the branch.

Comment 16

[Dirk Jesse]

> The real issue is that this _was_ found on trunk, during testing, and that the
fix didn't make it to the branch.

So, if there is a fix already when will it be released? Jason mentioned "clearfix" as a workaround but thats only for new layouts with this bug in mind. It's impossible to fix all exisiting layouts.

Comment 17

[Boris Zbarsky [:bzbarsky]]

> So, if there is a fix already when will it be released?

That's basically the question in comment 9.  I suspect there will be an answer once it's no longer weekend in California.

Comment 18

[Jeff Lundberg]

Hopefully this will help someone else who happens to be using the ALA layout,
has a JavaScript file included on all their pages, and also happens to be using
jQuery.  It's basically a JavaScript hack to apply the ClearFix hack which
fixes this Firefox Bug.  Why Firefox... Why???

$(function(){
        if($.browser.mozilla && $.browser.version == '1.8.1.8')
                $('#container').addClass("clearfix");
});

Comment 19

[Daniel Veditz [:dveditz]]

We will be taking bug 391412 to fix this in a 1.8.1.9 respin

Comment 20

[Bevan Rudge]

I have experienced this same issue (or a very similar issue?) with FF < 1.5
also.

Comment 21

[Bevan Rudge]

I would like to test RCs to help prevent this in the future.  How can I find out when they are available?
It would be nice if I could set in FF about:config that I get notified about RCs
and FF updates automatically to them.  Is this possible?

Comment 22

[Danny Dawson]

First: Thanks, Jeff. You saved me a good bit of poking around.

For more background on Jeff Lundberg's workaround:
http://www.positioniseverything.net/easyclearing.html

For those who aren't using jQuery, the following javascript can be included at the end of every page: 

<pre><code>if (window.navigator 
&& window.navigator.userAgent.toString().indexOf('Firefox') != -1 
&& window.navigator.userAgent.toString().indexOf('1.8.1.8') != -1){
document.getElementById('container').className = document.getElementById('container').className
+ ' clearfix';}</code></pre>

As long as you also have the following in your global CSS:
<pre><code>.clearfix:after {
    content: "."; 
    display: block; 
    height: 0; 
    clear: both; 
    visibility: hidden;
}</code></pre>

This should fix the bug for all Firefox 2.0.0.8 users who have javascript on, without breaking anything for others.

(In reply to comment #18)
> Hopefully this will help someone else who happens to be using the ALA layout,
> has a JavaScript file included on all their pages, and also happens to be using
> jQuery.  It's basically a JavaScript hack to apply the ClearFix hack which
> fixes this Firefox Bug.  Why Firefox... Why???
> 
> $(function(){
>         if($.browser.mozilla && $.browser.version == '1.8.1.8')
>                 $('#container').addClass("clearfix");
> });
> 

Comment 23

[Danny Dawson]

(In reply to comment #22)

Of course, you should leave off all the <pre><code></code></pre>. Sorry about that (and this duplicate comment). Correct code below.

JS:
if (window.navigator 
 && window.navigator.userAgent.toString().indexOf('Firefox') != -1 
 && window.navigator.userAgent.toString().indexOf('1.8.1.8') != -1){
 document.getElementById('container').className =
 document.getElementById('container').className + ' clearfix';}

CSS:
.clearfix:after {
    content: "."; 
    display: block; 
    height: 0; 
    clear: both; 
    visibility: hidden;
}

Comment 24

[Mats Palmgren (inactive)]

(In reply to comment #21)
> It would be nice if I could set in FF about:config that I get notified about
> RCs
> and FF updates automatically to them.  Is this possible?

http://kb.mozillazine.org/App.update.channel

Comment 25

[Martijn Wargers (dead)]

A reftest was checked in in bug 391412 (which is basically the same one as this bug).

Comment 26

[Daniel Veditz [:dveditz]]

(In reply to comment #15)
> So the testing that happens on branch is, in the end, done by a very small
> number of people (order of 10-20 at the most, I would guess).  None of these
> loaded any of the sites in question during their normal browsing, apparently.

We had 70,000 users on the beta update channel use this build for a week before we released it.

(In reply to comment #24)
> (In reply to comment #21)
> > It would be nice if I could set in FF about:config that I get notified about
> > RCs and FF updates automatically to them.  Is this possible?
> 
> http://kb.mozillazine.org/App.update.channel

Note that this can't be done in "about:config", you have to manually edit defaults/pref/channel-prefs.js in your install directory. Change "release" to "beta".

People who don't want to bother can install one of the ancient Firefox 2 betas which will then immediately update to the latest release and keep you getting betas.

Comment 28

[Daniel Veditz [:dveditz]]

the patch in bug 391412 landed, calling this fixed so we can get verification

Comment 29

[Marcia Knous [:marcia]]

verified fixed on the 1.8 branch using Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.8pre) Gecko/2007102306 BonEcho/2.0.0.8pre. I used the testcase in the bug for verification. Adding branch verified keyword.

If anyone else besides Bevan is interested in getting on the beta channel so that you can get updates and check for any possible layout regressions, please let me know.

Comment 30

[Bevan Rudge]

I'm not sure if I understood all that.  Will this be fixed in the next release of FF?  Will the release be fast-tracked due to this bug?

Btw, I have set app.update.channel in FF to 'beta' and look forward to testing! :)  Thanks to THREE of you who replied to me! :)

> Note that this can't be done in "about:config", you have to manually edit defaults/pref/channel-prefs.js in your install directory. Change "release" to "beta".

I was able to edit it in about:config.  Are you saying the option isn't available there, or that setting it there doesn't work?

Comment 31

[Boris Zbarsky [:bzbarsky]]

> Will this be fixed in the next release of FF? 

Yes.

> Will the release be fast-tracked due to this bug?

This bug and one or two others, yes.

> Are you saying the option isn't available there, or that setting it there
> doesn't work?

The latter.  See http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/toolkit/mozapps/update/src/nsUpdateService.js.in&rev=1.143&mark=507-509#506

Comment 32

[Bevan Rudge]

I see.  Thanks!   I'll download 3 beta when it comes out and keep on the beta wave form there!  :)

Comment 33

[Joe Krahn]

This type of bug suggests that it would be good to support temporary patches that can automatically load a javascript 'patch' like the one above. If javascript can be used as a temporary work-around, then it will allow more time to get the updated release ready, and maybe help avoid an extra round of downloads.

Comment 34

[Bevan Rudge]

Thanks Mozilla team for getting this one fixed and released so quick!  :)  Works for me in 2.0.0.9 on Mac.

Comment 35

[Carsten Book [:Tomcat]]

verified fixed 1.8.1.10 using the testurl from comment #0 and Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.10pre) Gecko/2007111503 BonEcho/2.0.0.10pre

Adding verified keyword