1478720 - Fonts not reacting to font-variation-settings values on OS X

Status: VERIFIED FIXED

(Core :: Layout: Text and Fonts, defect, P2)

Description

[Martin Balfanz [:mbalfanz]]

This bug was tested on the latest Nightly and latest OS X version.

STR:
1. Visit https://typetools.typenetwork.com/
2. Click on the element labeled with `H1`
3. Check "View all axis" in the left sidebar
4. Play around with the transparent / opaque axis (e.g. move first y transparent, then y opaque) for a little bit

ER: the fonts should adjust according to the settings

AR: the fonts adjust for the first slider, but stop working when moving the second slider

This behavior can also be tested with the devtools font editor or by setting the `font-variation-settings` manually.

Comment 1

[Jonathan Kew [:jfkthame]]

Martin, could you please try the build from https://treeherder.mozilla.org/#/jobs?repo=try&revision=0f8568c8bf06701a154ced1e8bf0809501321cab&selectedJob=190889590 and confirm whether the issue can still be reproduced? Thanks!

Comment 2

[Martin Balfanz [:mbalfanz]]

Looks good! I cannot reproduce the issue anymore :-)

Comment 3

[Jonathan Kew [:jfkthame]]

Attachment: Increase the fractional adjustment applied to 'opsz' on macOS to avoid using the font's default setting, which may be mishandled by Core Text

I don't entirely understand what's going wrong here, but it seems to be related to the 'opsz' axis and the tendency of Core Text to get confused when the page explicitly sets an 'opsz' value that matches the font's default. We worked around this in bug 1457417, but apparently with the Amstelvar font we're still dangerously close to it; increasing the fudge amount to 0.01, which is still way below what should be a perceptible optical-size difference with any reasonable font, seems to avoid the problem.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/9068ee10e910
Increase the fractional adjustment applied to 'opsz' on macOS to avoid using the font's default setting, which may be mishandled by Core Text. r=lsalzman

Comment 5

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/9068ee10e910

Comment 6

[Jonathan Kew [:jfkthame]]

Comment on attachment 8996002 [details] [diff] [review]
Increase the fractional adjustment applied to 'opsz' on macOS to avoid using the font's default setting, which may be mishandled by Core Text

Approval Request Comment
[Feature/Bug causing the regression]: variable fonts (not a regression)

[User impact if declined]: some variable fonts may render incorrectly

[Is this code covered by automated tests?]: no (version of macOS in CI infrastructure is too old)

[Has the fix been verified in Nightly?]: yes

[Needs manual test from QE? If yes, steps to reproduce]: yes; STR in comment 0

[List of other uplifts needed for the feature/fix]: none

[Is the change risky?]: no

[Why is the change risky/not risky?]: minor adjustment to the "fudge factor" we use to work around a Core Text quirk

[String changes made/needed]: none

Comment 7

[Jonathan Kew [:jfkthame]]

[Tracking Requested - why for this release]:
We're shipping Variable Fonts as one of the high-profile new features in Fx62; it would be unfortunate to ship with this as a visible bug on demo pages.

Comment 8

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 8996002 [details] [diff] [review]
Increase the fractional adjustment applied to 'opsz' on macOS to avoid using the font's default setting, which may be mishandled by Core Text

Fix for a bug in a new feature for 62. Let's uplift for beta 15.

Comment 9

[Dorel Luca [:dluca]]

https://hg.mozilla.org/releases/mozilla-beta/rev/07f7e41737eb

Comment 10

[Catalin Sasca, Desktop Test Engineering [:csasca]]

I successfully reproduced this issue on Firefox Beta 62.0b13 under macOS 10.13 using the STR from Comment 0.

The issue is no longer reproducible on Firefox Beta 62.0b15 and latest Nightly 63.0a1 (2018-08-06), under macOS 10.13.