absolute positioning containing block established by relative-positioned fieldsets is misplaced

RESOLVED FIXED in mozilla10

Status

()

Core
Layout: Form Controls
RESOLVED FIXED
9 years ago
3 years ago

People

(Reporter: Zenich Igor, Assigned: Ehsan)

Tracking

Trunk
mozilla10
x86
Windows XP
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

9 years ago
User-Agent:       Opera/9.27 (Windows NT 5.2; U; ru)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; ru; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1

Coordinates count not from the top left corner of the block, but from contents (i.e. move downwards and to the right on size padding-top and padding-left.

Reproducible: Always

Steps to Reproduce:
1. Create a html file with this code in it:
------
  <fieldset style="width: 300px; height: 300px; position: relative; padding: 20px; border: 1px solid black">
    <span style="position: absolute; top: 0; left: 0">Test word</span>
  </fieldset>
------

2. Open created html file with Mozilla.
Actual Results:  
The test word is shifted on 20 pixels at the left and from above.

Expected Results:  
The test word is in the top left corner of the block.
(Reporter)

Updated

9 years ago
OS: Windows Server 2003 → Windows XP
Version: unspecified → 3.0 Branch

Comment 1

9 years ago
Created attachment 333579 [details]
testcase

Attached testcase.

I can confirm described behavior in latest nightly.

Renders as expected in Konqueror 3.5.9.
There aren't any specs that actually say what should happen here, though.  (I'm surprised fieldsets work as absolute positioning containing blocks at all.)
Component: General → Layout: Form Controls
Product: Firefox → Core
QA Contact: general → layout.form-controls
Summary: Absolutely positioned elements inside fieldset with padding and position:relative incorrectly count his coordinates → absolute positioning containing block established by relative-positioned fieldsets is misplaced
Version: 3.0 Branch → Trunk
We set up the fieldset as the abs pos container, but then when inserting the frames we actually stick them inside the -moz-fieldset-content frame.  That's a block, so it can deal, but you get the offset this bug is about.

Once bug 455338 is fixed we should just stop forwarding the absolute list here, and that will fix things.
Status: UNCONFIRMED → NEW
Depends on: 455338
Ever confirmed: true

Comment 4

9 years ago
I have similar behaviour that I suspect is related.
Even though the fieldset in this case is NOT absolutely positioned.
http://m8y.org/tmp/fieldset_abuse.xhtml

I set the fieldset to relatively positioned, to allow the spinner top/right to be relative to the first positioned parent.

IE6, Opera, Safari, Chrome, Webkit nightly and Konqueror all position both spinners the same distance to the right.

Firefox does not.

This is a little odd since computed styled reports Firefox is fully aware of the dimensions of the fieldset, and the deviation is not great, so I'm not too sure what Firefox is doing.

There are 2 spinners on this test - the first one is relative to the <fieldset>  - that's the one Firefox breaks.  The second one is relative to the <ul> - that one works in Firefox.

Comment 5

9 years ago
Oh. Oops. I see Boris has explained what is happening.
Thanks! :)

Updated

8 years ago
Duplicate of this bug: 532368
Duplicate of this bug: 543052
Duplicate of this bug: 542650
Duplicate of this bug: 543052
Duplicate of this bug: 543052

Comment 11

7 years ago
Created attachment 431763 [details]
fieldset relative positioning bug

This seems to apply in instances where there is no padding on the fieldset. Other browsers seem to treat the fieldset as expected.

Comment 12

7 years ago
Still happening in latest minefield build 

Mozilla/5.0 (Windows NT 6.1; rv:2.0b10pre) Gecko/20110111 Firefox/4.0b10pre ID:20110111030357

fieldset with position relative
button with position absolute

test case :
paste this code in a html empty file and open it in firefox

<!DOCTYPE html>
<html>
<body>
	<fieldset style="position: relative">
		<legend>Legend</legend>
		<button style="position:absolute; top: 0; right: 0;">should be at top right</button>
		<ol>
			<li>
				Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean posuere, nibh vitae posuere hendrerit, orci sem ultricies elit, ac ornare orci lorem id ipsum. Sed sed tincidunt augue. Duis interdum volutpat convallis. Praesent id diam augue. Nam lacinia felis nec mauris consequat dictum. Mauris in commodo ipsum. Phasellus tincidunt massa massa. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Donec molestie ornare vulputate. In justo turpis, volutpat a ultricies non, congue id risus. In viverra velit eget libero mollis mollis ac eget urna. Curabitur fringilla, magna sit amet feugiat dictum, diam orci suscipit arcu, id tempus massa felis vel tellus. Sed quis diam mauris, non aliquet lectus.
			</li>
		</ol>
	</fieldset>
</body>
</html>

actual result : the button is not at top right corner of the fieldset

expected result : the button should be at top right corner
Duplicate of this bug: 635773

Comment 14

6 years ago
Here's a quick example: http://jsfiddle.net/93LRU/

Taken from Bug 635773

Comment 15

6 years ago
I can confirm this bug. Set up two sets of HTML with the same CSS, one using fieldset, one using form; the button is misplaced when inside fieldset but not anything else, works fine in all other browsers.

I set the child element to:
 right:8px;
 top:10px;

But Firebug reports that Firefox thinks this is:
right:-4px;
top:10px;

So the right-position is being halved and inversed... Odd.

Comment 16

6 years ago
Forgot to mention that the bottom position variable is also wrong, when top is set to 10px, the bottom is set to -4px, when it should be 7px. So clearly there's some problems with the calculation of absolute position within the fieldset.

Comment 17

6 years ago
George, my workaround was just to put those elements in a wrapper.
<fieldset><div style="position: relative;"><button style="position: absolute">... will do the trick
in my case, it was a spinner.
I just moved it from under <fieldset> to under <fieldset><ul><li> and added a comment noting this bug.

Updated

6 years ago
Duplicate of this bug: 647169

Comment 19

6 years ago
The nemo's solution works, but if we try to put a <legend> inside the <div>, in Firefox 3.6 the <fieldset> get broken. 

(Sorry for my English.)
This was fixed by bug 656130.
Assignee: nobody → ehsan
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Depends on: 656130
Resolution: --- → FIXED
Target Milestone: --- → mozilla10
(Reporter)

Comment 21

6 years ago
As I can see it has not been fixed.
If you open enclosed testcase: https://bugzilla.mozilla.org/attachment.cgi?id=431763 you will be able to see that the bug still exists.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This was marked fixed for what will become Firefox 10. Are you running a nightly build?
(Reporter)

Comment 23

6 years ago
Sorry for the confusion, I thought that it was fixed for current stable version of Firefox.
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago6 years ago
Resolution: --- → FIXED

Comment 24

6 years ago
This should be reopened. Zenich's test case is still failing: https://bugzilla.mozilla.org/attachment.cgi?id=431763
RB, please file a new bug if you think there's something wrong with it.
Please check that it's not known already.  Thanks.

Comment 26

3 years ago
I can confirm this bug is still present... and annoying in Firefox 29.0.

Updated

3 years ago
Depends on: 1005791
Thi(In reply to nicolas.ternisien from comment #26)
> I can confirm this bug is still present... and annoying in Firefox 29.0.

You're seeing bug 942341, which is similar but distinct.
(and a relatively recent behavior-change, rather than this bug being "still present")
You need to log in before you can comment on or make changes to this bug.