1527265 - Style inspector strange behavior with ::after pseudo-element

Status: RESOLVED DUPLICATE of bug 489100

(Core :: Layout: Block and Inline, defect, P3)

Description

[Vlad Fateev]

Attachment: firefox-bug.html

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

Steps to reproduce:

Version: 64.0.2 (64-bit)

JSFiddle as an alternative to attached HTML: https://jsfiddle.net/g2fku6r1/10/

1. Open attached HTML file
   1.1. Star icon overlaps second link's text (covers word "With")

2. Open element inspector and find ::after pseudo-element near "Test Link With Long Label"

3. In style inspector find this CSS rule:
   .link::after {
   ...
   right: 0;
   ...
   }

4. Click checkbox near "right" rule to disable it and then click again to enable it back
   4.1. Also, instead of disabling-enabling CSS rule, you can double-click text "Test Link With Long Label" in DOM inspector to enter edit mode and then "apply" the changes without actually changing the text (for example by clicking outside the editable text)

Actual results:

Star icon now don't overlap link's text and placed before the text

Expected results:

Nothing has to changes.
Actually, in Chrome, point 1.1 does not take place, the star icon don't overlap link's text and drawn after this text immediately after page loading. I don't know what behavior is preferred but anyway it seems like a bug

Comment 1

[Razvan Caliman [:rcaliman]]

Attachment: absolute-positioning-display-inline.mp4

I couldn't reproduce the workaround with DevTools. Toggling the properties or editing the text doesn't change the layout. This is most likely a CSS layout issue/question.

The root cause is perhaps in the way the absolute positioning is treated within fragmented inline elements.

In Firefox, the text gets fragmented into two boxes and it seems the pseudo-element is positioned against the first one (see attached video). The padding-right does not affect individual fragments, as expected.

In Chrome, the fragmented text seems to reside in a single box and the pseudo-element is absolutely positioned in relation to this box.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Smells a lot like the other bugs hanging off bug 255139.

Comment 3

[Razvan Caliman [:rcaliman]]

On further research, this seems like a duplicate of Bug 489100.