2082794 - SVG text not painted when font-size attribute is extremely small, even though on-screen size is normal

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Compagnon]

Attachment: firefox-svg-text-bug-repro.html

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:158.0) Gecko/20100101 Firefox/158.0

Steps to reproduce

1. Open the attached file firefox-svg-text-bug-repro.html in Firefox.
2. The page shows two SVG panels, both 400x200 CSS pixels:
   • Case A: a normal viewBox="0 0 400 200" with font-size="28" on a <text> element.
   • Case B: a viewBox="0 0 0.004 0.002" (scaled down x100000 relative to Case A) with font-size="0.00028" on the equivalent <text> element (also scaled x100000), positioned and styled identically to Case A otherwise (same paint-order="stroke", proportionally scaled stroke-width, same letter-spacing).
   • Because the SVG's own viewBox-to-viewport scale factor is x100000 larger in Case B, the two <text> elements end up with the same final on-screen size — confirmed live on the page via getBoundingClientRect(), printed under each panel.
3. Compare what is visually painted in Case A vs Case B.

Actual results

Case A (normal numbers): the text "HELLO WORLD" is clearly painted, as expected.

Case B (same effective screen size, but tiny raw numbers): nothing is painted - the text is completely invisible, even though:

• the <text> element exists in the DOM,
• getBoundingClientRect() on it reports a normal, non-zero, clearly visible width/height (same as Case A's),
• the circle in the same SVG panel (not text) renders correctly at the expected position/size.

This reproduces, in isolation, a real-world bug in a production web app (an interactive SVG map using a dynamic viewBox for deep zooming, where label font-size is expressed in small "world-space" units that shrink as the user zooms in, so the apparent on-screen text size stays constant). At deep zoom levels, all text labels disappear while all circular markers stay fully visible - exactly matching Case B.

Confirmed NOT reproducible in Chrome, Edge or Opera (both cases render identically and correctly there). Also confirmed this is not a GPU/WebRender compositing issue: forcing gfx.webrender.software = true in about:config does not change the result.

Confirmed NOT reproducible in Firefox 157.0.1 (tested on a separate machine that had not yet received the 158.0 update); confirmed reproducible in Firefox 158.0. The regression appears to have been introduced specifically in the 157 -> 158 update.

Expected results

Case B should render identically to Case A, since both resolve to the same final, on-screen (post-transform) text size. The raw numeric magnitude of the font-size attribute in the SVG's local/user-space coordinate system should not affect whether the text is painted - only the final screen-space size should matter, which is already computed correctly (as shown by getBoundingClientRect()).

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Graphics: WebRender' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Robert Longson [:longsonr]]

the viewBox values are not really in a range we currently support. viewBox values are rounded to 1/60

Comment 3

[Alice0775 White]

Regression window:
https://hg-edge.mozilla.org/integration/autoland/pushloghtml?fromchange=3c36156a38e3738afe6488ea8cfce7cbbc7e0c6b&tochange=6567bdeb3c1e97a75f12fd72d92a6fb4a2cfcc91

Comment 4

[BugBot [:suhaib / :marco]]

:aosmond, since you are the author of the regressor, bug 1681921, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 5

[David Shin[:dshin] [PTO, back Nov 12th]]

This could be reproduced locally on Ubuntu, so the regression does not seem correct. Re-running, I got Bug 2073465, which seems more in the ballpark.

Comment 6

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 2073465

Comment 7

[Jonathan Kew [:jfkthame]]

The patch in bug 2073465 made us snap computed font-size values to an integer number of appUnits, where 1 appUnit = 1/60 px. Unfortunately, that means the tiny font-size used here ends up snapping to zero, and no amount of scaling will then bring back visible glyphs!

I guess a solution here would be to disable the appUnit snapping for really small sizes (say, <= 0.1px).

Comment 8

[Jonathan Kew [:jfkthame]]

Attachment: Bug 2082794 - Don't snap very small font-size to integer appUnits, to avoid tiny values going to zero. r=#style

Only including a mismatch reftest for now, to confirm that the tiny-then-scaled text
does not render blank. A proper matching reftest would be nice but currently ends up
with a huge amount of "fuzz" due to blurry rendering of the extremely-scaled test;
see bug 2082801.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/0a1bb6167c47
https://hg.mozilla.org/integration/autoland/rev/9828e32964d3
Don't snap very small font-size to integer appUnits, to avoid tiny values going to zero. r=firefox-style-system-reviewers,emilio

Comment 10

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/9828e32964d3

Comment 11

[BugBot [:suhaib / :marco]]

The patch landed in nightly and beta is affected.

:jfkthame, please make an uplift decision for beta:

• For beta, nominate the patch for beta uplift approval if the fix should be included in this release, or set status-firefox159 to wontfix if the fix can wait for the next release.

See Requesting an Uplift for documentation on how to request an uplift.

For more information, please visit BugBot documentation.

Comment 12

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/63873 for changes under testing/web-platform/tests

Comment 13

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot