font-family: -apple-system; with weight bold not working

VERIFIED FIXED in Firefox 61

Status

()

defect
P1
blocker
VERIFIED FIXED
Last year
Last year

People

(Reporter: solidcolour, Assigned: jfkthame)

Tracking

({regression})

61 Branch
mozilla62
Points:
---
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox-esr60 unaffected, firefox60 unaffected, firefox61blocking verified, firefox62 verified)

Details

Attachments

(2 attachments)

Reporter

Description

Last year
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180524181234

Steps to reproduce:

Use system font CSS stack, e.g.:
font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, sans-serif;

And set some text bold:
font-weight: bold;

Live demo:
https://codepen.io/anon/pen/pKzxrQ

Platform:
Firefox 61.8b8; macOS 10.13.4

Side note:
Firefox 60 has no problem with it



Actual results:

No bold font weight for "-apple-system"


Expected results:

Render bold font weight for "-apple-system"
Status: UNCONFIRMED → NEW
Component: Untriaged → Graphics: Text
Ever confirmed: true
Product: Firefox → Core
I only see this in beta, not nightly. It affects many sites (ie facebook). Regression range on the beta channel for me is

https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=8284f435a1cb5681c3dd2d08591aa5df2d8d5846&tochange=f8c381b7d9a42ecbe4ed34792cd98430b32b6dd0

The only thing that looks relevant is unsetting the EARLY_BETA_OR_EARLIER flag. So maybe we have some font stuff that depends on that?
Flags: needinfo?(jfkthame)
Assignee

Comment 2

Last year
Oh dear.... that'll be related to disabling variable-font support for later beta. :(

Presumably if you manually reset layout.css.font-variations.enabled to true, the problem goes away? (That may require a browser restart, I think.)
Flags: needinfo?(jfkthame)
(In reply to Jonathan Kew (:jfkthame) from comment #2)
> Presumably if you manually reset layout.css.font-variations.enabled to true,
> the problem goes away? (That may require a browser restart, I think.)

Yes, that fixes the problem.
Reporter

Comment 4

Last year
(In reply to Jonathan Kew (:jfkthame) from comment #2)
> Oh dear.... that'll be related to disabling variable-font support for later
> beta. :(
> 
> Presumably if you manually reset layout.css.font-variations.enabled to true,
> the problem goes away? (That may require a browser restart, I think.)

Yes, that fixed it after a restart. Is that just a workaround or proper fix?
Assignee

Comment 5

Last year
That's a workaround; we need to fix this properly before Firefox 61 ships.

Confirmed that the same problem occurs in Nightly (Fx62) if the font-variations pref is explicitly set to false. (On Fx62 the plan is to ship with the feature enabled, so users won't generally see the issue. But for Fx61 it'll ship disabled, so it's critical we fix this now for Beta.)
Assignee: nobody → jfkthame
Component: Graphics: Text → Layout: Text
Priority: -- → P1
Assignee

Comment 7

Last year
[Tracking Requested - why for this release]:
This negatively affects rendering of major sites (e.g. Facebook) on macOS.
Severity: normal → blocker
Flags: qe-verify+
Flags: in-testsuite?
Keywords: regression
Assignee

Updated

Last year
Attachment #8981367 - Flags: review?(jwatt) → review?(lsalzman)
Attachment #8981367 - Flags: review?(lsalzman) → review+

Comment 8

Last year
Pushed by jkew@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/315a0483bab2
When font-variations support is preffed off, do not set up variation ranges in the gfxFontEntry for a system font, so that font selection will rely only on the static properties of the faces. r=lsalzman

Comment 9

Last year
bugherder
https://hg.mozilla.org/mozilla-central/rev/315a0483bab2
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → mozilla62
Assignee

Comment 10

Last year
Comment on attachment 8981367 [details] [diff] [review]
When font-variations support is preffed off, do not set up variation ranges in the gfxFontEntry for a system font, so that font selection will rely only on the static properties of the faces

Approval Request Comment
[Feature/Bug causing the regression]: Variable Fonts (primarily a result of the changes in bug 1454598)
[User impact if declined]: bold styling not working for macOS 10.13 users on pages that use the -apple-system font family (e.g. Facebook) when Variable Fonts is preffed off (which will be the default in Fx61)
[Is this code covered by automated tests?]: no, we don't have CI running macOS 10.13
[Has the fix been verified in Nightly?]: not yet, tested in local build
[Needs manual test from QE? If yes, steps to reproduce]: yes - on macOS 10.13, visit Facebook and check that bold works; visit about:config and check that non-default prefs are shown in bold
[List of other uplifts needed for the feature/fix]: none
[Is the change risky?]: no
[Why is the change risky/not risky?]: trivial patch to disable a block of variations-related code when the feature is preffed off
[String changes made/needed]: none
Attachment #8981367 - Flags: approval-mozilla-beta?
Comment on attachment 8981367 [details] [diff] [review]
When font-variations support is preffed off, do not set up variation ranges in the gfxFontEntry for a system font, so that font selection will rely only on the static properties of the faces

Fixes a critical font rendering regression for OSX systems when variation fonts are disabled. Approved for 61.0b10.
Attachment #8981367 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Fix confirmed on 61.0b10, and on 62.0a1.
Verified with MacOS 10.13.4.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.