New issue
Advanced search Search tips

Issue 762957 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac , Fuchsia
Pri: 3
Type: Bug



Sign in to add a comment

Changing FontFace attributes should affect font matching

Project Member Reported by malteubl@google.com, Sep 7 2017

Issue description

Chrome Version: Current Canary
OS: All

What steps will reproduce the problem?
(1) Run something like document.fonts.values().next().value.display = 'swap' on a web page while fonts are loading

What is the expected result?
The font should change its display behavior to swap

What happens instead?
Nothing

Please use labels and text to provide additional information.
Relevant FIXME is here https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/css/FontFace.h?sq=package:chromium&l=87

 
Components: -Blink>Fonts Blink>WebFonts
Labels: -OS-All OS-Android OS-Chrome OS-Fuchsia OS-Linux OS-Mac OS-Windows
Status: Started (was: Assigned)
Being able to change FontFace.display would be more important than other attributes, because that will allow developers to workaround issue 777846.

Created a patch for font-display: https://chromium-review.googlesource.com/c/chromium/src/+/828227
Resumed the spec discussion:
https://github.com/w3c/csswg-drafts/issues/1358#issuecomment-352989765

Malte, please confirm that this works for you.

Comment 4 by malteubl@google.com, Dec 20 2017

Thanks, this looks great. I wanted to confirm one edge case:

In this sequence:
- Text is styled with font-face that has default display
- Font is not yet available, so font is not rendered
- Browser paints with blank text
- JS runs and makes the font-face display-swap

Does this end in the browser immediately repainting the fallback font even if it had already decided to paint blank?

Let's see:
 - your scenario starts with the default so it means a block period of 3s.
 - the font isn't there so indeed we render blank text
 - JS runs to change font-display to swap while the block period is still going on.
 - swap has a zero second block period and an infinite swap period.
 - So, yes this means that we would immediately paint with the fallback font and swap to the web font when/if it arrives.

If the JS ran and changed font-display to fallback while the block period barely started (<=100ms), we would keep the blank text for up to that 100ms mark (on-going timer) and then show the fallback.
Project Member

Comment 6 by bugdroid1@chromium.org, Dec 22 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/234fc1b55d82694a89ca31cd4b36b5a47da2d0e5

commit 234fc1b55d82694a89ca31cd4b36b5a47da2d0e5
Author: Kunihiko Sakamoto <ksakamoto@chromium.org>
Date: Fri Dec 22 06:40:08 2017

Update fallback font visibility on FontFace.display change

This patch lets RemoteFontFaceSource recalculate font display period
when the FontFace's display attribute is changed. This gives a
workaround for crbug.com/777846, allowing developers to monkey patch
font faces from third party font services.

Bug: 682117, 762957, 777846
Change-Id: Ic25392b2d1bd240015e51cda52896415373afa97
Reviewed-on: https://chromium-review.googlesource.com/828227
Commit-Queue: Kunihiko Sakamoto <ksakamoto@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#525947}
[add] https://crrev.com/234fc1b55d82694a89ca31cd4b36b5a47da2d0e5/third_party/WebKit/LayoutTests/external/wpt/css/css-fonts/font-display/font-display-change-ref.html
[add] https://crrev.com/234fc1b55d82694a89ca31cd4b36b5a47da2d0e5/third_party/WebKit/LayoutTests/external/wpt/css/css-fonts/font-display/font-display-change.html
[modify] https://crrev.com/234fc1b55d82694a89ca31cd4b36b5a47da2d0e5/third_party/WebKit/LayoutTests/external/wpt/lint.whitelist
[modify] https://crrev.com/234fc1b55d82694a89ca31cd4b36b5a47da2d0e5/third_party/WebKit/Source/core/css/CSSFontFace.cpp
[modify] https://crrev.com/234fc1b55d82694a89ca31cd4b36b5a47da2d0e5/third_party/WebKit/Source/core/css/CSSFontFace.h
[modify] https://crrev.com/234fc1b55d82694a89ca31cd4b36b5a47da2d0e5/third_party/WebKit/Source/core/css/CSSFontFaceSource.h
[modify] https://crrev.com/234fc1b55d82694a89ca31cd4b36b5a47da2d0e5/third_party/WebKit/Source/core/css/FontFace.cpp
[modify] https://crrev.com/234fc1b55d82694a89ca31cd4b36b5a47da2d0e5/third_party/WebKit/Source/core/css/RemoteFontFaceSource.cpp
[modify] https://crrev.com/234fc1b55d82694a89ca31cd4b36b5a47da2d0e5/third_party/WebKit/Source/core/css/RemoteFontFaceSource.h

Sakamoto, thanks for the quick follow-up.
Is there anything else to do here?
Cc: ksakamoto@chromium.org
Owner: ----
Status: Available (was: Started)
The reported use case (changing display value for 3rd-party font faces) should work now.

Ideally, the other FontFace attributes (style, weight, etc.) should be update-able, but it requires some extra work.
Let's keep this bug open for that, unassigning myself for now as I'm not going to work on that anytime soon.
Project Member

Comment 9 by sheriffbot@chromium.org, Jan 17 (6 days ago)

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 10 by ksakamoto@chromium.org, Jan 18 (5 days ago)

Labels: -Pri-2 Pri-3
Status: Available (was: Untriaged)

Sign in to add a comment