2056856 - The tab titles are cut off at the beginning, if System font is `MS UI Gothic`

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, defect)

Description

[Alice0775 White]

Attachment: screenshot

[Tracking Requested - why for this release]:

[Tracking Requested - why for this release]: Visual glitch, The tab titles are cut off at the beginning

Steps to reproduce:

1. Change Windows11 system font to MS UI Gothic using such as noMeiryoUI (https://github.com/Tatsu-syo/noMeiryoUI/releases),
   Winaero Tweaker (https://winaerotweaker.com/)
2. Start Firefox
3. Open https://www.wikipedia.org/ or https://www.pref.yamaguchi.lg.jp/

Actual Results:
The tab titles W, 山 are cut off at the beginning (The pixel on the leftmost edge is cut off).

Expected Results:
Should not cut off at the beginning.

Regression window:
https://hg-edge.mozilla.org/integration/autoland/pushloghtml?fromchange=5f8e2eb6e6261d66cd33bbfdf092a217e52bcc1e&tochange=5f76e5907b817bd91ccee7b916662b1616e9dca7

Comment 1

[Alice0775 White]

Attachment: about:support

Comment 2

[BugBot [:suhaib / :marco]]

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

For more information, please visit BugBot documentation.

Comment 3

[BugBot [:suhaib / :marco]]

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

Comment 4

[Glenn Watson [:gw]]

Attachment: Bug 2056856 - Round a text run's ancestor clips out on both axes

Text runs kept their clip exact on the sub-pixel axis (bug 2050692),
assuming glyphs are sub-pixel-positioned there. Embedded bitmap strikes
(e.g. MS UI Gothic) are grid-placed with no sub-pixel positioning, so a
zero-bearing first glyph at a fractional device origin gets its leftmost
column shaved by the exact clip edge. Round the clip out on both axes;
round-out never moves an edge inward, so bug 2050692 stays fixed. Removes
the now-unused SnapRounding::RoundOutNonSubpx.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/11ccd5737372
https://hg.mozilla.org/integration/autoland/rev/8dc63ac7d11c
Round a text run's ancestor clips out on both axes r=gfx-reviewers,lsalzman

Comment 6

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/8dc63ac7d11c

Comment 7

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/8dc63ac7d11c

Comment 8

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/8dc63ac7d11c

Comment 9

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/8dc63ac7d11c

Comment 10

[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-firefox154 and the ESR status flag(s) to wontfix.

For more information, please visit BugBot documentation.

Comment 11

[Glenn Watson [:gw]]

I believe this should only affect nightly, since layout.disable-pixel-alignment is only enabled there for now.

Comment 12

[Alice0775 White]

(In reply to Glenn Watson [:gw] from comment #11)

I believe this should only affect nightly, since layout.disable-pixel-alignment is only enabled there for now.

No, The issue is reproduced with regardless of setting of layout.disable-pixel-alignment.

And the issue is reproduced on Firefox153.0 and 154.0b1 as well.

Comment 13

[Glenn Watson [:gw]]

Added an uplift request for beta, esr140 is unaffected.

Comment 14

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined/Reason for urgency: Visual artifacts for some fonts in URL bar.
• 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: In nightly for a while now, small patch
• String changes made/needed?: No
• Is Android affected?: yes

Comment 15

[Glenn Watson [:gw]]

Attachment: Bug 2056856 - Round a text run's ancestor clips out on both axes

Device-space text runs keep their clips exact on the sub-pixel axis
(bug 2050692), assuming glyphs are sub-pixel-positioned there. That is
correct for a run's OWN clip (the leaf clip_rect - e.g. a partial-ligature
or selection clip): rounding it out would over-reveal a sub-pixel column of
an adjacent run at an inline boundary. But it is wrong for the run's
ANCESTOR clips (an overflow:hidden container, table-cell edge, scroll
frame): an embedded bitmap strike (e.g. MS UI Gothic) is grid-placed with
no sub-pixel positioning, so a zero-bearing first glyph at a fractional
device origin gets its leftmost column shaved by the exact container edge.

Round only the ancestor (clip-chain) clips of a text run out on both axes;
keep the run's own leaf clip exact on the sub-pixel axis as before. Round-out
never moves an edge inward, so bug 2050692 stays fixed, and keeping the leaf
exact avoids over-revealing adjacent runs (no regression to shaping/boundary
text).

The wrench reftest uses Proggy's ppem-11 bitmap strike clipped by a
clip-chain node (mirroring overflow:hidden); it can't be a Gecko reftest
since drawSnapshot bypasses WebRender.

Drop now-passing WPT expectations that the ancestor-clip round-out fixes:
text-overflow-028 and text-wrap-balance-line-clamp-005 (Mac). Both target
tests byte-identical to the ones on central, so the improvements carry over.

Beta uplift of 11ccd5737372; the code change is byte-identical. Two of
central's WPT metadata edits are deliberately not taken, because both files
diverged through wpt metadata syncs rather than any behaviour difference:
text-overflow-with-selection.html.ini has no counterpart on beta (the test
itself does not exist here), and text-overflow-string-005.html.ini is left
untouched because beta still runs an older revision of that test, for which
its current bare-FAIL expectation is self-consistent. If the fix flips that
test on beta the way it did on central, the annotation can be narrowed once
a beta try run shows it.

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

Comment 16

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/3ca0bfa2c168
https://hg.mozilla.org/releases/mozilla-beta/rev/e3bc6be5a323

Comment 17

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

Attachment: image.png

Hello! I have reproduced the issue on Windows 11 with Firefox 153.0.1 by using Winaero Tweaker to change the font to MS UI Gothic and setting toolkit.legacyUserProfileCustomizations.stylesheets:true and adding a chrome folder inside the profile with userChrome.css containing .tab-text { font-family: "MS UI Gothic" !important; }. The Wikipedia tab title is a little cut off on the left side of the W letter if the tab is placed on the second place.

However, I can still see the issue with 154.0b5 and 155.0a1 (2026-07-30) if I open a page that contains the letter 'C', for example https://en.wikipedia.org/wiki/Colorado's_congressional_delegations. I can also see it in the Wikipedia tab when there are 5 tabs open in total, and Wikipedia is in 4th place (see screenshot). Should we open a new issue for this or reopen this one? The issue depends on how many tabs are open, I think, or I am doing something wrong. Thank you!

Comment 18

[Glenn Watson [:gw]]

Attachment: Bug 2056856 - Round a bitmap-strike glyph's pen to nearest

A glyph that rasterizes from an embedded bitmap strike ignores the sub-pixel
offset its key asks for and lands on the device grid, so flooring its pen with
the sub-pixel bias put it up to 0.875px left of where layout placed it, outside
its own element. A snapped clip or mask edge then shaved its leading column,
which is what cut the first letter off MS UI Gothic tab titles. Rounding to
nearest keeps the pen within 0.5px and on the same grid line as a nearest-snapped
mask edge, so nothing downstream has to compensate.

GlyphFormat::Bitmap and ColorBitmap identify these glyphs exactly: on every
backend, the branch that produces them is the branch that discards the sub-pixel
offset. That is only known after rasterization, so the pen is stored unsnapped
and snapped in the shader, with the bias chosen by a flag packed into the
instance flags at batch time. Snapping a value the shader receives verbatim
keeps it bit-exact; re-deriving the pen GPU-side would risk crossing a floor
boundary at the fractions layout produces.

The reftest draws Proggy's ppem-11 strike at a range of fractional x positions
and references each at round(x), with rows either side of the interesting range
guarding against the pen moving when it should not. Pinned to scale(1.0) because
the pen rounds in device space, so the reference position only holds at one
scale.

Comment 19

[Glenn Watson [:gw]]

(In reply to Alexandru Trif, Desktop Test Engineering [:atrif] from comment #17)

Created attachment 9620424 [details]
image.png

Hello! I have reproduced the issue on Windows 11 with Firefox 153.0.1 by using Winaero Tweaker to change the font to MS UI Gothic and setting toolkit.legacyUserProfileCustomizations.stylesheets:true and adding a chrome folder inside the profile with userChrome.css containing .tab-text { font-family: "MS UI Gothic" !important; }. The Wikipedia tab title is a little cut off on the left side of the W letter if the tab is placed on the second place.

However, I can still see the issue with 154.0b5 and 155.0a1 (2026-07-30) if I open a page that contains the letter 'C', for example https://en.wikipedia.org/wiki/Colorado's_congressional_delegations. I can also see it in the Wikipedia tab when there are 5 tabs open in total, and Wikipedia is in 4th place (see screenshot). Should we open a new issue for this or reopen this one? The issue depends on how many tabs are open, I think, or I am doing something wrong. Thank you!

Thanks for the detailed bug report - attached a new patch which handles that case (similar symptom, different cause).

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/e665c1a3c748
https://hg.mozilla.org/integration/autoland/rev/62f45fdc2f79
Round a bitmap-strike glyph's pen to nearest r=gfx-reviewers,lsalzman

Comment 21

[Silaghi Andreea]

https://hg.mozilla.org/mozilla-central/rev/62f45fdc2f79

Comment 22

[BugBot [:suhaib / :marco]]

A patch has been attached on this bug, which was already closed. Filing a separate bug will ensure better tracking. If this was not by mistake and further action is needed, please alert the appropriate party. (Or: if the patch doesn't change behavior -- e.g. landing a test case, or fixing a typo -- then feel free to disregard this message)

Comment 23

[Dianna Smith [:diannaS]]

Probably should have landed the last patch in a new bug. Since it is already there please request uplift requests:

• Beta & ESR 153 uplift for the new patch (D315917)
• ESR 153 uplift for the old patch(D313624), release uplift if wanted in 153 as well

Comment 24

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

Confirming I can no longer reproduce the issue from comment 17 on Windows 11 with 155.0a1 (2026-08-06).

Comment 25

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined/Reason for urgency: Some visual artifacts per bug report.
• 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 26

[Glenn Watson [:gw]]

Attachment: Bug 2056856 - Round a bitmap-strike glyph's pen to nearest

A glyph that rasterizes from an embedded bitmap strike ignores the sub-pixel
offset its key asks for and lands on the device grid, so flooring its pen with
the sub-pixel bias put it up to 0.875px left of where layout placed it, outside
its own element. A snapped clip or mask edge then shaved its leading column,
which is what cut the first letter off MS UI Gothic tab titles. Rounding to
nearest keeps the pen within 0.5px and on the same grid line as a nearest-snapped
mask edge, so nothing downstream has to compensate.

GlyphFormat::Bitmap and ColorBitmap identify these glyphs exactly: on every
backend, the branch that produces them is the branch that discards the sub-pixel
offset. That is only known after rasterization, so the pen is stored unsnapped
and snapped in the shader, with the bias chosen by a flag packed into the
instance flags at batch time. Snapping a value the shader receives verbatim
keeps it bit-exact; re-deriving the pen GPU-side would risk crossing a floor
boundary at the fractions layout produces.

The reftest draws Proggy's ppem-11 strike at a range of fractional x positions
and references each at round(x), with rows either side of the interesting range
guarding against the pen moving when it should not. Pinned to scale(1.0) because
the pen rounds in device space, so the reference position only holds at one
scale.

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

Comment 27

[Dianna Smith [:diannaS]]

Comment on attachment 9625892 [details]
Bug 2056856 - Round a bitmap-strike glyph's pen to nearest

There are no more betas in the 154 cycle. Moving request to firefox-release for dot release consideration.

Comment 28

[Ryan VanderMeulen [:RyanVM]]

Please request ESR153 uplift for this.

Comment 29

[Glenn Watson [:gw]]

We will revert the 153 patches that caused this instead - https://bugzilla.mozilla.org/show_bug.cgi?id=2063932

Comment 30

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/c3621d74e872
https://hg.mozilla.org/releases/mozilla-release/rev/93b5365f4c19

Comment 31

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

Verified fixed with Firefox 154.0.1 (64-bit) by following the steps from comment 17.