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!

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.

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.

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?

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

Huh; I'm definitely seeing it on 20220613094641

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

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

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

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

It does!

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?)

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?

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.

(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?

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.

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

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.

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

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!

LGTM

(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.