266402 - Extra whitespace displayed on page (with 1.0RC)

Status: VERIFIED INVALID

(Core :: Layout: Floats, defect)

Description

[Nitin (vfwlkr)]

Also seen on other sites. See:
http://forums.mozillazine.org/viewtopic.php?t=151562

For the sfx blog post:
http://www.spreadfirefox.com/?q=node/view/4724

there's too much whitespace between '--Asa' and the comments below it.

It displays fine in IE

Comment 1

[Josh Powell]

I have noticed this too (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7.3) Gecko/20041026 Firefox/1.0RC1) and its getting really annoying to have
to scroll down so much to read the comments on SFX.. I have no idea if this is
SFX's problem or a Firefox bug, but it appears to be the latter.

Comment 2

[Volkmar W. Pogatzki]

WFM using
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041026 Firefox/1.0RC1

Could you please attach a screenshot visualizing where you've got too much
whitespace?

Comment 3

[Josh Powell]

Attachment: Screenshot of the Whitespace in question

Here is a screenshot, it is taken from
http://www.spreadfirefox.com/?q=node/view/4611 -- the whitespace was so large I
had to go into full screen mode at the highest res my monitor could handle just
to give it some context clues.. 

Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041026
Firefox/1.0RC1. This ONLY happens to me when I AM logged in, if I am not logged
in it works fine. This may be a SFX problem, and not have anything to do with
Firefox.

Comment 4

[Nitin (vfwlkr)]

Note: you have to be logged into spreadfirefox.com to see the extra whitespace

Comment 5

[Josh Powell]

(In reply to comment #4)
> Note: you have to be logged into spreadfirefox.com to see the extra whitespace

Um, I did say that in comment 3, "This ONLY happens to me when I AM logged in,
if I am not logged in it works fine." But you are right, you must be logged in.
So it leads me to beleive it has something to do with the Rate this post code.

Comment 6

[Nitin (vfwlkr)]

Attachment: Screenshot from SFX (after logging in)

Attaching screenshot from the URL mentioned in the bug (after logging in)

Comment 7

[mixxster]

*** Bug 266871 has been marked as a duplicate of this bug. ***

Comment 8

[mixxster]

I get the same bug. Its quite annoying

Comment 9

[Martijn Wargers (dead)]

I bet this was introduced by the fix for bug 148994.

Comment 10

[Martijn Wargers (dead)]

Attachment: Testcase, not minimal yet

When I remove this rule:
.node_rating{	clear: both;}
then the testcase renders as one would expect. 
This is exactly the case that bug 148994 fixed, so it is very likely that the
spreadfirefox site needs to fix this css part (more or less the same case as
bug 259275, I guess).

Comment 11

[Martijn Wargers (dead)]

I think this has been fixed on the site.
I don't see the bug anymore, and they have now this in their stylesheet for
.node_rating:
* html > .node_rating{
	clear: both; /* for IE */
}
This doesn't apply for Mozilla.

Comment 12

[Noa Groveman]

I'm seeing perhaps this same bug in a google search -
http://www.google.com/search?q=xaml

The whitespace doesn't appear in Internet Explorer.

Comment 13

[Worcester12345]

(In reply to comment #12)
> I'm seeing perhaps this same bug in a google search -
> http://www.google.com/search?q=xaml
> 
> The whitespace doesn't appear in Internet Explorer.

I confirm that I also see that. 

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041102
Firefox/1.0RC2 (bangbang023)

Comment 14

[Michael Lefevre]

*** Bug 267536 has been marked as a duplicate of this bug. ***

Comment 15

[Michael Lefevre]

This bug is invalid per the discussion here and in bug 267536 - the change was
deliberate, and the old behaviour (and IE's behaviour) was wrong. So unless
someone in authority wants to decide that the change should be reversed for
compatibility reasons...

Comment 16

[dharana]

*** Bug 267640 has been marked as a duplicate of this bug. ***

Comment 17

[Jeremy Arnold]

My main concern here is not that the bug was fixed, 
But rather that a significant change in the render engine did not get a mention
in the changelog supplied with FF RC1... nor in the even in the (more complete)
changelog online.(http://www.mozilla.org/projects/firefox/qa/changelog-rc1.html) 

I suspect the main reason for this is because the fix was taken from mozzila
trunk and patched into the FF branch. This is also the reason that this problem
has been fixed so late in the development cycle of FF, not the ideal time at all.

Are there not proccesses in place for this thing ???

(please correct me if I am wrong)

Comment 18

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The underlying float change made us change from incompatible with IE to
compatible with IE, not the other way around.  Likewise for the spec.  Likewise
for Opera and Safari, IIRC.

Most of the sites that it's broken are Mozilla-specific sites that are going to
fix their CSS quickly (planet.mozilla.org, some things on www.mozilla.org,
spreadfirefox.com), and perhaps a few other sites that were writing CSS using
selectors that they knew IE didn't support (i.e., using child selectors as in
comment 11 above -- although the CSS comments in comment 11 don't make sense).

The reason it was landed on the branch was that it was quite safe and well
tested and it would prevent a proliferation of Mozilla-specific sites that
depended on a Mozilla bug that was already fixed on the trunk.

Comment 19

[Jeremy Arnold]

David B, I think you have missed the mark here ...
 The only other browsers correctly displaying float clearing is Konquerer and
possibly safari .. opera's behaviour copied IE last I heard.

The child selectors and comment #11 refer to a CSS code "fix" and a pretty
useless one at that ... the selector could only be regognised by IE's
interesting DOM.
Many sites will be affected by this Fix ... I have at least 20 sites I now have
to fix ... 

It is not isolated to obscure selectors...
I can't be alone, these things should be in the changelogs!

Again, I have been an advocate of CSS for over 5 years and while I might not
agree that the spec outlines the most sensible way of dealing with this, I am
all in favour of the related Fix and sticking to the specs now they are set down.

FireFox's 'clear' property now behaves as the spec says it should.

I think tomorrow will be spent writing this up in an easy to understand way,
because how this all now works is obscure in the least for most web
designers/developers. 
Reading w3c specs is not everyones favorite pass-time!