Last Comment Bug 400406 - Layout badly broken in 2.0.0.8, CSS issue with floats or negative margins or display property...
: Layout badly broken in 2.0.0.8, CSS issue with floats or negative margins or ...
Status: RESOLVED FIXED
: regression, testcase, verified1.8.1.10, verified1.8.1.9
Product: Core
Classification: Components
Component: Layout (show other bugs)
: 1.8 Branch
: x86 All
: -- major with 7 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://www.alistapart.com/d/multicolu...
: 400405 400469 400828 (view as bug list)
Depends on: 391412
Blocks: 387201
  Show dependency treegraph
 
Reported: 2007-10-19 09:06 PDT by Marcus Rodriguez
Modified: 2010-09-17 14:37 PDT (History)
43 users (show)
mtschrep: blocking1.8.1.9+
dveditz: blocking1.8.1.10+
martijn.martijn: in‑testsuite-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase by Dirk Jesse (2.19 KB, text/html)
2007-10-20 04:11 PDT, Steve England [:stevee]
no flags Details

Description Marcus Rodriguez 2007-10-19 09:06:53 PDT
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 (:mats) 2007-10-19 10:16:13 PDT
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 2007-10-19 10:28:48 PDT
It seems this bug only occurs if the negative margin is equal or greater than the width of the floated element.
Comment 4 Mats Palmgren (:mats) 2007-10-19 10:42:11 PDT
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 (:mats) 2007-10-19 11:05:06 PDT
Confirmed regression from bug 387201 by local backout in an up-to-date tree.
Comment 6 Boris Zbarsky [:bz] 2007-10-19 14:15:40 PDT
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 (:mats) 2007-10-19 15:42:13 PDT
(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 8 philippe (part-time) 2007-10-19 18:43:11 PDT
*** Bug 400405 has been marked as a duplicate of this bug. ***
Comment 9 Boris Zbarsky [:bz] 2007-10-19 21:31:58 PDT
> 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 10 philippe (part-time) 2007-10-19 21:36:41 PDT
*** Bug 400469 has been marked as a duplicate of this bug. ***
Comment 11 Dirk Jesse 2007-10-20 01:48:26 PDT
> 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 13 Jason Knight 2007-10-21 19:00:34 PDT
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 2007-10-21 19:33:42 PDT
(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 [:bz] 2007-10-21 19:58:25 PDT
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 2007-10-21 22:43:29 PDT
> 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 [:bz] 2007-10-21 23:10:30 PDT
> 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 2007-10-22 07:21:02 PDT
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] 2007-10-22 14:52:54 PDT
We will be taking bug 391412 to fix this in a 1.8.1.9 respin
Comment 20 Bevan Rudge 2007-10-22 15:06:02 PDT
I have experienced this same issue (or a very similar issue?) with FF < 1.5
also.
Comment 21 Bevan Rudge 2007-10-22 15:07:45 PDT
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 2007-10-22 15:24:24 PDT
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 2007-10-22 15:28:42 PDT
(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 (:mats) 2007-10-22 15:34:41 PDT
(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 [:mwargers] (not working for Mozilla) 2007-10-22 15:36:35 PDT
A reftest was checked in in bug 391412 (which is basically the same one as this bug).
Comment 26 Daniel Veditz [:dveditz] 2007-10-23 00:03:30 PDT
(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 27 Lorna 2007-10-23 06:50:08 PDT
*** Bug 400828 has been marked as a duplicate of this bug. ***
Comment 28 Daniel Veditz [:dveditz] 2007-10-23 09:56:14 PDT
the patch in bug 391412 landed, calling this fixed so we can get verification
Comment 29 Marcia Knous [:marcia - use ni] 2007-10-23 11:34:48 PDT
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 2007-10-23 22:13:41 PDT
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 [:bz] 2007-10-23 22:20:27 PDT
> 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 2007-10-23 22:52:57 PDT
I see.  Thanks!   I'll download 3 beta when it comes out and keep on the beta wave form there!  :)
Comment 33 Joe Krahn 2007-11-03 10:23:39 PDT
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 2007-11-03 15:27:26 PDT
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] - PTO-back Sept 4th 2007-11-15 08:00:25 PST
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

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