The equivalent Safari issue - https://bugs.webkit.org/show_bug.cgi?id=191198

Thanks for the report and the test case. More ellipsis fun.

Sorry for spoiling the fun (;)), but it happens without text-overflow as well.

(Test case updated)

Looks like inline-abspos issue, happens on NG too (though differently.)

This example has a lot going on: floats, :after content, abspos inside inlines, ellipsis. I've spent 10 minutes looking into it, and I am unsure what exactly is the problem.

Could you create a small reproducible case, with just the features necessary to reproduce the bug? There might be several overlapping bugs here.

#7 - sorry, I started from a single case (the first line, with :after) and tried to make it less special and added more variation in order to see whether it reproduces in more cases.

I removed anything (or most things?) that seems unnecessary to reproduce and forked it here -
https://codepen.io/phistuck/pen/dQoeNb

Just make sure you look at the original as well after it is fixed, just to make sure because it does seem to be the same issue (and if not, maybe file bugs for sub-issues)...

Thank you!

And another fork without the unnecessary hovering workaround -
https://codepen.io/phistuck/pen/GwJGqO

Thanks for the reduced test case. The reduced test case renders identically on NG and Legacy.

But NG fails for a different reason from Legacy. Maybe I can fix it with kojii's help.

I've attached a cleaner test case that causes a DCHECK(!NeedsLayout()) for abspos Element. I think we should fix this if we can, at least to avoid DCHECK.

This is what test looks like:
<div id="container">
  <span class="containining_block">
     <span class="float">
       Text
       <span class="abspos"></span>
     </span>
  </span>
</div>

In NG, abspos fragments whose containing block is inline are positioned by containing block's container. 

In the example above, running NGOutOfFlowLayoutPart::Run on #div should position #abspos. 

It does not, because #abspos NGOutOfFlowPositionedDescendant.inline_container is NULL.

The cause for this is that NGInlineLayoutAlgorithm's NGInlineLayoutStateStack does not contain inline container.

This can be fixed by obtaining inline_container from Legacy when not available from NG. Here is the fix:

https://chromium-review.googlesource.com/c/chromium/src/+/1321167/

If inline_container gets assigned correctly, one more problem remains. The inline_container should be used to generate containing block dimensions for abspos. In this example, inline_container has not generated any fragments, so there is no dimensions information. Because of this, we run into NOTIMPLEMENTED() in ng_out_of_flow_layout_part.cc:129

I ran into missing fragments problem when generating outlines too. Maybe we can fix this after outlines are fixed?

Deleted: test.html 407 bytes

test.html 407 bytes View Download

Thank you for the test from me too.

+cc our float experts.

Should abspos compute its static position across float container? I don't know the answer, but the test in #9 fails in all browsers as far as I tested; Blink, Gecko, and Edge.

#9 looks correct to me. Add a border to the relatively positioned inline, and the test starts behaving as expected in Blink, Edge and Gecko. I guess the issue is that when the inline is empty (the float is taken out), no line box is created?

Presto passes the test without any modifications! :)

BTW: no static position involved in that test. right and top are set to 0.

I see, thank you Morten. So we should probably separate the case where the line box is empty and is not empty. Confirmed non-empty case works on Gecko, Edge, Blink, but not in LayoutNG.

So when floats are between abspos and its containing block, the containing block maybe in a different inline formatting context. Interesting.

> no static position involved in that test. right and top are set to 0.

Right, mistaken, containing block. And wow, nice, Presto.

Wow, looks like only Firefox (and maybe Presto Opera, but irrelevant to interoperability at this point) gets this right, I guess (the red rectangle appears much higher than in Chrome for some reason, not sure which is right). Internet Explorer 11 and Edge 17 disregard the position: relative at all.

What worries me about the original test case is that triggering a re-layout does fix things, so the engine knows how it should look, but it skips a step when first laying things out.

Empty line box is tricky, its position is not well-defined when margin collapsing occurs, and it changes when it's not empty (e.g., text is inserted or margin/border/padding etc. are applied.) Interesting to find out how empty line box positioning is not interoperable, but I guess the original problem is not about that, it's about containing block is in different inline formatting context.

Let's fix that first, and see if problems still remain in the original tests.

By the way, Edge 18 (Insider) gets all of the test cases right (like Chrome after hovering, not like Firefox), as opposed to Edge 17. I guess they found compatibility issues there.

Can you tell whether the Firefox behavior of showing the red rectangle a bit higher is a bug, or a Chrome issue that it does not? If it is a Firefox bug, I would file it.

For reference, here is the Firefox rendering.

Deleted: firefox-empty-absolute-inline-within-relative.png 5.1 KB

	firefox-empty-absolute-inline-within-relative.png 5.1 KB View Download

> Can you tell whether the Firefox behavior of showing the red rectangle a bit higher is a bug...

I think it's undefined. This empty line box is "certain zero-height line boxes" mentioned in the 2nd bullet list item in margin collapsing:
https://drafts.csswg.org/css2/box.html#collapsing-margins

So when margins collapse across this line box, AFAIU, the position of this "certain zero-height line boxes" isn't clear to me. Maybe you can raise to csswg to see if it's defined somewhere else.

Allow me to confirm, the empty line box case is only in your minimized case, not in the original stackoverflow, since it did work, correct? Since this issue contains two problems, I'd like to understand which problems we're talking about.

> Allow me to confirm, the empty line box case is only in your minimized case, not in the original stackoverflow

The original (forget StackOverflow) test case is this -
https://codepen.io/phistuck/pen/pQzmjj
<span class="after"> (or its :after equivalent) has some content, so it is not an empty line box, right?

> since it did work, correct?
I am not sure what you are asking here... I tried to remove whatever I could (including text) from the original test case because @atotic found it too convoluted. I did not test the minimized test case in other browsers at the time - I guess I removed too much.

By the way - without float: left, Firefox and Chrome render identically (and there is no bug).

> I guess I removed too much.

Yeah, empty line box case is more non-interoperable, and atotic@ is tracking at  issue 903578 . It has some tests.

Assuming there are issues that appear on non-empty line box case, great if this issue can focus on it. I believe the original problem was about when the abspos is in a float, and its containing block is ancestor of the float?