New issue
Advanced search Search tips

Issue 235303 link

Starred by 24 users

Issue metadata

Status: Fixed
Closed: Mar 2014
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug

Blocked on:
issue 237058

issue 245094

Sign in to add a comment

Text not visible while external font downloading

Project Member Reported by, Apr 25 2013

Issue description

Migrated from WebKit Bugzilla:
Originally reported 2009-04-15 06:24 PST by Henri Sivonen (

Steps to reproduce:
1) Load

Actual results:
When a given run of text is to be rendered with a external font, the run of text is not drawn until the font has been downloaded.

Expected result:
If the external font is not already in cache and layout starts, expected the next best available font to be used during font download and the page to be redrawn once the external font is available.

[] NEW - fillText() function on <canvas> doesn't work with @font-face remote fonts

The specification has a section on what to render while the web font is downloading.

Browsers are behaving as follows:

Firefox 4:
1. Text is rendered as blank for 3 seconds or so.
2. Text is rendered with fallback fonts until download completes.
3. Text is rendered with the web fonts.

Opera 11:
1. Nothing is rendered for 2 seconds or so.
2. Text is rendered with fallback fonts until download completes.
3. Text is rendered with the web fonts.

IE 9:
1. Text is rendered with fallback fonts until download completes.
2. Text is rendered with the web fonts.

Chrome, Safari:
1. Text is rendered as blank until download completes.
2. Text is rendered with the web fonts.

Yuzo(@google) had a WebKit patch waiting for review which followed's Firefox behavior.
Labels: Needs-Feedback
We need to discuss if we want to scientifically determine the right threshold or if we should just pick the value based on empirical evidence.
Blockedon: chromium:237058
Owner: ----
Status: Available
Science it is:  issue 237058 .
Project Member

Comment 4 by, May 20 2013

Labels: -WebKit-ID-25207 WebKit-ID-25207-NEW

Blocking: chromium:245094
Labels: -Needs-Feedback
Will discuss at the next F2F meeting to inform the final decision.
The site has a webfont behavior that may be worth considering, as an alternative to the Firefox behavior.

1. Text is immediately rendered with fallback fonts
2. Webfonts are downloaded lazily after first page load finishes
3. Webfonts are used for second page load
Paul: you can implement this behavior with a fontloader (additional JS), or via the upcoming Font Events API without any external JS (under "experimental features" flag atm). Are you suggesting that a strategy like this be the default? To me, that seems a bit too aggressive -- at the very least we'd then have to provide a way to provide current behavior.
Status: Assigned
While I was at AtypI, I talked to Jonathan Kew (Mozilla) to find out if this would be in scope of the CSS WG. It seemed unlikely, so I will move forward and eventually share back the data we used and our rationale to the CSS WG as an FYI. 

Let me come full circle on all the different approach and reach out for consensus.
Status: Started
We have reached consensus within the team. We are looking at the following behavior:
 - wait until 3 seconds then uses the author specified fallback font if any otherwise user/agent fallback font.
 - keep downloading the web font so that it's ready (in the cache) for the next time

However, early feedback from developers is mixed:

We are considering blocking this behavior change on the availability of Font Load Events which will let anyone control the user experience and realize any (even more) of the suggestions in Paul's g+ post.

Comment 12 by, Nov 19 2013

Labels: Hotlist-DevRel
Labels: M-35
 Issue 335701  has been merged into this issue. you please confirm,if  Issue 335701  is same or not?Shall we go ahead and Unmerge this.

Thanks for asking, this is most likely a different a issue (Paul already unmerged it).
Labels: -Pri-2 Pri-1
Status: Assigned
Our conclusion based on outreach to developers, Mozilla's John Daggett and another round of healthy debate:

We'll opt for the following change:
 - wait until 3 seconds then use the author specified fallback font if any otherwise user/agent fallback font.
 - keep downloading the web font
 - switch to the web font when the web font is ready

The upcoming Font Load Events will let developers customize this behavior to their own needs.

Note: we intend to revise the 3 seconds timeout as web font performance improves so that it keeps hitting a predetermined percentile.
Project Member

Comment 19 by, Mar 3 2014

The following revision refers to this bug:

r168258 | | 2014-03-03T03:15:14.931621Z

Changed paths:

Make text visible when font loading takes longer than 3 seconds

When a font resource takes a long time to download, currently Blink
keeps the text invisible until the font is ready. After this patch,
Blink behaves similar to FireFox; keeps the text invisible until 3
seconds, then fallback to the next available font in the fallback
list. When the webfont finally loads, change the text to use it.

- Add a Timer to FontResource that fires after 3 seconds since load start.
- fontLoadWaitLimitExceeded() callback invalidates the fallback font and
  triggers style recalc.
- Fallback fonts have m_skipDrawing boolean in CustomFontData, that is
  false if the font load exceeds the wait limit.
- FontFallbackList::shouldSkipDrawing() returns true if it contains at
  least one FontData with m_skipDrawing == true.

BUG= 235303 

Review URL:

Since this is what we used to decide on the 3 seconds timeout, I'm assuming that the existing UMAs (the time to download UMAs) are self-sufficient (to know how often we are under the 3 sec timeout and if not how long it took for reverting back from the fallback to the webfont). But let me know if this turned out to be a bit more subtle than that.
Status: Fixed
Yeah, we can assume that
The download time UMA indicates >3 seconds === 3 seconds timeout triggered.

Sign in to add a comment