579835 - Top bar is broken into two on latest nightly of Camino - smooth and continuous in Safari.

Status: RESOLVED WONTFIX

(Web Compatibility :: Site Reports, defect)

Description

[psmaher]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en; rv:1.9.2.8pre) Gecko/20100717 Camino/2.1a1pre (like Firefox/3.6.8pre)
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en; rv:1.9.2.8pre) Gecko/20100717 Camino/2.1a1pre (like Firefox/3.6.8pre)

Top bar is broken into two on latest nightly of Camino - smooth and continuous in Safari.

Reproducible: Always

Steps to Reproduce:
1. http://www.writerspub.com/account/index
2.
3.

Comment 1

[philippe (part-time)]

It is also broken in all Firefox 3.6.x and a recent Minefield nightly. Opera 10.6 shows also a broken layout.
However Gecko 1.9.0 (Camino 2.0.3) and Gecko 1.9.1 (Firefox 3.5.12pre) display the same as Safari 5.

I'm not clear why it displays correctly in Safari or older Gecko, the math just doesn't add up. The Logo image is 250px wide with a negative margin-left of 18px. The brown navigation bar is 731px wide according to Firebug (right floated block). All this has to fit in a 962px side container.

Sending to core for further triage, although I suspect it will end-up being invalid. The site should correct their math.

Comment 2

[Boris Zbarsky [:bzbarsky]]

731 + 250 - 18 = 981 - 18 = 963.

And indeed, the page styles that <div id="container"> to be width:962px.

That said, in a minimal-ish testcase webkit has the same behavior as us for that sort of thing.  So _something_ about the site is special...

A reduced testcase that doesn't put the image on the next line in webkit but does in Gecko would be really nice.

Comment 3

[philippe (part-time)]

Attachment: test case based on URL

Here is the page, reduced as much as possible (with some additional background-colors)

Displays 'as expected' in Safari 5, fails in Gecko 1.9.2+ and Opera 10.6.

div id="header_forms" (floated right) (blue bar in test case) must exist in the markup for Safari to display this 'as expected'

Comment 4

[Boris Zbarsky [:bzbarsky]]

Attachment: Even smaller testcase

The div around the image is necessary for Gecko to not have the rendering webkit does.  I'm not sure why.

The header_forms div is necessary for webkit to not have the rendering Gecko does.

In any case, it seems we place the image below the floats, while webkit decides that it fits next to the first float and places it there (overlapping the second float with the image).  

Opera places the image below the floats even if the div around the image is removed; I believe this is the correct behavior.

Note: making the image display:block makes it overlap the floats in all three browsers, which sounds like a direct contradiction of CSS2.1 section 9.5 to me....

Comment 5

[Boris Zbarsky [:bzbarsky]]

David, any idea what's going on here?

Comment 6

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

Responses below, based on a very quick look at the testcase in Gecko and Chromium:

(In reply to comment #4)
> The div around the image is necessary for Gecko to not have the rendering
> webkit does.  I'm not sure why.

Sounds like a bug in the fix for bug 25888; I don't recall now whether it's one of the known ones.

> The header_forms div is necessary for webkit to not have the rendering Gecko
> does.

Because the issue is whether browsers check the whole height of what they're wrapping around the floats or whether they just check the floats at the top edge.

> In any case, it seems we place the image below the floats, while webkit decides
> that it fits next to the first float and places it there (overlapping the
> second float with the image).  

Because we've fixed bug 25888 for most cases with inlines, but WebKit hasn't.

> Note: making the image display:block makes it overlap the floats in all three
> browsers, which sounds like a direct contradiction of CSS2.1 section 9.5 to
> me....

Because we haven't yet fixed bug 25888 for blocks.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Aha.  Sounds like all this adds up to tech evangelism.  Reporter, please contact the site and let them note their layout is relying on a browser bug?  I'll do the same.

Comment 8

[philippe (part-time)]

Fwiw:

bug 25888 matches the regression range I found:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0f4de606acd7&tochange=d0ae0b099a40

20090520 Minefield/3.6a1pre displays as WebKit - 
20090521 Minefield/3.6a1pre hangs (regression from bug 25888)
first builds that doesn't hang: 20090617 Minefield/3.6a1pre
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ca8799e74642&tochange=92b6868ef3f4

Comment 9

[Karl Dubost💡 :karlcow]

RIP Camino. This bug are now WONTFIX.