285269 - CSS margin for node inserted using insertBefore: unused or bad reflow

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect)

Description

[Christophe Porteneuve]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7.6) Gecko/20050226 Firefox/1.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7.6) Gecko/20050226 Firefox/1.0.1

When inserting an Element using some container element's insertBefore method, no
matter what the method's first argument is, the CSS margin property for the
inserted element does not seem to be used, or at least, the reflow does not take
it into account.

However, adding an identical element using the container's appendChild method
properly renders margins.

Correct behavior tested: Opera 7 XP, IE 6 XP, Konqueror 3.3.2, Safari 1.2.24
Incorrect behavior tested: Firefox 1.0.1 (XP, Debian GNU/Linux), Camino 0.8.2,
Mozilla 1.7.5 (Debian GNU/Linux)

Reproducible: Always

Steps to Reproduce:
1. Go to the URL attached to this report
2. Use the bottom button to "appendChild" new paragraph elements: it works fine
3. Use the top button to "insertBefore" new elements: margins are ignored.

Actual Results:  
Margins are ignored when using insertBefore, while they are properly used when
using appendChild

Expected Results:  
insertBefore should trigger a proper rendering of the inserted element's margins.

I could not find an easy workaround, so I leave severity as Normal.  If someone
finds a quick, not-too-kludge-like workaround, I wouldn't mind the bug being
downgraded to Minor severity, but still...

Comment 1

[Martijn Wargers (dead)]

works for me in the latest nightly trunk build.
I can see the bug in Mozilla1.7, though.
Please try with a trunk build:
http://ftp.scarlet.be/pub/mozilla.org/firefox/nightly/latest-trunk/

Comment 2

[Boris Zbarsky [:bzbarsky]]

1.7 (and that includes Firefox 1.0.x) is using a layout engine from April
2004... It's pretty pointless to test layout issues in it at this point.

This works no trunk, so resolving accordingly.

Comment 3

[Christophe Porteneuve]

Uh, Firefox 1.0.1 is out, and I was wondering, since its About string displays a
"Gecko/20050318" component, whether it includes the trunk's version of Gecko or not.

I don't suppose it does, since the bug's issue remains, and we're on a very
minor release here (aside from security issues), which would not justify the QA
work of integrating a new version of Gecko, but this About string puzzles me a
bit.  Is the timestamp about FF or Gecko?!

Comment 4

[Martijn Wargers (dead)]

No, Firefox 1.0.1 is branch.
Trunk versions, you can download here:
http://ftp.uni-erlangen.de/pub/mozilla.org/firefox/nightly/latest-trunk/

Comment 5

[Boris Zbarsky [:bzbarsky]]

> Is the timestamp about FF or Gecko?!

The timestamp is when the binary was compiled, unfortunately.... listing it
after "Gecko/" is a massive source of confusion.  :(

The Gecko version used by the app is what follows the "rv:" text in the
useragent string.