Closed Bug 1606305 Opened 1 year ago Closed 1 year ago

Wrong intrinsic width for pre element with font-size: 0.


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

71 Branch
Not set



Tracking Status
firefox74 --- fixed


(Reporter: enrique.arizonbenito, Assigned: jfkthame)



(5 files)

Attached file bugExample.tar.gz

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:71.0) Gecko/20100101 Firefox/71.0

Steps to reproduce:

Rendering a -something like weird/non-standard- layout (See attached example)

Actual results:

The calculated width for pre elements is not correct.

The widh is calculated properly "most-of-the-times", but depending on the internal content of the pre element it suddenly "explodes" in width. This looks to happen in latest versions of firefox 69+

Expected results:

The calculated width should adjust properly.
See attached example with input html and rendered output.
Same content is rendered as expected on Chrome.

It looks to be related to the script making the font-size equal to ZERO. By just increasing to 0.0001 it renders properly.

Hi, Enrique!

Thanks for your contribution!

I couldn't reproduce the described behavior in:

Ubuntu 18.04 LT
Firefox 71.0
Nightly 73.0a1 (2020-01-03) (64-bit)

Will add product and component to keep on track, it seems like an easy issue to reproduce.

Please let us know if this issue is reproduced in the latest Nightly edition. You can download it from here:

If you still have the issue please create a new profile, you have the steps here:

Once you have all this information, please let us know so we can continue investigating.


Flags: needinfo?(enrique.arizonbenito)

I tried with Nightly. The bug persists. Digging further, it looks to be related to the parsing of the CSS.

"font-size: 0em;" fails.

"font-size: 0.em;" works (Adding a dot after the 0)

"font-size: 0.0em;" fails. (Adding a second 0 after the dot)

Flags: needinfo?(enrique.arizonbenito)

Hi, Enrique!

Thanks for clarifying this, I am going to add product and component to this issue in order to move on. If you have some other details or specifications you can dd it on a thread below.


Component: Untriaged → CSS Parsing and Computation
Product: Firefox → Core

(In reply to Enrique from comment #3)
Can you elaborate? I don't see any different style for the <pre> element involved or such due to different font-size parsing.

Flags: needinfo?(enrique.arizonbenito)

Not sure how to elaborate. Just another online example. This time it works when font-size is greater or equal to 0.0006rem:

Edit style rule using rem units:

[zoom] { font-size:0.0001rem; } / ERROR! . The element width "explodes". */
[zoom] { font-size:0.0002rem; } / ERROR! . The element width "explodes". */
[zoom] { font-size:0.0003rem; } / ERROR! . The element width "explodes". */
[zoom] { font-size:0.0004rem; } / ERROR! . The element width "explodes". */
[zoom] { font-size:0.0005rem; } / ERROR! . The element width "explodes". */
[zoom] { font-size:0.0006rem; } / OK! */
[zoom] { font-size:0.0007rem; } / OK! */

Edit style rule using em units:
[zoom] { font-size:0.00em; } / ERROR! . The element width "explodes". */
[zoom] { font-size:0.001em; } / OK! */
[zoom] { font-size:0.000em; } / ERROR! . The element width "explodes". */
[zoom] { font-size:0.0001em; / ERROR! . The element width "explodes". */
[zoom] { font-size:0.0006em; } / OK! */

I've not been able to find a common error-pattern, but it looks "something somewhere" has problems to handle zero or "close-to-zero" values.

Flags: needinfo?(enrique.arizonbenito)

Ok, so I see what happens, mostly.

The <pre> element is floating, so it gets sized at its intrinsic size. It seems that when we're computing intrinsic sizes, we ignore the font-size: 0 content altogether, and thus don't break...

Ever confirmed: true
Summary: Wrong calculated width for pre element → Wrong intrinsic width for pre element with font-size: 0.
Component: CSS Parsing and Computation → Layout: Text and Fonts
Attached file Reduced test-case.

The border should be just around the text

Ah, yes... we short-circuit textrun initialization when the font size is zero (or close enough to zero that it rounds down). But unfortunately we then fail to record the locations of important characters like <newline> in the textrun, and that's what leads to this issue.

<tab> is similarly affected; if you try an example like

data:text/html,<pre style="font-size:0px;-moz-tab-size:100px"><span style="font-size:12px">foo</span>&%239;<span style="font-size:12px">bar</span>

we fail to properly tab the word "bar" over to start at 100px from the left margin.

Looks like a straightforward fix...

Assignee: nobody → jfkthame

This fixes the bug reported here, as well as the related <tab> example; we should also add a couple of simple reftests (but I don't have time tonight).

Attachment #9120337 - Attachment description: Bug 1606305 - Add reftests for handling of <newline> and <tab> when font-size is zero. r=emilio → Bug 1606305 - Add WPT reftests for handling of <newline> and <tab> when font-size is zero. r=emilio
Pushed by
Don't forget to record the location of newline and tab characters when creating a textrun for a zero-size font. r=emilio
Add WPT reftests for handling of <newline> and <tab> when font-size is zero. r=emilio
Created web-platform-tests PR for changes under testing/web-platform/tests
Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla74
Upstream PR merged by moz-wptsync-bot
You need to log in before you can comment on or make changes to this bug.