After updating from macOS 10.13 (High Sierra) to 10.14 (Mojave), some fonts are lighter weight in Firefox and Chrome than in Safari.
Examples:
* Bugzilla's text
* The body text on https://searchfox.org/
* The blame tool tip text and monospace code text on https://searchfox.org/mozilla-central/source/README.txt
See the attached screenshot show Firefox, Safari, and Chrome side-by-side.

Thanks. Your screenshots clearly show the differences. However, I just tested on my MacBook Pro Retina running Mojave and see different results. I see the same lightweight fonts in Firefox 64, 65 Beta, and 66 Nightly. (If I enable WebRender in Nightly using gfx.webrender.all, I see heavier weight fonts, but not has heavy as Safari's.)

If you can reproduce the 64/65 font differences when using a new Firefox user profile, can you try using the mozregression script to bisect the Firefox builds between 64 and 65 until you've found the build that caused the regression in 65? Then we can try to undo that font change.

Minkul, thanks again for using mozregression to pinpoint the exact cause of the regression in Firefox 65.

65=wontfix because, without less than two weeks left in the 65 beta cycle, I think it's too late to uplift a fix for a cosmetic issue.

Even given that, I think the fix is trivial enough, and I am fairly sure how it regressed given the nature of it. It was predictable enough upon inspection that I independently found the fix myself before checking to see if upstream did the same.

I think so long as we just have a couple people verify the fix in nightly it should be safe to uplift to beta, even on short notice. The alternative is to let a known avoidable regression in appearance slip into release.

Relman, this bug is a font regression in 65. You know how sensitive macOS users (like me) can be about their fonts. :)

This bug's history has morphed: I originally filed it for a font problem on Retina displays caused by upgrading to macOS 10.14 Mojave. The Retina problem was fixed by Skia bug 1502152, but the fix caused a similar font regression on non-Retina displays. Lee's patch in this bug fixes that non-Retina regression by cherry-picking a one line fix from upstream Skia.

I think so long as we just have a couple people verify the fix in nightly it should be safe to uplift to beta, even on short notice. The alternative is to let a known avoidable regression in appearance slip into release.

As a Mac user and the person originally who filed this bug, that sounds good to me. :)

So this is kind of a mess now :. Do we need a follow-up bug for fixing ESR60 for the originally-reported problem? Also, please request Beta approval on this patch if you feel it needs uplift - tracking+ doesn't guarantee that.

So this is kind of a mess now :. Do we need a follow-up bug for fixing ESR60 for the originally-reported problem?

I just confirmed that ESR 60 is affected, but I don't think this issue is serious enough to warrant an ESR uplift. IIUC, we would need to uplift all of Skia m71 (bug 1502152) plus this bug's patch to ESR 60.

I confirmed on my Retina MacBook Pro that fonts (on Wikipedia) now look heavier in 66 Nightly than 65 Beta (which look a little heavier than 64 Release and ESR 60). For comparison, Safari's font weight looks like it is half-way between Firefox 65's and 66's weights. I actually prefer 65's lighter weight on my Retina display, but the differences are small and subjective. :)

Comment on attachment 9037387[details][diff][review]
cherry-pick Skia fix for Mac font gamma
[Beta/Release Uplift Approval Request]
Feature/Bug causing the regression: Bug 1502152
User impact if declined: Font weights will be too light on macOS non-Retina displays.
I originally filed this bug for a font weights being too light on macOS *Retina* displays caused by upgrading to macOS 10.14 Mojave. The Retina problem was fixed in Firefox 65 by Skia bug 1502152, but that fix caused a font weight regression on *non-Retina* displays. Lee's patch in this bug fixes the non-Retina regression by cherry-picking a one line fix from upstream Skia.
In comment 14, Lee says: "I think the fix is trivial enough, and I am fairly sure how it regressed given the nature of it. It was predictable enough upon inspection that I independently found the fix myself before checking to see if upstream did the same. I think so long as we just have a couple people verify the fix in nightly it should be safe to uplift to beta, even on short notice. The alternative is to let a known avoidable regression in appearance slip into release.""
Is this code covered by automated tests?: No
Has the fix been verified in Nightly?: Yes
Needs manual test from QE?: No
If yes, steps to reproduce:
List of other uplifts needed: None
Risk to taking this patch: Low
Why is the change risky/not risky? (and alternatives if risky): This fix cherry picks a one-line, macOS-specific fix from upstream Skia.
String changes made/needed: None

In my opinion this fix makes reading webpages worse on Retina Displays than it was (I'd say you fixed something that wasn't broken). I tested it with the default Display on a Retina MacBook & iMac and the latest Version of macOS Mojave. The fonts after the Fix in Firefox look a bit blurry and too bold now in my opinion and especially smaller texts are harder to read for me now than before.

I also tried to compare it to Safari and even though the fonts in Safari are a little bit bolder than Firefox did it before (in the current stable), I still feel that Firefox with this new fix makes them even bolder than Safari (blurry?). The rendering in the current stable version is in my opinion much better (on Retina Display at last, don't know if this is also the case on external Monitors or non-Retina Devices, I have no possibility to test that).

I also tried to compare it to Chrome: This one shows the fonts like Firefox does it in the current stable and in my opinion it seems this has a much better readability on Retina Displays.

I hope you test this again, especially with Retina Displays, because I think this change reduces readability instead of improving it and I have the feeling the font-weight definition drifts too far apart (even from Safari).

Lee, what do you think about Christian's point? Should we get feedback from the Firefox UX team?

As I noted in comment 18, like Christian, on my Retina display, I personally preferred 65's font weight with Skia m71 before the SmoothBehavior patch, but these differences are subjective. :)

The patch here is what is used by upstream, and it fixed a legitimate bug in the code, so what you see now is actually how it is supposed to look, and what is being used by Skia upstream/Google/Chrome going forward. The appearance that you saw prior while the bug was in effect was from flat-out wrong gamma-space conversions, so it is behavior that can't be reinstated for that reason.

Subpixel anti-aliasing on macOS, as part of its explicit strategy, includes dilation (i.e. "bolding") to offset some of the perception of thinness caused by subpixel anti-aliasing.

macOS 10.14 decided to remove the subpixel anti-aliasing itself, but keep the dilation. So if you enable font-smoothing in macOS, you will see this bolding. The current recommended way to get rid of this legacy bolding is to disable the OS font-smoothing. The alternative that gives you is the normal grayscale anti-aliasing which never included the dilation.

So if there was a discussion to be had, it should be on the grounds of which of those two - macOS 10.14's legacy font smoothing that produces dilation vs the pre-existing grayscale AA that never dilated - was to be used. Even then, the first concern is which more closely matches Safari.

On my Retina MacBook Pro, I had to restart my browser (be it Firefox, Safari, or Chrome) to see the "Use font smoothing" change.

Christian told me that he was able to fix the fonts on his non-Retina display by toggling "Use font smoothing" off and on and then rebooting his Mac. Perhaps there is some GPU state on some machines that "Use font smoothing" can't completely reset until macOS reboots? Or maybe Firefox didn't pick up the font changes because it hadn't fully quit first? Either way, we have a workable solution

Paraphrasing Christian's email, the fonts in 66 Nightly still look a bit "bolder" compared to the current Firefox 64 release (which, as mentioned above, is the expected behavior), but it doesn't look wrong anymore (because the blur around the text is gone). 66 now really matches the font rendering of Safari completely and feels correct.

FWIW, I've decided to disable "Use font smoothing" on my MacBook Pro so I can keep using the lighter fonts. :)