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

Steps to reproduce:

Honestly I'm not sure whether it's a bug, but the behavior is different than Chrome. See attached code.

Actual results:

::after content in <pre> tag is aligned to top and looks broken

Expected results:

::after content in <pre> tag is aligned to middle just like outside of <pre> tag

Managed to reproduce this issue on Win 10, Ubuntu 22 and macOS 12 ARM with Firefox 120.0a1 (20230928215127) and Firefox 119.0b3 (20230928191344).
It's not reproducible on Edge and Chrome.
Setting as NEW so the developer team can have a look.

Moving this to Core > DOM: Editor component, if this is not the right component please assign a more suitable one. Thanks!

It seems that this is caused by the baseline difference caused by the font-family difference between <pre> and the others. Once I specify vertical-align for ::after, I see same result unless setting baseline value.

The severity field is not set for this bug.
:jwatt, could you have a look please?

For more information, please visit BugBot documentation.

Here's a testcase with a variety of related scenarios, some with ::after { display:inline-block}, some with a literal <div> that has display:inline-block.

We have a large baseline for the orange box in the pseudo pre and ib pre with space sections.
Chrome agrees with us on the large baseline for the ib pre with space section.

Seems to boil down to us creating line + text frame with an empty string:

Inline(span)(0)@7fc188df9b38 parent=7fc188df9a20 next=7fc188df9ff0 (x=0, y=2010, w=5290, h=900) ink-overflow=(x=0, y=-1950, w=5290, h=2850) scr-overflow=(x=0, y=-1950, w=5290, h=2850) [content=7fc184904dc0] [cs=7fc184834608] <
  Block(_moz_generated_content_before)(-1)@7fc188df9be0 parent=7fc188df9b38 next=7fc188df9d98 (x=0, y=-1950, w=480, h=480) [content=7fc184909160] [cs=7fc184834708:before] <
    line@7fc188df9d48 count=1 state=inline,clean,prevmarginclean,not-impacted,not-wrapped,no-break,clear-before:none,clear-after:none(x=120, y=120, w=0, h=4500) ink-overflow=(x=120, y=2670, w=0, h=0) scr-overflow=(x=120, y=2670, w=0, h=0) <
      Text(0)""@7fc188df9ca8 parent=7fc188df9be0 (x=120, y=2670, w=0, h=0) [content=7fc184905780] [cs=7fc184834c08:-moz-text] [run=7fc188d59b00][0,0,T] 
    >   
  >
  Text(0)"pseudo pre"@7fc188df9d98 parent=7fc188df9b38 next=7fc188df9e38 (x=480, y=0, w=4330, h=900) [content=7fc184905580] [cs=7fc184834508:-moz-text] [run=7fc1accfe2f0][0,10,T] 
  Block(_moz_generated_content_after)(-1)@7fc188df9e38 parent=7fc188df9b38 (x=4810, y=-1950, w=480, h=480) [content=7fc1849091f0] [cs=7fc184834808:after] <
    line@7fc188df9fa0 count=1 state=inline,clean,prevmarginclean,not-impacted,not-wrapped,no-break,clear-before:none,clear-after:none(x=120, y=120, w=0, h=4500) ink-overflow=(x=120, y=2670, w=0, h=0) scr-overflow=(x=120, y=2670, w=0, h=0) <
      Text(0)""@7fc188df9f00 parent=7fc188df9e38 (x=120, y=2670, w=0, h=0) [content=7fc184905800] [cs=7fc184834d08:-moz-text] [run=7fc188d59c00][0,0,T] 
    >   
  >
>

... which then forces the line height to be set, since preMode is true.

Comparatively, empty inline-block div would have zero line:

Inline(span)(3)@7fc188dfa068 parent=7fc188df9a20 next=7fc188dfa340 (x=0, y=6810, w=3558, h=900) [content=7fc184904ee0] [cs=7fc184834608] <
  Block(div)(0)@7fc188dfa110 parent=7fc188dfa068 next=7fc188dfa1d8 (x=0, y=240, w=480, h=480) [content=7fc184904f70] [cs=7fc184834a08] <
  >
  Text(1)"ib pre"@7fc188dfa1d8 parent=7fc188dfa068 next=7fc188dfa278 (x=480, y=0, w=2598, h=900) [content=7fc184905680] [cs=7fc184834508:-moz-text] [run=7fc188d1db60][0,6,T] 
  Block(div)(2)@7fc188dfa278 parent=7fc188dfa068 (x=3078, y=240, w=480, h=480) [content=7fc184909040] [cs=7fc184834a08] <
  >
>

We shouldn't generate frames for pseudo-elements with empty content.

This test-case also behaves differently from other browsers. If you change the "" by " ", then Chrome starts behaving like us.

Maybe we shouldn't let empty text nodes contribute to baselines?

The .before empty text node provides a baseline in Blink but the others don't. That's because in Chromium their "is editing text" check goes before the "is empty" check here

So... I guess I don't feel that terrible about the approach in comment 7 after all, https://drafts.csswg.org/css2/#propdef-content is a bit ambiguous but seems reasonable to not generate a node for the empty string.

At the very least we should file some spec issues to clarify whether an empty text-node provides a baseline, or put this special-case into the spec.

Hm... Played around with test cases a bit more. Taking out white-space: pre the two x's align.

Ultimately, the fact that this behaviour depends on white-space seems... wrong, which points to :emilio's solution as a better approach..

(In reply to David Shin[:dshin] from comment #11)

Created attachment 9363972 [details]
Empty linebox giving baseline

Hm... Played around with test cases a bit more. Taking out white-space: pre the two x's align.

That is most likely because we optimize out the white-space only text node otherwise, see this and callers.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #12)

(In reply to David Shin[:dshin] from comment #11)

Created attachment 9363972 [details]
Empty linebox giving baseline

Hm... Played around with test cases a bit more. Taking out white-space: pre the two x's align.

That is most likely because we optimize out the white-space only text node otherwise, see this and callers.

But if I replace pre with pre-line, I still get the second empty line in #dut:

Block(div id=dut)(0)@7fde89741b38 parent=7fde89741a20 next=7fde89741e58 (x=0, y=0, w=542, h=1140) [content=7fde81204b80] [cs=7fde856a5708] <
  line@7fde89741db8 count=2 state=inline,clean,prevmarginclean,not-impacted,not-wrapped,forced-break,clear-before:none,clear-after:none(x=0, y=0, w=542, h=1140) <
    Text(0)"x"@7fde89741c00 parent=7fde89741b38 next=7fde89741ca0 (x=0, y=0, w=541, h=1140) [content=7fde81205500] [cs=7fde856a5b08:-moz-text] [run=7fde878e6790][0,1,T] 
    BR(br)(1)@7fde89741ca0 parent=7fde89741b38 next=7fde89741d18 (x=541, y=0, w=1, h=1140) [content=7fde81204c10] [cs=7fde856a5908]
  >
  line@7fde89741e08 count=1 state=inline,clean,prevmarginclean,not-impacted,not-wrapped,no-break,clear-before:none,clear-after:none(x=0, y=1140, w=0, h=0) <
    Text(2)""@7fde89741d18 parent=7fde89741b38 (x=0, y=1140, w=0, h=0) [content=7fde81205680] [cs=7fde856a5b08:-moz-text] [run=7fde856ea500][0,0,T] 
  >
>

... But the x's align nevertheless instead of aligning to the empty text frame (On gdb, the last line skips because it has zero block size and is considered empty).

On the other hand, with pre, the empty line seems to have a size, which causes us to take that baseline:

line@7fde85680e08 count=1 state=inline,clean,prevmarginclean,not-impacted,not-wrapped,no-break,clear-before:none,clear-after:none(x=0, y=1140, w=0, h=1140) ink-overflow=(x=0, y=2040, w=0, h=0) scr-overflow=(x=0, y=2040, w=0, h=0) <
  Text(2)""@7fde85680d18 parent=7fde85680b38 (x=0, y=2040, w=0, h=0) [content=7fde81205300] [cs=7fde81149108:-moz-text] [run=7fde856e9d00][0,0,T] 
>

Backed out for wpt failure on empty-text-baseline-001.html

Backout link: https://hg.mozilla.org/integration/autoland/rev/b24ebcca491e7e5aeec93563f63d888f3cd14e73
Log link: https://treeherder.mozilla.org/logviewer?job_id=436880599&repo=autoland&lineNumber=6491

https://hg.mozilla.org/mozilla-central/rev/8272ad0d7c2d

(In reply to Pulsebot from comment #14)

Pushed by dshin@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/f78453d75438
Empty text line should not give line height even with white-space: pre.
r=layout-reviewers,emilio

== Change summary for alert #40449 (as of Wed, 29 Nov 2023 06:55:07 GMT) ==

Improvements:

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=40449