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

Issue metadata

Status: Duplicate
Merged: issue 236298
Owner: ----
Closed: Mar 2014
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug

Sign in to add a comment

Issue 336879: Fonts appear to "unload" while page is not focused for some time

Reported by, Jan 22 2014

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.77 Safari/537.36

Example URL: mailboxes (logo),

Steps to reproduce the problem:
1. Navigate to a page that sends @font-face (for icons or text, have had it happen with both)
2. Leave page unfocused, go about browsing in other tabs (the longer the time before going back seems to have an effect)
3. Navigate back to the tab with @font-face, glyphs are unloaded until you an event fires on the DOM element.

What is the expected behavior?
Glyphs remain loaded instead of showing the "Unknown glyph" icon.

What went wrong?
The screenshot with the "unknown glyph" square was taken after ~30 minutes of not having the tab focused. Navigating back to the tab shows these, but after hovering over that top blue bar, they reload to their known glyph state.

In other cases (, where the selected font face uses standard characters (some sans-serif font), it will revert to browser-default font-family until elements have an event fired on them (hover, usually).

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? Yes 31 @ Stable

Does this work in other browsers? Yes 

Chrome version: 32.0.1700.77  Channel: stable
OS Version: OS X 10.8.5
Flash Version: Shockwave Flash 12.0 r0
Screen Shot 2014-01-21 at 2.41.40 AM.png
11.3 KB View Download
Screen Shot 2014-01-22 at 1.16.43 PM.png
15.3 KB View Download

Comment 1 by, Jan 24 2014

Seeing this problem on as well.

The "home" icon will be appear as a square block after a certain amount of time.

Comment 2 by Deleted ...@, Jan 25 2014

I'm seeing this as well. At first I thought there was something wrong with (adobe) typekit on a site I'm working on, but I started seeing it happen all over the web. 

Unsure as to how to replicate, but it seems that leaving a tab in the background for a while will cause it to happen. Usually, the fonts snap back when the page is scrolled, an element is viewed in the inspector, or if they have a :hover style that gets applied when I hover over them. 

I'll try and screenshot any occurrences of this that I spot in the future. Although it's pretty hard, because for most of the cases, once I switch back to the tab, it the fonts will correct themselves usually after a few seconds.

Comment 3 by Deleted ...@, Jan 25 2014

Probably worth adding, I am seeing this happen on fonts that have regular ascii characters as well. A place I've noticed this happen extensively is the text on a wikipedia article.

Comment 4 by, Jan 28 2014

Labels: -Cr-Content Cr-Blink-Fonts

Comment 5 by Deleted ...@, Jan 29 2014

Getting the same problem. At first I thought it was something with my codebase because I noticed happening locally, while in development. Since then however I've noticed it happening almost everywhere; it's not constant, but occurs fairly often when I leave a tab open/inactive for more than a few minutes.

As mentioned above, the font(s) seem to pop back in when an affected element is hovered over or interacted with somehow. Never notice a similar problem before a week ago or so.

Screenshots of it happening on a live site are attached:
Screenshot 2014-01-28 16.09.08.png
18.9 KB View Download
Screenshot 2014-01-28 16.09.47.png
19.8 KB View Download

Comment 6 by, Jan 30 2014

We're seeing this issue on

Comment 7 by Deleted ...@, Feb 4 2014

Also seeing it in the "wp-admin" section of WordPress sites from time to time.
Hovering elements seem to trigger the right font back into place.

Comment 8 by, Feb 4 2014

Will anybody on the Chromium team acknowledge this issue?

Example from
133 KB View Download

Comment 9 by, Feb 4 2014

I think this may be a duplicate of, which may be fixed in the next Chrome release.

Comment 10 by Deleted ...@, Feb 4 2014

I see the issue on a daily basis as of v32.  Before v32 I don't think I ever saw it.  So if it is a duplicate, the problem has gotten severely worse since v26 when that other bug was introduced.

Comment 11 by, Feb 5 2014

Is this issue the same as ?

I'm working on 336756.

I will land a fixing patch by the end of this week.

Comment 12 by, Feb 5 2014

I believe this is a duplicate of and should be closed as such.

Comment 13 by, Mar 4 2014

Mergedinto: 236298
Status: Duplicate

Sign in to add a comment