295026 - position:absolute misplaced input tags relative to <p> tags regarding to IE behavior

Status: RESOLVED DUPLICATE of bug 33784

(Core :: Layout: Positioned, defect)

Description

[Roland Käser]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:1.7.7) Gecko/20050414 Firefox/1.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:1.7.7) Gecko/20050414 Firefox/1.0.3

When several HTML parts are absolute positioned on the page or on a div or
iframe the position regarding to the parents top doesn't appears on the right
place. The controls (including absolute positioned <p> tags and others are
shifted about 3 pt from the controls they should appear. For sample when a text
(inside a absolute positioned <p> tag) and <input type="text" control or other
input controls are not positioned on the same line. the input tag appears more
below than the <p> tag. This makes it really hard to make cross browser pages
with position absolute tags.


Reproducible: Always

Steps to Reproduce:
1. Open the URL page with IE
2. Open the URL page with Firefox
3. Compare the graphical appearance

Actual Results:  
The controls in IE and firefox are not on the same place

Expected Results:  
Position the controls on the right place

This must be bug in Firefox (which is also in all Mozilla based browsers from
version 7.0 and above). Just look at the sample page, the describing fields and
the input fields appears only on firefox on the same place because the top
values in the style line have not the same values in case the page is optimized
for Firefox. But on IE the <p> tags are much higher than on firefox and netscape
and mozilla).
This bug is probably in the geko engine. Please relocate this bug if it should
not be on this list

Comment 1

[djpohly]

-> Core / Layout: R&A Positioning

Comment 2

[Roland Käser]

Attachment: Screenshot of the Firefox behaviour

Attachement Added in case of an improvment of the underlying framework to avoid
this bug

Comment 3

[Roland Käser]

Attachment: Screenshot of the IE behaviour

Attachement Added in case of an improvment of the underlying framework to avoid
this bug

Comment 4

[Martijn Wargers (dead)]

I can see the bug in Mozilla1.7, but not in current trunk build.
Looks like this is already fixed somehow.
Reporter, could you please verify that this is wfm in current trunk build?
http://ftp.scarlet.be/pub/mozilla.org/firefox/nightly/latest-trunk/

Comment 5

[Jason Barnabe (np)]

Looks like it's fixed already. WFM.

Comment 6

[Roland Käser]

I tryed it with the newest Deer Park (Alpha 1) Version. And the bug is already
there. Try this html snipped

<p style="font-family:Arial,Helvetica; font-size:10;   position:absolute;
top:90px; left:20px;">Username:</p>

<input type="TEXT" name="Input_1084" size="10" class="DanteInput"
style="position:absolute; font-family:Arial,Helvetica, sans; font-size:10px;  
top:90px; left:110px; width:263px;" >

Both of them should appear on the same vertical position but they doesn't.
Please check it again.

Comment 7

[Martijn Wargers (dead)]

Attachment: testcase from comment 6

(In reply to comment #6)
> Both of them should appear on the same vertical position but they doesn't.
> Please check it again.
WFM with current trunk build.

Comment 8

[djpohly]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
Firefox/1.0.4
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050603
Firefox/1.0+

Both the testcase and the website appear for me as they should.  Have you tried
a clean profile or safe mode to make sure it's not a problem with an extension?
 Is there anything else "special" about your configuration?

Comment 9

[Roland Käser]

Its a clean installation of a Deer Alpha on Windows 2000 with NO extensions, and
the error appears also in safe mode. Can You eventually attach a link to a
version which You think is working. Its possibly a error regarding to the use of
DIVS with absolute position. Try:

<DIV STYLE="position:absolute; width:411px; height:200; top:20px; left:20px">
   <p style="font-family:Arial,Helvetica; font-size:10;   position:absolute;
    top:90px; left:20px;">Username:</p>

   <input type="TEXT" name="Input_1084" size="10" class="DanteInput"
    style="position:absolute; font-family:Arial,Helvetica, sans; font-size:10px;  
    top:90px; left:110px; width:263px;" >
</DIV>

Comment 10

[Roland Käser]

Attachment: Testcase with DIV

Comment 11

[Martijn Wargers (dead)]

Ok, that testcase shows a difference. 
A P element has normally a margin-top and margin-bottom om 1 em. If you want no
margin, you can set it to margin:0;.
It seems to me that the behavior of IE6 is at mistake here, see also:
http://www.w3.org/TR/CSS21/box.html#collapsing-margins
"Margins of absolutely positioned boxes do not collapse (not even with their
in-flow children)."

Comment 12

[Roland Käser]

But look, the describen feature happens only when the <p> and <input tag is
absolutly positionized inside a absolutly positionized div. when it is directly
placed in the body the misplacement doesn't happen. Yet it seems to me as an but.
See "testcase from comment 6" and compare it with "Testcase with DIV" to see
what I mean.

Comment 13

[Martijn Wargers (dead)]

Attachment: testcase from comment 6, but now in standards mode

That's a quirk rule of Mozilla that's causing it:
http://lxr.mozilla.org/seamonkey/source/layout/style/quirk.css#120
p:-moz-first-node gets margin-top:0 in quirks mode, but not in standards mode
where those quirk rules are not applied.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Yep.  This is invalid -- the content is being laid out exactly as the CSS rules
applied to it require.

Comment 15

[Roland Käser]

What go you guys wrote here about that? 

Just open it in IE, open it in Konquerror, open it in Opera etc. All they have
the same behaviour in this BUT NOT FIREFOX!!.  Also not the Deer Park Alpha 2.
Just fix this.

Comment 16

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

There's a bug somewhere on replacing that p:-moz-first-node, etc., quirk with
something more like what older browsers did.  Is this bug a duplicate of that one?

Comment 17

[Boris Zbarsky [:bzbarsky]]

Basically, yes.  I spent some time looking for it, and couldn't find it, so I
decided it's just not worth the effort.  But yeah, someone should locate it and
mark this duplicate.

Roland, Opera and most of those browsers you mention render the testcase just
like we do in standards mode.  So what you're complaining about is that we're
not emulating a purposeful bug that they introduce in quirks mode.  That's
really a pretty low priority.

Comment 18

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

*** This bug has been marked as a duplicate of 33784 ***