New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 868795 link

Starred by 4 users
Status: Started
Owner:
drott@chromium.org
Cc:
mpear...@chromium.org
e...@chromium.org
█ rsheeter@google.com
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac
Pri: 2
Type: Bug



Sign in to add a comment

[Variations] Guard font src:local() matching with experiment configuration

Project Member Reported by drott@chromium.org, Jul 30 
Design Doc for @font-face { src: local() } matching:
https://docs.google.com/document/d/1yCZwVIF39S8WOgCUraT5OuUUaLSqWrxoG3mqdtnHnhs/edit#

Fixing font matching for src: local() references requires adding a larger set of new code on Android which persists a font table to cache directories. As this code is rolling out to large number of devices eventually, and reads and writes from disk, I'd like to be able to have a killswitch should there be stability issues with this code.

Also, rolling out the feature to stable needs to be synchronized with Google fonts, so we'd like to have more control over the rollout then just the Chromium waterfall process.

I will add UMA histograms to the font scanning and cache persistence code to measure whether reading back the stored font table succeeds, whether updating it succeeds, and whether writing the cached table back to the cache directory succeeds. Looking at those metrics, we will know whether we see the expected robustness and whether failures are close to 0.

Other than that, the improved src: local() matching feature should be default enable for dev and beta version.

The feature switch implementation is here, https://chromium-review.googlesource.com/c/chromium/src/+/1151203 - named "FontSrcLocalMatching".

Comment 1 by mpear...@chromium.org, Jul 30

Summary: [Variations] Guard font src:local() matching with experiment configuration (was: [Finch] Guard font src:local() matching with Finch configuration)
> rolling out the feature to stable needs to be synchronized with Google fonts
One big concern is that (stable) users take a long time to update, especially on Android.  Like, months later a lot are still on an old version.  If a Google fonts update isn't going to be tied to a particular Chrome version, then--flag controlled or not--you're always going to end up with a sizable fraction of users with Google fonts that don't have the code or its associated experiment config.

> the improved src: local() matching feature should be default enable for
> dev and beta version.
Please make sure to have dev and beta test the setting that stable will end up having.  Having, say, dev and beta 100% one thing and stable an entirely different thing is problematic.  If stable isn't going to be enabled when it rolls out, keep at least some percent of installs on dev and beta to be not enabled as well.

[other edits: removed codenames]

Comment 2 by drott@chromium.org, Jul 31

Cc: e...@chromium.org
mpearson@, thanks for the valuable feedback.

Re 1: (mixed fleet, slow updates on stable channel): I think there is a relatively straightforward transition period in which multiple src: local() values can be present, selecting fonts by still specifying an incorrect family name (the old way) and at the same time placing a local() value in the @font-face{src:...} line that selects the font by full font name or postscript name (the new and correct way). I outlined this transition strategy in a document guiding the discussion with Google fonts, compare https://docs.google.com/document/d/1xU-R_ar2iuiMZ246tI6fssNQCksO6FcrnIZEDgktYKA/edit?usp=sharing

> Please make sure to have dev and beta test the setting that stable will end up having.  Having, say, dev and beta 100% one thing and stable an entirely different thing is problematic.  If stable isn't going to be enabled when it rolls out, keep at least some percent of installs on dev and beta to be not enabled as well.

Okay, I will do that. For web pages using src: local(), they can target both the fixed an non-fixed versions of Chrome with the same transitioning strategy.

Comment 3 by drott@chromium.org, Jul 31

Cc: rsheeter@google.com

Comment 4 by mpear...@chromium.org, Jul 31 

Thanks for the explanations above.

I'm not sure how the web platform team does launches.  That said, this sounds like a non-trivial user facing change, which means per go/newChromeFeature it should go through launch review.  You may need a real launch bug.  Of course, I could be entirely wrong...

Comment 5 by e...@chromium.org, Aug 1 

This is not a new chrome feature but a fix to an existing web platform API and will go through the regular web platform launch process.
►

Sign in to add a comment