Closed Bug 450418 Opened 16 years ago Closed 13 years ago

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

Categories

(Core :: Layout: Form Controls, defect)

Product:
Core
Component:
Layout: Form Controls
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla10

People

(Reporter: ihor.zenich, Assigned: ehsan.akhgari)

References

Details

Attachments

(2 files)

testcase
544 bytes, text/html
Details
fieldset relative positioning bug
1.04 KB, text/html
Details
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.
OS: Windows Server 2003 → Windows XP
Version: unspecified → 3.0 Branch
Attached file 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
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.
Oh. Oops. I see Boris has explained what is happening. Thanks! :)
This seems to apply in instances where there is no padding on the fieldset. Other browsers seem to treat the fieldset as expected.
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
Here's a quick example: http://jsfiddle.net/93LRU/ Taken from Bug 635773
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.
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.
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.
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
Closed: 13 years ago
Depends on: 656130
Resolution: --- → FIXED
Target Milestone: --- → mozilla10
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?
Sorry for the confusion, I thought that it was fixed for current stable version of Firefox.
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → FIXED
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.
I can confirm this bug is still present... and annoying in Firefox 29.0.
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")
It seems nicolas, mats and RB are all correct, this is still an issue and should be reopen. Daniel did you actually try the test cases? The fix provided by nemo still works. But this behaviour just seems odd and counter-intuitive.
(In reply to Mikael Sand from comment #29) > It seems nicolas, mats and RB are all correct, this is still an issue and > should be reopen. Mats didn't make any claims here; he simply asked other folks to open a new bug to cover remaining issues, rather than lobbying to reopen this one. And as I noted above: I believe the issues nicolas/RB observed are described in bug 942341, so I don't think a new bug is actually needed -- bug 942341 is the new bug. (Though as noted in bug 942341 comment 8 [and in comment 2 here], the HTML spec doesn't say what to do here, and we've arrived at something that we think is coherent & logical and other browsers haven't necessarily arrived at the same behavior.) > Daniel did you actually try the test cases? Yes. I actually posted a screenshot of one of them over on bug 942341, and a reduced testcase (as a data URL) in bug 942341 comment 7. (See also roc's response over there.)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: