349580 - margin gets doubled at top of canvas in certain case involving floats and clears

Status: RESOLVED DUPLICATE of bug 451791

(Core :: Layout: Block and Inline, defect)

Description

[Christopher Hotchkiss]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.5) Gecko/20060731 Ubuntu/dapper-security Firefox/1.5.0.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.5) Gecko/20060731 Ubuntu/dapper-security Firefox/1.5.0.5

When rendering the above page the top two images do not render next to each other. Instead the second image is dropped down a line.

Reproducible: Always

Steps to Reproduce:
1. go to http://www.votevana.com
2.
3.




This bug does not appear in Safari, Konqueror, Internet Explorer or Opera.

Comment 1

[Christopher Hotchkiss]

Attachment: Source code of the site that demonstrates the bug.

Comment 2

[Christopher Hotchkiss]

Attachment: Irc log of the discussion of this bug.

This is the inital discussion of the bug between Sander and me.

Comment 3

[jorge alves]

Confirming the same behaviour, check the upcoming simplified test-case.
I replaced the img's with spans and added a copy with the styles defined inline, just in case. Also, in the stylesheet, I separated the css selectors ".logo, .logo img" and ".portait, .portait img" to individual declarations. 

The inner span is floated right inside a floated element.
The outer span gets a display:block according to DOM Inspector. Maybe this is according to spec?

Seamonkey trunk 2006081908, wxp.

Comment 4

[jorge alves]

Attachment: simplified testcase

Comment 5

[Sander]

Attachment: better (?) testcase

jorge, although the discrepancy in rendering between gecko and opera in your testcase is weird, I'm pretty certain that gecko's behaviour there is as expected. It's the effect of the negative margin pushing the previous sibling up that I think might be a real bug. Here's a testcase showing that.

(Christopher: sorry, I should've explained what I meant with "minimal testcase" - these last two attachments are it - the bare minimum amount of HTML/CSS to show the bug, so that it's easy for developers to see what's really happening.)

Comment 6

[Sander]

Moving to (what I think is) the correct component. This needs a layout expert to determine if it's actually a bug.

Comment 7

[jorge alves]

I don't know.
Examining the original page, I first noticed the second image was being floated inside a floated span and I would expect [with my limited knowledge] to see it floated in the right side just like the other floats to the left. At least in the same line.

If you substitute the spans and css definition in my testcase with the original images, they still appear the same way as in the original page. I don't have any negative margin in my testcase and I tried to target the original comment's problem. Maybe we're talking about 2 different bugs? 

Comment 8

[jorge alves]

Attachment: simple style "fix" to the original problem

Original testcase with "style='float: none'" applied inline to the right img element to demonstrate what causes the page to misbehave.

Sander:
This is what prompt me to approach the double floating supposed bug.
I believe we're talking about 2 independent problems, although I really don't know if either of them is a real bug.

Comment 9

[dolphinling]

It's not just a negative margin pushing it up, a positive margin pushes it down, too, and makes it easier to see what's going on.

The strange thing is that it's not really applying the extra (or negative-extra) space to an element, not even the body. When the DOMi flashes an element, it surrounds the entire thing, including margins. None of the elements include the extra space at the top when they flash.

Also, if the div with clear applied has any height, or if there's any content before the first div, or any content after the float but inside the div that contains it, the bug goes away.

Comment 10

[jorge alves]

(In reply to comment #4)

FWIW, the problem I was trying to address is solved (if it really is a bug) in Minefield 20061015 [reflow-refactor], but it's still present in seamonkey/trunk 2006101605.

The negative margin issue is still the same, though...

Comment 11

[Daniel.S]

(In reply to comment #4)
> Created an attachment (id=234867) [details]
> simplified testcase

This was an issue fixed by bug 300030. It is similar to bug 69745.

(In reply to comment #5)
> Created an attachment (id=234917) [details]
> better (?) testcase

This issue has been filed as bug 451791, the only difference is that in this report's case, the margin is negative.