New issue
Advanced search Search tips
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

Issue 235303: Text not visible while external font downloading

Reported by, Apr 25 2013 Project Member

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.

Comment 1 by, Apr 25 2013

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.

Comment 2 by, May 1 2013

Blockedon: chromium:237058
Owner: ----
Status: Available

Comment 3 by, May 1 2013

Science it is:  issue 237058 .

Comment 4 by, May 20 2013

Project Member
Labels: -WebKit-ID-25207 WebKit-ID-25207-NEW

Comment 5 by, Jul 3 2013

Blocking: chromium:245094

Comment 6 by, Oct 3 2013

Labels: -Needs-Feedback

Comment 7 by, Oct 3 2013

Will discuss at the next F2F meeting to inform the final decision.

Comment 8 by, Oct 16 2013

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

Comment 9 by, Oct 16 2013

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.

Comment 10 by, Oct 17 2013

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.

Comment 11 by, Nov 13 2013

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

Comment 13 by, Jan 8 2014

Labels: M-35

Comment 14 by, Jan 21 2014

 Issue 335701  has been merged into this issue.

Comment 15 by, Jan 21 2014 you please confirm,if  Issue 335701  is same or not?Shall we go ahead and Unmerge this.


Comment 16 by, Jan 22 2014

Thanks for asking, this is most likely a different a issue (Paul already unmerged it).

Comment 17 by, Jan 30 2014

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.

Comment 19 by, Mar 3 2014

Project Member
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:

Comment 20 by, Mar 3 2014


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.

Comment 21 by, Mar 3 2014

Status: Fixed
Yeah, we can assume that
The download time UMA indicates >3 seconds === 3 seconds timeout triggered.

Sign in to add a comment