Closed Bug 489100 Opened 17 years ago Closed 4 months ago

absolutely positioned child of relative inline containing block is positioned relative to only first line of inline

Categories

(Core :: Layout: Positioned, defect)

Product:
Core
Component:
Layout: Positioned
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
153 Branch
Tracking Flags:
Tracking Status
firefox153 --- fixed

People

(Reporter: rn214, Assigned: TYLin)

References

(Blocks 5 open bugs)

Details

(Keywords: parity-chrome, webcompat:platform-bug)

User Story

platform-scheduled:2025-12-31
user-impact-score:950

Attachments

(5 files)

Screenshots in Firefox/Konqui/Opera
5.43 KB, application/octet-stream
Details
testcase
378 bytes, text/html
Details
A few more tests, splitting the CB over columns
5.09 KB, text/html
Details
Bug 489100 - Compute inline absolute containing block rect from its first and last continuation. r?#layout
48 bytes, text/x-phabricator-request
Details | Review
Bug 489100 - Add WPTs for abspos under inline element in rtl and vertical writing mode. r?dholbert
48 bytes, text/x-phabricator-request
Details | Review
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.8) Gecko/2009033117 Mandriva/1.9.0.8-0.1mdv2009.0 (2009.0) Firefox/3.0.8 Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.8) Gecko/2009033117 Mandriva/1.9.0.8-0.1mdv2009.0 (2009.0) Firefox/3.0.8 The child element of an inline div is misplaced. It is actually positioned with respect to the top line of that div, rather than the bottom. Both Opera and Konqueror behave differently, so this is probably a genuine bug. Reproducible: Always Steps to Reproduce: Look at the following HTML. (I'll attach screenshots shortly) <h2>Firefox</h2> BEFORE <div style="position:relative; display:inline; background-color:#0F0"> This is an inline div.<br>Here is the second line<br>And a third line<br>And now a fourth and final line <div style="position:absolute; left: 0; bottom: 0; display:inline; background-color:#F00"> x </div> </div> AFTER Actual Results: The red 'x' is positioned at the TOP of the parent div. It should be placed at the bottom. Both Firefox 3.5 and Firefox 3.6a1 (today's nightly) show the same behaviour. But Opera and Konqueror show different behaviour. Expected Results: The inner div has "bottom: 0", therefore the bottom of the 'x' should be aligned with the bottom of the parent div.
Here is a tarball of 3 png files, showing the rendering in Firefox, Konqueror (3.5) and Opera (9.64) respectively. The HTML source of all of them is exactly the same (excepting that I changed the <h2> to show the correct name)
Component: General → Layout: Block and Inline
Product: Firefox → Core
QA Contact: general → layout.block-and-inline
Version: unspecified → Trunk
dupe of bug 5016, I think
I think you're probably right. 10 years, and half-a-million bugs later ;-) Any chance of a fix? Web designers now tend to regard Firefox as the de-facto implementation of the standards, and test here first.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
Reopening per bug 5016 comment 32.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Attached file testcase —
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8 Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090202 Minefield/3.2a1pre Confirmed.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: wanted1.9.2?
Flags: blocking1.9.2?
OS: Linux → All
Hardware: x86_64 → All
Summary: Child of inline div is positioned incorrectly. → absolutely positioned child of relative inline positioned relative to only first line of inline
There is an explanation of what needs to be done to fix this starting from bug 5016 comment 17.
Flags: wanted1.9.2?
Flags: wanted1.9.2-
Flags: blocking1.9.2?
Flags: blocking1.9.2-
Blocks: 743599
Blocks: 766530
Issue 215 Summary Make it undefined what containing block is formed by a relpos inline that splits across multiple lines URI http://test.csswg.org/suites/css2.1/20110111/html4/containing-block-032.htm (which was removed from /latest/ and /nightly/ : http://test.csswg.org/suites/css2.1/latest/html4/containing-block-032.htm http://test.csswg.org/suites/css2.1/nightly/html4/containing-block-032.htm ) Resolution Make undefined. Status Closed. http://wiki.csswg.org/spec/css2.1#issue-215 " If the element has 'position: absolute', the containing block is established by the nearest ancestor with a 'position' of 'absolute', 'relative' or 'fixed', in the following way: In the case that the ancestor is an inline element, the containing block is the bounding box around the padding boxes of the first and the last inline boxes generated for that element. In CSS 2.1, if the inline element is split across multiple lines, **_the containing block is undefined_**. " CSS2.1, §10.1 Definition of "containing block" http://www.w3.org/TR/CSS21/visudet.html#containing-block-details So, I'd say this bug is not valid for CSS 2.1. CSS3 is a bit different: " If the element has ‘position: absolute’, the containing block is established by the nearest ancestor with a ‘position’ other than ‘static’, in the following way: In the case that the ancestor is inline-level, the containing block depends on the ‘direction’ property of the ancestor: If the ‘direction’ is ‘ltr’, the top and left of the containing block are the top and left content edges of the first box generated by the ancestor, and the bottom and right are the bottom and right content edges of the last box of the ancestor. " CSS Positioned Layout Module Level 3, Working Draft 7 February 2012 §3.1. Definition of containing block http://www.w3.org/TR/css3-positioning/#def-containing-blocks as it now refers to content edges (and not padding edges) and it does not specify what happens if the positioned ancestor inline box is split in multiple line boxes.
Is there any push at all to implement this? It's inconsistent with all major browsers causing me quite a few headaches. It's been half a year since this was last discussed which is quite alarming.
Still experiencing this bug, and can confirm it is still inconsistent with Chrome and IE implementation.
Firefox 49.0.2 fails this test: http://www.gtalbot.org/BrowserBugsSection/css21testsuite/containing-block-017-GT.html as far as CSS2.1 and CSS2.2 are involved. Note that there is only 1 line box in such test. Opera 12.16 (Presto engine), Chrome 54.0.2840.90, Chrome 56.0.2902.0, IE11 and Edge pass this test. - - - - - - - If the positioned ancestor is an inline element split across multiple lines, then Firefox complies with CSS2.x since, in such case, "the containing block is undefined". And all the tests we had with such multiple lines have been removed from CSS2.1 test suite. - - - - - - - (In reply to matt from comment #11) > Is there any push at all to implement this? It's inconsistent with all major > browsers (In reply to tdmalone from comment #12) > Still experiencing this bug, and can confirm it is still inconsistent with > Chrome and IE implementation. Chrome (all versions), IE11 and Edge (all versions) do not comply with CSS3 (and never did) when the positioned ancestor is an inline element *_split across multiple lines_*. Only Opera 12.16 (Presto engine) complies, otherwise passes the tests we have. Regarding CSS Positioned Layout Module Level 3, section 3.1. Definition of containing block https://www.w3.org/TR/css-position-3/#def-cb there will be a CSSWG discussion this month to decide on a proposed modification of CSS3. More info: https://github.com/w3c/csswg-drafts/issues/609
https://github.com/w3c/csswg-drafts/issues/609 proposes changes to the spec here, although probably only a minor adjustment to what we need to do to fix this.
See Also: → https://github.com/w3c/csswg-drafts/issues/609
In today's teleconference the CSS WG accepted the proposal in https://github.com/w3c/csswg-drafts/issues/609#issuecomment-259058527
Component: Layout: Block and Inline → Layout: R & A Pos
Just poking through quickly now, but there may be more information on this in bug 5016 and bug 255139.
Blocks: 1533151
See Also: → 255139
See Also: → 1544146
See Also: 1544146 →

