1450591 - Elements with "position:absolute" or "position:fixed" in text break text flow

Status: NEW

(Core :: Layout: Text and Fonts, defect, P3)

Description

[joshuapowlison]

Attachment: firefox-absolute-test.html

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36

Steps to reproduce:

I had a sizable paragraph of text in a p tag.

Each letter was handled specially: each was a span with two spans inside.

The first was absolutely positioned and contained the letter.

The second was positioned regularly and also contained the letter.

(you can see the demo for an example and test)


Actual results:

The text would break in odd spots and would not line up between the absolutely positioned letters and regularly positioned ones. For example, "text" might be broken as
"tex
t"

Each character was essentially treated as an individual inline-block with no regards for the text flow of the regular text. The correct flow of the text wasn't recognized.


Expected results:

The absolutely positioned spans should not effect the flow of the regular spans. The absolutely positioned letters should fit perfectly over the regular letters. (The correct response can be seen in Chrome and Edge.)

Comment 1

[u554753]

Hi joshuapowlison,

Thanks for reporting this issue. I was able to reproduce it with the following specifications:
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0

Comment 2

[Xidorn Quan [:xidorn] UTC+10]

I think there are two separate problems:
1. absolutely-positioned elements breaks text flow
2. the hypothetical box of absolutely-positioned element is computed before line breaking is applied

The first is definitely a problem of text layout, and the fix should probably happen somewhere around BuildTextRunsScanner::FindBoundaries[1].

The second one I'm not completely sure. Probably should be a problem in block layout or so.


[1] https://searchfox.org/mozilla-central/rev/2ce99e8054b0ff6ed1adf484aeaacacf2fea084c/layout/generic/nsTextFrame.cpp#1331

Comment 3

[Xidorn Quan [:xidorn] UTC+10]

Attachment: simplified testcase for text flow issue

Comment 4

[Xidorn Quan [:xidorn] UTC+10]

For the second problem, Chrome isn't completely correct either, i.e. it doesn't always use the position as if it is placed statically. The spec also gives leeway to implementations by
> But rather than actually calculating the dimensions of that hypothetical box, user agents are free to make a guess at its probable position. 

So maybe Chrome uses a better approach to guess the position in this case.

Comment 5

[Jonathan Kew [:jfkthame]]

(In reply to Xidorn Quan [:xidorn] UTC+10 from comment #2)
> I think there are two separate problems:
> 1. absolutely-positioned elements breaks text flow

This is bug 1283222. I've been hoping to get back to test Jeremy's patch there further and see if it's ready to be landed.

> 2. the hypothetical box of absolutely-positioned element is computed before
> line breaking is applied

Bug 1418472 might be related to this. Another factor in the issue (there and here) may be do with whether the placeholder for the out-of-flow frame is kept in the line before the break, or goes into the line after the break.