Closed Bug 400406 Opened 17 years ago Closed 17 years ago

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

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Version:
1.8 Branch
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: mlrtpo, Unassigned)

References

(
URL
)

Details

(4 keywords)

Attachments

(1 file)

testcase by Dirk Jesse
2.19 KB, text/html
Details 
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
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...
Component: General → Layout
Keywords: regression
OS: Windows XP → All
Product: Firefox → Core
QA Contact: general → layout
Version: unspecified → 1.8 Branch
It seems this bug only occurs if the negative margin is equal or greater than the width of the floated element.
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...
Blocks: 387201
Confirmed regression from bug 387201 by local backout in an up-to-date tree.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.8.1.9?
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.  :(
Flags: in-testsuite?
(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.

> 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?
Depends on: 391412
> 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.
Keywords: testcase
Flags: blocking1.8.1.9?
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.
(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.
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.
> 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.
> 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.
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");
});
Flags: blocking1.8.1.9? → blocking1.8.1.9+
We will be taking bug 391412 to fix this in a 1.8.1.9 respin
Flags: blocking1.8.1.10? → blocking1.8.1.10+
I have experienced this same issue (or a very similar issue?) with FF < 1.5
also.
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?
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");
> });
> 


(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;
}
(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
A reftest was checked in in bug 391412 (which is basically the same one as this bug).
Flags: in-testsuite? → in-testsuite-
(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.
the patch in bug 391412 landed, calling this fixed so we can get verification
Status: NEW → RESOLVED
Closed: 17 years ago
Keywords: fixed1.8.1.10, fixed1.8.1.9
Resolution: --- → FIXED
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.
Keywords: fixed1.8.1.9 → verified1.8.1.9
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?
> 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

I see.  Thanks!   I'll download 3 beta when it comes out and keep on the beta wave form there!  :)
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.
Thanks Mozilla team for getting this one fixed and released so quick!  :)  Works for me in 2.0.0.9 on Mac.
Flags: blocking1.8.1.11+ → blocking1.8.1.10+
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
Keywords: fixed1.8.1.10 → verified1.8.1.10
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: