Closed Bug 1680706 Opened 4 years ago Closed 2 years ago

A block has wrong height when it has white-space:pre and an empty child text node

Categories

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

Firefox 83
defect

Tracking

()

RESOLVED DUPLICATE of bug 1731120

People

(Reporter: jeffreytse.mail, Unassigned)

References

Details

(Keywords: testcase)

Attachments

(5 files)

Attached image 2020-12-04_18-23.png

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.66 Safari/537.36

Steps to reproduce:

create a pseudo element (::before, ::after), then set padding and backgroud-color as below:

.test::before {
content: '';
color: #fff;
background-color: #ff4e00;
padding: 0 .5em;
}

Actual results:

Pseudo element (::before, ::after) has wrong height when its content is empty but padding is non-zero.

Expected results:

It should have no height, because there is no content to spread its height.
And there is no such problem in Chrome browser (my Chrome Version: 87.0.4280.66 (Official Build) (64-bit)), and the display is normal.

Summary: Pseudo element (::before, ::after) has wrong height when its content is empty but padding non-zero → Pseudo element (::before, ::after) has wrong height when its content is empty and padding is non-zero

Hi,
Can you please provide us a test page or a reduced case in order to reproduce this issue.

Component: Untriaged → CSS Parsing and Computation
Flags: needinfo?(jeffreytse.mail)
Product: Firefox → Core
Component: CSS Parsing and Computation → Layout: Generated Content, Lists, and Counters

Hi,
Here is the test page with reduced case to reproduce this issue.
The key point is that the display should be the inline-block.

<!DOCTYPE html>
<html>
  <head>
    <title>This is a test page</title>
    <style>
      pre::before {
        content: attr(data-lang);
        color: #fff;
        background-color: #ff4e00;
        padding: 0 0.5em;
        display: inline-block;
      }
    </style>
  </head>

  <body>
    <figure class="highlight">
      <pre data-lang="python" ><code class="hljs python" data-lang="python"><table class="rouge-table"><tbody><tr><td class="gutter gl"><pre class="lineno"><span class="hljs-number">1</span>
<span class="hljs-number">2</span>
</pre></td>
<td class="code"><pre><span class="kn"><span class="hljs-keyword">import</span></span> <span class="nn">networkx</span> <span class="k"><span class="hljs-keyword">as</span></span> <span class="n">nx</span>
<span class="kn"><span class="hljs-keyword">from</span></span> <span class="nn">collections</span> <span class="kn"><span class="hljs-keyword">import</span></span> <span class="n">Counter</span>
</pre></td>
</tr></tbody></table></code></pre>
    </figure>
  </body>
</html>

Screenshot on Firefox:

Screenshot on Chrome:

Flags: needinfo?(jeffreytse.mail)
Severity: -- → S4
Component: Layout: Generated Content, Lists, and Counters → Layout: Block and Inline
Priority: -- → P3
Summary: Pseudo element (::before, ::after) has wrong height when its content is empty and padding is non-zero → A block has wrong height when it has white-space:pre and an empty child text node

So what happens in Gecko is that we decide that the block has a line box, given that it has a child box. When we have a line box we apply line-height to it, which gives it some size based on the font in this case. My gut feeling is that we handle this correctly (for Standards mode layout at least), but I haven't read the relevant specs in detail yet...
This is where the size comes from, fwiw:
https://searchfox.org/mozilla-central/rev/c7cf087b6e1384608ca3989f042f12f7cabd0a5f/layout/generic/nsLineLayout.cpp#2282

Keywords: testcase

The last paragraph here seems like it addresses this case:
https://drafts.csswg.org/css-inline-3/#line-boxes

Line boxes that contain no text, ... must be treated as zero-height line boxes ...

It depends on what they mean by "no text" in that sentence.
I would assume an empty text node counts as "no text", but the spec could certainly be more precise on that...
Also, there's no indication that white-space:pre should make a difference (other than for "preserved white space", which this clearly is not) and we do make the height zero for white-space:normal, so our layout for pre seems unintentional to me.

Status: UNCONFIRMED → NEW
Ever confirmed: true

... and it broke <input type=button/submit/reset value="">. We go again:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=21c812309d023d557ea0e92e53d16b434a6d13ac

Assignee: nobody → mats
Status: NEW → ASSIGNED

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Assignee: MatsPalmgren_bugz → nobody
Status: ASSIGNED → NEW

The severity field for this bug is set to S4. However, the following bug duplicate has higher severity:

:jfkthame, could you consider increasing the severity of this bug to S3?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jfkthame)

This appears to have been fixed by bug 1731120.

Status: NEW → RESOLVED
Closed: 2 years ago
Duplicate of bug: 1731120
Flags: needinfo?(jfkthame)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: