2061411 - CSS transform sometimes doesn't affect emoji size

Status: RESOLVED FIXED

(Core :: Graphics: Text, defect, P3)

Description

[Jason Orendorff]

Attachment: tmp.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:153.0) Gecko/20100101 Firefox/153.0

Steps to reproduce:

1. Open the attached HTML file
2. Zoom in/out using trackpad gestures and/or resize the window horizontally

Actual results:

The emoji in the page are sometimes rendered in the wrong size. They're rendered at the correct location, but too small.

The page changes between rendering correctly and incorrectly as I zoom or resize.

Regular letters and digits in the same document render correctly.

This happens in Firefox 153.0.3 (aarch64) on Mac, Firefox 151 on Linux, and Firefox 153.0.3 (Build #2016176519) on Android 16.

Expected results:

The CSS contains transform: scale(1.6) and this should be consistently applied to all the emoji in the HTML.

Comment 1

[Jason Orendorff]

If I add rotate(30deg) to the transform it's clear the transform isn't being applied to the emoji; when they are rendered small they are also unrotated.

Comment 2

[Jason Orendorff]

Attachment: Screen recording of zooming in and out to trigger the bug

Comment 3

[Jonathan Kew [:jfkthame]]

Also, when they're rendered correctly (i.e. at the enlarged size) after pinch-zooming, if I then start to select some of the text (which causes a repaint), they'll snap back to their untransformed size.

Seems like they "prefer" to render without the transform applied, but in some cases, particularly as a result of pinch-zoom, they do apply it correctly. Weird. I suspect this might have something to do with the emoji font involved using bitmap (rather than scalable outline) glyphs. If I force the use of a scalable-outline emoji font such as (modern COLRv1) Noto Color Emoji[1], I can't reproduce the issue.

[1] Note that many Linux distros appear to still have the older bitmap-format Noto Color Emoji, which is probably why comment 0 mentions reproducing this on Linux.

Comment 4

[Jonathan Kew [:jfkthame]]

I think this is likely to be more on the Gfx/rendering side of things than Layout, given that they're in the right place and being measured correctly, afaict. Might be a webrender issue, or somewhere else up the painting stack.

Comment 5

[Jason Orendorff]

Attachment: Different minimization

This different test case seems to trigger the bug 100% for me, on Mac, without user interaction.

The emoji should be the same size (3x) in both rows; instead the emoji in the second row are rendered small (1x).

Comment 7

[Jonathan Kew [:jfkthame]]

mozregression indicates this is a result of bug 2044211.

Comment 8

[BugBot [:suhaib / :marco]]

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

Comment 9

[Glenn Watson [:gw]]

Attachment: Bug 2061411 - Apply a scale transform to embedded-bitmap glyphs

Bitmap fonts rasterize with an identity glyph shape, so a transform's scale
survives only as the scalar RasterizedGlyph::scale. The device glyph path from
bug 2044211 multiplies that into the atlas footprint, so a scaled emoji paints
at its untransformed size: too small scaling up, too big and clipped scaling
down (bug 2062234).

Widen the bug 2055177 bitmap-strike gate from "not an axis-aligned scale" to
"not a pure translation", so a scale joins rotation and skew on the local-raster
path.

2056856-bitmap-clip becomes scale(1.0)-only: wrench fakes a device pixel scale
with a root scale transform, so at other scales its glyphs are no longer
device-grid-placed and it asserts nothing.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/4e48f9ab6f40
https://hg.mozilla.org/integration/autoland/rev/a3bde9d0055b
Apply a scale transform to embedded-bitmap glyphs r=gfx-reviewers,lsalzman

Comment 11

[agoloman]

https://hg.mozilla.org/mozilla-central/rev/a3bde9d0055b

Comment 12

[BugBot [:suhaib / :marco]]

The patch landed in nightly and beta is affected, along with ESR.
:gw, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta and ESR approvals.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox155 and the ESR status flag(s) to wontfix.

For more information, please visit BugBot documentation.

Comment 13

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined/Reason for urgency: Visual artifacts
• Code covered by automated testing?: yes
• Fix verified in Nightly?: yes
• Needs manual QE testing?: yes
• Steps to reproduce for manual QE testing: Per bug report
• Risk associated with taking this patch: low
• Explanation of risk level: Small patch
• String changes made/needed?: No
• Is Android affected?: yes

Comment 14

[Glenn Watson [:gw]]

Attachment: Bug 2061411 - Apply a scale transform to embedded-bitmap glyphs

Bitmap fonts rasterize with an identity glyph shape, so a transform's scale
survives only as the scalar RasterizedGlyph::scale. The device glyph path from
bug 2044211 multiplies that into the atlas footprint, so a scaled emoji paints
at its untransformed size: too small scaling up, too big and clipped scaling
down (bug 2062234).

Widen the bug 2055177 bitmap-strike gate from "not an axis-aligned scale" to
"not a pure translation", so a scale joins rotation and skew on the local-raster
path.

2056856-bitmap-clip becomes scale(1.0)-only: wrench fakes a device pixel scale
with a root scale transform, so at other scales its glyphs are no longer
device-grid-placed and it asserts nothing.

Original Revision: https://phabricator.services.mozilla.com/D318258

Comment 15

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/6c91453dec09
https://hg.mozilla.org/releases/mozilla-beta/rev/0422b97095f9

Comment 16

[Glenn Watson [:gw]]

Attachment: Bug 2061411 - Apply a scale transform to embedded-bitmap glyphs

Bitmap fonts rasterize with an identity glyph shape, so a transform's scale
survives only as the scalar RasterizedGlyph::scale. The device glyph path from
bug 2044211 multiplies that into the atlas footprint, so a scaled emoji paints
at its untransformed size: too small scaling up, too big and clipped scaling
down (bug 2062234).

Widen the bug 2055177 bitmap-strike gate from "not an axis-aligned scale" to
"not a pure translation", so a scale joins rotation and skew on the local-raster
path.

2056856-bitmap-clip becomes scale(1.0)-only: wrench fakes a device pixel scale
with a root scale transform, so at other scales its glyphs are no longer
device-grid-placed and it asserts nothing.

Original Revision: https://phabricator.services.mozilla.com/D318258

(cherry picked from commit 4e48f9ab6f40f42de1ad3d9b5dd3179b93f03c1b)

Comment 17

[Phabricator Automation]

firefox-esr153 Uplift Approval Request

• User impact if declined/Reason for urgency: Both patches are needed to land cleanly on esr.

Bitmap glyphs under rotation or skew paint axis-aligned at their transformed pen, looking unrotated and displaced

Scaled emoji too small when scaling up, too large and hard-clipped when scaling down.

• Code covered by automated testing?: yes
• Fix verified in Nightly?: yes
• Needs manual QE testing?: yes
• Steps to reproduce for manual QE testing: Per bug reports.
• Risk associated with taking this patch: low
• Explanation of risk level: Small patches
• String changes made/needed?: None
• Is Android affected?: yes

Comment 18

[Glenn Watson [:gw]]

Uplift requests added.

Comment 19

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Reproduced the issue with Firefox 154 on macOS 14 aarch using the test case from comment 1 and comment 5. The emojis on the page are rendered in the wrong size.
I can confirm that with Firefox 156.0a1 (2026-08-17) and 155.0b1 from comment 15, the issue is no longer reproducible on macOS 14 and 27 aarch, Windows 11, and Ubuntu 24.

However, I can see that on Firefox with this test case, the second row of emojis is more blurred screenshot - Firefox is on the left side. Should I file a new issue for this? Thank you!

Comment 20

[Glenn Watson [:gw]]

Yes, new issue for that please, thanks!

Comment 21

[Ryan VanderMeulen [:RyanVM]]

Regressing bug was reverted from ESR153.