If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Wrong positioning for absolute positioned elements

RESOLVED INVALID

Status

()

Core
Layout
RESOLVED INVALID
9 years ago
6 years ago

People

(Reporter: Eugen Konkov, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; ru; rv:1.9) Gecko/2008052906 Firefox/3.0

see attached file

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
(Reporter)

Comment 1

9 years ago
Created attachment 326271 [details]
test case
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Eugen, do you have the source of that page or an url somewhere?
(Reporter)

Comment 3

9 years ago
Created attachment 326629 [details]
test case
(Reporter)

Updated

9 years ago
Attachment #326629 - Attachment is obsolete: true
(Reporter)

Comment 4

9 years ago
Created attachment 326630 [details]
test case
Attachment #326271 - Attachment is obsolete: true
(Reporter)

Updated

9 years ago
Attachment #326271 - Attachment is obsolete: false
(Reporter)

Comment 5

9 years ago
Comment on attachment 326630 [details]
test case

type something long in input field near Fetch
Right and bottom for absoluted positioned elements that are replaced doesn't work anymore. That is according to CSS2.1. See bug 423397.
A text input is a replaced element, so that is why the text input is wider now with your testcase.

For the rest, I don't really see a difference compared to FF2 with your testcase.

Comment 7

9 years ago
Same problem, different explanation (check testcase):

FF3 do not calculate position relative to its closest positioned ancestor when an absolute positioned table is contained inside another absolute positioned table (using relative to initial containing block => window)

Comment 8

9 years ago
Created attachment 327140 [details]
Calculates position relative to wrong object

Comment 9

9 years ago
It seems to me that my comment and test-case is a separate case?

Eugen Konkov's testcase may not be a bug and I believe as Martijn Wargers that this was the same in FF2:

FF3 gives INPUT a width: 151px (fontSize=13px) ( and length: 149 (??)) as default 
(INPUT has no size or width attribute and no width or max-width in style)

Confusion around these issues is very common and may be partly due too:

- Setting width or max-width on containing element is not respected (bug ?)
- Setting width-attribute has no effect (bug?)
- Setting style='width: 40px' limits width
- Setting style='max-width: 40px' limits width more (?) (bug?)

Comment 10

6 years ago
(In reply to Terje Rosenlund from comment #7)
> Same problem, different explanation (check testcase):

Completely differen issue. What you describe is bug 10209 and/or bug 63895. There is a patch on the way in another bug that will fix those issues.

(In reply to Terje Rosenlund from comment #9)
> - Setting width or max-width on containing element is not respected (bug ?)
> - Setting width-attribute has no effect (bug?)
> - Setting style='width: 40px' limits width
> - Setting style='max-width: 40px' limits width more (?) (bug?)

All those cases appear to work correctly and identically in Firefox and other browsers.

I'll resolve this report as Invalid because the input element behaves correctly.
The table issue has its bugs and does not really fit in here (so I don't dupe the report).
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.