1774037 - Google Docs font weight is wrong, but also changing while typing.

Status: VERIFIED FIXED

(Core :: Graphics: Canvas2D, defect)

Description

[Matthew Gaudet (he/him) [:mgaudet]]

Attachment: WeightProblems.mov

Updated Nightly over the weekend, and suddenly my Google Docs look wrong; the font weight appears to be too heavy.

Worse, as I type, the weight seems to change!

Comment 1

[Matthew Gaudet (he/him) [:mgaudet]]

Hmm. Tried mozregression.

Came up with https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a419f8030e7556aa789dc5dfaa43a2ff9f6ad883&tochange=c7720fa81b265fe17061fd4ff7a5af04b34be354, which points the finger at Bug 1773752

Having said that, I'm not 100% confident in the results. I had a number of failed builds that crashed for code-signing reasons during mozregression.

Comment 2

[Jonathan Kew [:jfkthame]]

Watching the above video, there's an odd thing: observe the line that begins "Fasdfasd...". At around the 2-second mark, it switches from a heavier to a lighter rendering. But watch it closely! It doesn't just flicker from heavy to light; it momentarily flickers back again, but not entirely: only the lower half of the glyphs switch back to the heavier rendering, but their upper halves are untouched.

Presumably there's a boundary between some kind of surfaces/tiles/clip-areas/??? that runs through the middle of that line of text, and it's possible that the two parts get painted in different modes of some sort.

Comment 3

[Jonathan Kew [:jfkthame]]

Interestingly, using mozregression to launch nightlies, I can reproduce this with 2022-06-12, but not (afaict) with 2022-06-13. Maybe something just got fixed?

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 5

[Matthew Gaudet (he/him) [:mgaudet]]

Huh; I'm definitely seeing it on 20220613094641

Comment 6

[Jonathan Kew [:jfkthame]]

Also reproduces on an Intel-based Mac using the 2022-06-12 build.

Comment 7

[Jonathan Kew [:jfkthame]]

I'm trying 2022-06-13-13-18-02 and can't seem to reproduce on either M1 or Intel machines.

Comment 8

[Stephen A Pohl [:spohl]]

There is currently some confusion about what SDK exactly is being used by our build system, so I'm putting together a patch to revert the changes to gfx/thebes/gfxPlatformMac.cpp made in bug 1773752. I kicked off a try build to confirm:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=f3ab25021a2ce2822cfe33f86776a21a5e40dace

Comment 9

[Stephen A Pohl [:spohl]]

Does this build fix the issue for you?

https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/BDXGSyZfRgKFT8Rtz0S5Xw/runs/0/artifacts/public/build/target.dmg

Comment 10

[Matthew Gaudet (he/him) [:mgaudet]]

It does!

Comment 11

[Stephen A Pohl [:spohl]]

Attachment: Bug 1774037: Partially revert bug 1773752 for causing font weight issues on macOS. r=mstange

Comment 12

[Jonathan Kew [:jfkthame]]

Matthew, I'm curious if the problem reproduces for you with 2022-06-13-13-18-02?

What I'm seeing is that with

./mach mozregression --launch 20220613094641

the problem DOES reproduce, whereas with

./mach mozregression --launch 20220613131802

it DOES NOT, although both these builds are post-bug-1773752 and neither of these builds have Stephen's patch. It's unclear to me why they behave differently. (Maybe we have a mix of build environments in CI, and it's random which gets used to build any given push?)

Comment 13

[Matthew Gaudet (he/him) [:mgaudet]]

Attachment: Screen Shot 2022-06-13 at 12.03.11 PM.png

Uuuuugh. Something weird is going on here. This might actually just be something at Google's end.

I can no longer reproduce with either of the builds you point out, or even my current profile. Yet, I took this screenshot this morning with 20220613094641 on the left, and Stephen's build from Comment #9 on the right.

So something broken in the Google Docs application that was being served only some of the time?

Comment 14

[Markus Stange [:mstange]]

I can reproduce the same issue in the Firefox Profiler, and I got the same regression range.

Steps to reproduce:

1. Go to https://share.firefox.dev/3xeatPa
2. Move your boxes over some of the boxes in the flame graph.

Expected results:
Thin text.

Actual results:
Thicker text, sometimes only in the hovered boxes.

Comment 15

[Stephen A Pohl [:spohl]]

(In reply to Markus Stange [:mstange] from comment #14)

I can reproduce the same issue in the Firefox Profiler, and I got the same regression range.

Steps to reproduce:

1. Go to https://share.firefox.dev/3xeatPa
2. Move your boxes over some of the boxes in the flame graph.

Expected results:
Thin text.

Actual results:
Thicker text, sometimes only in the hovered boxes.

I can't reproduce the issue, so I will have to rely on you and others to let me know if things do or don't work as expected. Does the try build from comment 9 fix the issue for you?

Comment 16

[Markus Stange [:mstange]]

I looked at my mozregression log again and I'm no longer sure that I agree with Matt's regression window. I also had trouble with mozregression trying to launch unsigned builds.

Here's a range that I trust:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=46d8ba6116321275d36167c7266eb62eda1b8fd0&tochange=effe6ef55974d3ea50aa6f2a7d83c394e9fb9b87

This range includes bug 1773712, i.e. the bug that flipped gfx.canvas.accelerated to true.

That bug has been backed out.

On today's Nightly, fonts look normal to me.

And flipping the pref to true makes the fonts look bad again.

So yeah, I think the evidence is pointing pretty strongly towards gfx.canvas.accelerated.

Comment 17

[Donal Meehan [:dmeehan]]

Setting 103 to disabled, Bug 1773712 was backed out of central

Comment 18

[Lee Salzman [:lsalzman]]

Attachment: Bug 1774037 - Detect whether to use light or dark text masks on macOS. r?aosmond

macOS may apply differing amounts of font dilation depending on whether or not it
determines the text color is light or dark. We may end up applying the wrong amount
of dilation to text if we use a single mask texture for all colors. To work around
this, as in Skia and WebRender, we have to determine whether the text is light or
dark and then allocate separate mask textures for each case.

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5097dc5f0e4e
Detect whether to use light or dark text masks on macOS. r=aosmond

Comment 20

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/5097dc5f0e4e

Comment 21

[Anca Soncutean, Desktop QA]

This issue is not reproducible on my side with Fx 103.0a1 (2022-06-12/2022-06-13) on macOS 12.1 (Intel based).
Matthew Gaudet, If your time permits, could you help us with a fix confirmation on the latest available 103 Beta? Thank you!

Comment 22

[Matthew Gaudet (he/him) [:mgaudet]]

LGTM

Comment 23

[Anca Soncutean, Desktop QA]

(In reply to Matthew Gaudet (he/him) [:mgaudet] from comment #22)

LGTM

Thank you for your confirmation! I will mark the issue as verified fixed based on the previous comment.