The relevant spec text is in css-position-3.

Keywords: parity-chrome
Summary: absolutely positioned child of relative inline positioned relative to only first line of inline → absolutely positioned child of relative inline containing block is positioned relative to only first line of inline
Webcompat Priority: --- → ?
Webcompat Priority: ? → P3
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 8 duplicates.
:dholbert, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dholbert)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(dholbert)

We have these 2 tests (Ahem font must be installed on your system)

http://www.gtalbot.org/BrowserBugsSection/css21testsuite/containing-block-031.html

http://www.gtalbot.org/BrowserBugsSection/css21testsuite/containing-block-032.html

that can be adjusted to be submitted to WPT once Issue 8284 https://github.com/w3c/csswg-drafts/issues/8284 is resolved.

[Edit]
I am really eager to submit these because we have been keeping these for over 13 years now:
https://lists.w3.org/Archives/Public/public-css-testsuite/2010Jul/0046.html
[/Edit]

I think bug 489207 and bug 743599 should be resolved as DUPLICATEs.

Thanks. And yeah, let's implement whatever behavior shakes out of that spec issue (being discussed in the CSSWG meeting right now).

Duplicate of this bug: 489207
Duplicate of this bug: 743599
See Also: → 629059

CSSWG resolution:

RESOLVED: in LTR-tb the top-left corner is the top-left corner of the top-left-most fragment of the first line, and the bottom and right edges are bottommost and rightmost edges of all the fragments. Directionality comes from the inline

(with analogous writing-mode-informed directions for other direction/writing-mode setups. As noted at the end of the resolution, the direction/writing-mode of the inline element, i.e. the thing forming the abspos containing block, is what matters.)

See Also: → https://github.com/w3c/csswg-drafts/issues/8284

The linked webcompat issue (https://webcompat.com/issues/58613) is no longer reproducible as the site has changed their design, resetting Webcompat priority

Webcompat Priority: P3 → ---
See Also: → 1915992
Blocks: 1915992
See Also: 1915992 →
See Also: → 1918504
See Also: → 1938534

To assist in triaging comprehensive-webcompat bugs, based on whether they're scheduled or not:

Based on impact here, I think it's safe to say that this is one of our highest-priority layout webcompat bugs, but it's also probably high-complexity if I'm remembering things correctly, so I don't know that we can commit to having it fixed anytime soon. But I think it's safe to say that we should plan to fix this by the end of the year (which is pretty far out).

Hence: setting platform-scheduled:2025-12-31 to take this off of the unscheduled-high-priority-webcompat-bugs list.

User Story: (updated)
See Also: → 1978619
User Story: (updated)
Blocks: 2001098
User Story: (updated)
User Story: (updated)
User Story: (updated)
User Story: (updated)
User Story: (updated)

I'm planning to look into this bug, and break it down if needed.

User Story: (updated)
Flags: needinfo?(aethanyc)
Blocks: 2038072
Assignee: nobody → aethanyc
Status: NEW → ASSIGNED
Flags: needinfo?(aethanyc)
User Story: (updated)

In order to compute the rect, we need to have all the inline continuations
reflowed and placed. Therefore, this patch introduces a new phase in
nsBlockFrame::Reflow() to reflow all the absolute descendants under inline
containing blocks, and adds the absolute descendants' overflow areas into inline
frames and lines' overflow areas.

Blocks: 2041551
Pushed by aethanyc@gmail.com: https://github.com/mozilla-firefox/firefox/commit/1e2c72742664 https://hg.mozilla.org/integration/autoland/rev/dc1e78a2d1bd Compute inline absolute containing block rect from its first and last continuation. r=layout-reviewers,dholbert https://github.com/mozilla-firefox/firefox/commit/6c2a44988b13 https://hg.mozilla.org/integration/autoland/rev/22bcef891f2d Add WPTs for abspos under inline element in rtl and vertical writing mode. r=dholbert

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/60127 for changes under testing/web-platform/tests

https://hg.mozilla.org/mozilla-central/rev/dc1e78a2d1bd
https://hg.mozilla.org/mozilla-central/rev/22bcef891f2d

Status: ASSIGNED → RESOLVED
Closed: 17 years ago → 4 months ago
status-firefox153: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 153 Branch

Upstream PR merged by moz-wptsync-bot

No longer blocks: 1904875
Duplicate of this bug: 1904875
Duplicate of this bug: 1998902
No longer blocks: 2008478
Duplicate of this bug: 2008478
No longer blocks: 2011844
Duplicate of this bug: 2011844
Duplicate of this bug: 1923508
Blocks: 1718596
Duplicate of this bug: 1683820
No longer blocks: 1919733
Duplicate of this bug: 629059
See Also: 629059 →
Duplicate of this bug: 2011669
No longer duplicate of this bug: 2011844
Blocks: 2008478
No longer duplicate of this bug: 2008478
Blocks: 2011844
No longer duplicate of this bug: 1998902
Blocks: 1904875
No longer duplicate of this bug: 1904875
QA Whiteboard: [qa-triage-done-c154/b153]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: