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 298 users

Comments by non-members will not trigger notification emails to users who starred this issue.

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Dec 2013
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment
link

Issue 236298: Occasionally, "serif" font shows up where "sans-serif" is supposed to be

Reported by asmus...@gmail.com, Apr 29 2013

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31

Example URL:
http://www.theverge.com

Steps to reproduce the problem:
1. Load http://www.theverge.com
2. Scroll down to "You need to read this now" section
3. Sometimes the dates above each article are set in serif, rather than sans-serif — you can reload the page until this happens.

What is the expected behavior?
"sans-serif" is supposed to be showing, as that's what's defined in the CSS.

What went wrong?
"serif" shows up instead of "sans-serif".

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? Yes It worked in Chrome 25.x

Does this work in other browsers? Yes Safari 6.0.4

Chrome version: 26.0.1410.65  Channel: stable
OS Version: OS X 10.8.3

The issue appears at random, but seems to happen more often on complex CSS websites. 

When it happens, inspecting the sans-serif element, and disabling and re-enabling *any* CSS property seems to cause a page redraw which fixes the font.

Screenshot showing the bug:
http://cl.ly/image/1a173g0M122S

Screenshot showing how it's supposed to look:
http://cl.ly/image/1V1A0n3x3v3I

This video shows the serif font problem, including how the web-inspector shows the font should be sans-serif:
http://cl.ly/0r3t193t3p3x
 
Showing comments 60 - 159 of 159 Older

Comment 60 by mark@chromium.org, Nov 27 2013

I’d be interested to see what happens if, we replaced the NSFontManager and NSFont implementations with versions that assert that they’re on the right thread.

Comment 61 by esprehn@chromium.org, Nov 28 2013

What does forker do? You can't use Cocoa or CoreFoundation after forking until you exec, it should give you some nasty warnings about that and will crash.

Comment 62 by mark@chromium.org, Nov 28 2013

Well, the source is right there for the scrutinizin’…

It doesn’t do anything it’s not allowed to do.

Comment 63 by dglazkov@chromium.org, Nov 28 2013

I made some more progress today. I am not so sure that borked NSFontManager is the culprit anymore. Still looking, will post more later. Maybe after turkey.

Comment 64 by ashej...@chromium.org, Nov 28 2013

 Issue 282716  has been merged into this issue.

Comment 65 by dglazkov@chromium.org, Nov 28 2013

 Issue 323876  has been merged into this issue.

Comment 66 by goo...@mspacek.mm.st, Nov 28 2013

There seems to be a perception here that this is only a Mac OSX problem. It is not. I've been seeing this irregularly on my Xubuntu 12.10 installation (3.7 kernel from xorg-edgers PPA, and Chrome 31.0.1650.57 from the google-chrome-stable PPA) for the last couple of weeks or so:

https://code.google.com/p/chromium/issues/detail?id=323876#c2

Comment 67 by msrchandra@chromium.org, Nov 29 2013

Cc: msrchandra@chromium.org
 Issue 322125  has been merged into this issue.

Comment 68 by scart.ri...@gmail.com, Nov 29 2013

I get this bug often on my Mac, but also occasionally on my Nexus 7, so it's definitely not just a Mac OS X issue. Will provide screenshot next time I see it.

Comment 70 by dglazkov@chromium.org, Nov 30 2013

Labels: -OS-Mac OS-All
Aw snap! I fingered the wrong guy. NSFontManager is not to blame. I was reading the traces wrong -- it was simply (correctly) failing to find "-webkit-monospace" (which is part of the font fallback).

The problem is definitely not platform-specific, since it has nothing to do with fonts per se.

Here's the rundown:

1) All FontFallbackList instances hold a RefPtr to a CSSFontSelector instance. Among other things, this CSSFontSelector is used to query Settings to determine names of generic fonts.

2) When StyleEngine::resolverThrowawayTimerFired is invoked, the CSSFontSelector::clearDocument is called, which sets CSSFontSelector::m_document to 0. The CSSFontSelector instance on StyleEngine is then replaced with a new CSSFontSelector instance.

3) At this point, there is a discrepancy in the render tree: all Fonts (via their FontFallbackList instances) are now holding on to the old CSSFontSelector that has a zeroed-out document.

4) Since we don't mark the tree as needing a style recalc after throwing away a StyleResolver, we can totally still paint this tree in its existing state.

5) Unfortunately, this means that when we ask Font for the right FontData, it will turn to the old CSSFontSelector, and, since that old CSSFontSelector has no document to grab the Settings from, it will follow the font fallback trail and end up with Times.

So, the fix is fairly simple: just add m_document.setNeedsStyleRecalc() in clearStyleResolver. I need to ponder how to test this, but is the right solution.

Thanks for your help, everyone. I apologize for taking so long to hunt this down.

Comment 71 by dglazkov@chromium.org, Nov 30 2013

Just realized that calling setNeedsStyleRecalc will render the whole throwing-away-style-resolver logic moot :) Need something more gentle.

Comment 72 by dglazkov@chromium.org, Nov 30 2013

Another possible (nasty) solution would be to beef CSSFontSelector up with knowledge just enough to survive until the next style recalc. If it was asked for a generic font once, it could cache and not ask for it again.

Comment 73 by thakis@google.com, Nov 30 2013

Now that you understand this better, is it possible to bisect this?

Comment 74 by dglazkov@chromium.org, Dec 1 2013

thakis@, sure thing. Here's are the ranges (I double-checked for better confidence):

Chromium:
http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=/trunk/src&range=230366%3A230384

Blink:
http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog_blink.html?url=/trunk&range=160257:160295&mode=html

My guess would be that the change that regressed simply exposed the bug, which was there since the throw-away machinery was introduced in http://trac.webkit.org/changeset/136956

Comment 75 by ksakamoto@chromium.org, Dec 2 2013

Cc: tasak@chromium.org
 Issue 324599  has been merged into this issue.

Comment 76 by dglazkov@chromium.org, Dec 2 2013

BTW, landing tasak@'s patch will make the problem go away: https://codereview.chromium.org/87503003/

Comment 77 by ian.hick...@gmail.com, Dec 3 2013

If the bug is cross-platform, how come only Mac users have reported it? That seems like something worth understanding...

Comment 78 Deleted

Comment 79 by anars...@gmail.com, Dec 3 2013

Ian, see comment #69. Linux users are also affected.

Comment 80 by a...@chromium.org, Dec 3 2013

Cc: kenjibaheux@chromium.org
 Issue 325223  has been merged into this issue.

Comment 81 by dglazkov@chromium.org, Dec 3 2013

ian.hickson@, the problem won't manifest as frequently on non-Mac platforms, because the last resort font fallback path is different: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/platform/graphics/skia/FontCacheSkia.cpp&sq=package:chromium&type=cs&l=109&rcl=1386012933

On Linux (and now Windows), we have (admittedly duplicate) logic for trying to look at the family strings again and make sense of the data. On Mac, we just fall down to Times.

I am actually not yet convinced that anarsoul@'s example shows the same problem -- the last resort fallback is Verdana, but it should be Arial.

There's still lots of digging to do :)

Comment 82 by bugdroid1@chromium.org, Dec 4 2013

Project Member
The following revision refers to this bug:
    http://src.chromium.org/viewvc/blink?view=rev&rev=163130

------------------------------------------------------------------------
r163130 | dglazkov@chromium.org | 2013-12-04T00:34:52.089950Z

Changed paths:
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/css/CSSFontSelector.h?r1=163130&r2=163129&pathrev=163130
   M http://src.chromium.org/viewvc/blink/trunk/Source/platform/fonts/GenericFontFamilySettings.h?r1=163130&r2=163129&pathrev=163130
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/css/CSSFontSelector.cpp?r1=163130&r2=163129&pathrev=163130
   M http://src.chromium.org/viewvc/blink/trunk/Source/platform/fonts/GenericFontFamilySettings.cpp?r1=163130&r2=163129&pathrev=163130

Store a copy of generic font settings at CSSFontSelector.

A CSSFontSelector instance does not expect for generic font settings to
ever change within its lifetime. So, it makes sense to copy and stash
them locally and avoid holding/using a Document pointer for this
purpose.

Eventually, CSSFontSelector hopes to become a per-Document font context,
which knows nothing about the Document itself, but provides an API
that a Document could use.

This also fixes  bug 236298 , since determining generic font no longer relies on CSSFontSelector::m_document.

BUG= 324991 , 236298 
R=eae,eseidel,ksakamoto@chromium.org

Review URL: https://codereview.chromium.org/93783005
------------------------------------------------------------------------

Comment 83 by bugdroid1@chromium.org, Dec 7 2013

Project Member
The following revision refers to this bug:
    http://src.chromium.org/viewvc/blink?view=rev&rev=163369

------------------------------------------------------------------------
r163369 | tasak@google.com | 2013-12-07T03:05:26.186859Z

Changed paths:
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/css/FontFaceSet.cpp?r1=163369&r2=163368&pathrev=163369
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/dom/StyleEngine.h?r1=163369&r2=163368&pathrev=163369
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/css/resolver/StyleResolver.cpp?r1=163369&r2=163368&pathrev=163369
   M http://src.chromium.org/viewvc/blink/trunk/Source/web/AutofillPopupMenuClient.cpp?r1=163369&r2=163368&pathrev=163369
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/dom/Document.cpp?r1=163369&r2=163368&pathrev=163369
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/rendering/RenderMenuList.cpp?r1=163369&r2=163368&pathrev=163369
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/rendering/svg/RenderSVGInlineText.cpp?r1=163369&r2=163368&pathrev=163369
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/css/resolver/StyleResolver.h?r1=163369&r2=163368&pathrev=163369
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/rendering/RenderListBox.cpp?r1=163369&r2=163368&pathrev=163369
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/dom/Document.h?r1=163369&r2=163368&pathrev=163369
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/dom/DocumentStyleSheetCollection.cpp?r1=163369&r2=163368&pathrev=163369
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/html/canvas/CanvasRenderingContext2D.cpp?r1=163369&r2=163368&pathrev=163369
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/dom/StyleEngine.cpp?r1=163369&r2=163368&pathrev=163369

Moving fontSelector from StyleResolver to StyleEngine.

To avoid dispatching fontLoaded event multiple times for the same font (caused by clearResolver), we should change fontSelector's owner.

BUG= 236298 , 305885 

Review URL: https://codereview.chromium.org/87503003
------------------------------------------------------------------------

Comment 84 by Deleted ...@, Dec 7 2013

I get this problem to. Attached a photo of wikipedia where font rendering was incorrect.
Screen Shot 2013-12-07 at 06.52.13 .png
255 KB View Download

Comment 85 by jhgpor...@gmail.com, Dec 10 2013

Any progress on a fix?

Comment 86 by skoc...@gmail.com, Dec 10 2013

Same happens here, ALL THE TIME! When scrolling the Wikipedia page font suddenly switches to something that resembles "Times", which makes it look ugly. Compare the both attached screenshots.

OS X 10.9
Chrome 31.0.1650.63

Is there a fix on the way? It've been seeing this behavior constantly for the last couple of weeks.
bad_font.png
636 KB View Download
right_font.png
598 KB View Download

Comment 87 by rsesek@chromium.org, Dec 12 2013

 Issue 326200  has been merged into this issue.

Comment 88 by esprehn@chromium.org, Dec 12 2013

Labels: Merge-Requested

Comment 89 by paulir...@chromium.org, Dec 12 2013

Labels: Hotlist-DevRel
The fix is now available in Canary.

Tasak, if the fix is good, can you set status to Fixed?

Elliot, are you requesting a merge to stable or beta?

Comment 90 by esprehn@chromium.org, Dec 12 2013

We probably need to merge this to Stable, it's gotten really bad in M31+.

Comment 91 by ksakamoto@chromium.org, Dec 13 2013

 Issue 325732  has been merged into this issue.

Comment 92 by ksakamoto@chromium.org, Dec 13 2013

 Issue 325734  has been merged into this issue.

Comment 93 by hus...@gmail.com, Dec 13 2013

Works like a charm on Canary. Thanks for fixing this people!

Comment 94 by jhgpor...@gmail.com, Dec 13 2013

Still not fixed in Chrome...

Comment 95 Deleted

Comment 96 by Deleted ...@, Dec 18 2013

http://puu.sh/5QsDq.png

still not fixed.
Screenshot 2013-12-18 12.21.49.png
38.9 KB View Download

Comment 97 by dglazkov@chromium.org, Dec 30 2013

comment #96, that's a different issue. Please file a separate bug.

Comment 98 by dglazkov@chromium.org, Dec 30 2013

Status: Fixed

Comment 99 by jhgpor...@gmail.com, Dec 31 2013

Still not fixed in Chrome

Comment 100 by torzsmo...@gmail.com, Jan 1 2014

+jhgpor...@gmail: please stop spamming more than 120 people. wait for the fix to come to the stable channel, or if you can’t, switch to Canary.

Comment 101 by eseidel@chromium.org, Jan 1 2014

I see "Merge-Requested" in comment #88, but I don't see an actual merge having taken place.

Was this intentional dglazkov, esprehn, kareng, laforge?

Comment 102 by dglazkov@chromium.org, Jan 2 2014

eseidel@, I was OOO, will investigate.

Comment 103 by dglazkov@chromium.org, Jan 6 2014

Labels: -M-31 -Merge-Requested M-33
Unfortunately, we missed the M32 window, and now this fix is slated for M33. This means that if your chrome://version is less than 32, you will still see the bug.

Comment 104 by m.go...@gmail.com, Jan 7 2014

Can't it be backported to 32 after the release? This bug is kind of a big deal, to imagine next 6 weeks with it...

Comment 105 by pdr@chromium.org, Jan 8 2014

Cc: kareng@google.com laforge@google.com
This is a pretty nasty bug and I've seen several posts on it now (e.g., https://news.ycombinator.com/item?id=7018982). I think it would be a mistake to let this hit the stable channel.

m32 hasn't shipped yet; can we revisit the decision to let this regression hit stable?

Comment 106 by laforge@google.com, Jan 8 2014

M33 was branched at r163968, which includes (r163369), should be no action required for 33.

Comment 107 by laforge@google.com, Jan 8 2014

Labels: -M-33 M-32

Comment 108 by abwic...@gmail.com, Jan 8 2014

re: comment #105 (pdr@chromium.org)

It has already hit stable channel. If you read the comments in the ycombinator thread you will see users experiencing this bug even on M31 stable. I myself am experiencing it on M31 stable. It's extremely annoying.

Comment 109 by kenjibaheux@chromium.org, Jan 9 2014

Labels: Merge-Requested
Re-adding the merge request since the milestone label was reset to M32.

Comment 110 by rponnada@chromium.org, Jan 10 2014

Cc: rponnada@chromium.org
Labels: TE-Verified-33.0.1750.22 TE-Verified-M33
Tested this issue on MAc 10.9 using 33.0.1750.22 (Official Build 243718) . Scrolled the wiki pages and observed the sans-serif font on Wiki page.

Comment 111 by ranjitkan@chromium.org, Jan 15 2014

Cc: ranjitkan@chromium.org
Labels: TE-Verified-32.0.1700.98 TE-Verified-M32
Rechecked this issue on Chrome 32.0.1700.98(Official Build 244465), Scrolled to "You need to read this section" and observed that the dates are displayed in Sans-serif font family. Navigated to Wiki page "http://en.wikipedia.org/wiki/Electronic_paper" and observed that fonts are displayed in "sans-serif" family.

Comment 112 Deleted

Comment 113 by robbie.t...@gmail.com, Jan 15 2014

Also seeing this in latest Chrome, 32.0.1700.77, Mac OS X 10.9.2 (Developer Beta), on this Wikipedia page, "http://en.wikipedia.org/wiki/Flashpoint_(TV_series)" on the heading DVD Release. I noticed this also leaked to my company's site suddenly, but have been seeing the issue for 2 weeks or so now on Wikipedia. Attaching screenshot of company site showing the issue.
Screen Shot 2014-01-15 at 12.51.49 copy.jpg
2.1 MB View Download

Comment 114 by behzad.g...@gmail.com, Jan 15 2014

I always use new version of chrome. I've been worked on a website for a month now. haven't seen this bug until this morning that I updated to 32  (32.0.1700.77) .  http://grab.by/tz9Y  must looks like http://grab.by/tza4 
I just saw it on wikipedia. and kinda same rendering issue on another website.

Comment 115 by robbie.t...@gmail.com, Jan 16 2014

Here are screenshots of multiple manifestations of this issue:

http://i.rxt.gd/LUbf
http://d.pr/i/IZ3m
http://i.rxt.gd/cU1T
http://i.rxt.gd/pEf1
http://i.rxt.gd/CR0W

Comment 116 by dxie@chromium.org, Jan 16 2014

Labels: -Merge-Requested
I think this is already in M32.  See comment #111

Comment 117 by esprehn@chromium.org, Jan 16 2014

Labels: -TE-Verified-32.0.1700.98 -TE-Verified-M32 Merge-Rejected
This is not in 32, it's just inconsistent and seems to only happen on OS X.

Comment 118 by goo...@mspacek.mm.st, Jan 16 2014

It is indeed still in Chrome 32, but not limited to OS X. I'm still seeing it in Linux (Xubuntu 12.10).

Comment 119 by mike.hop...@revium.com.au, Jan 16 2014

+esprehn@chromium.org I can confirm that I am seeing the bug behaviour in 31, 32 on Windows and Mac on multiple machines with different profiles. It is not OS X specific. Since 33 has landed on beta, will wait to test it.

Comment 120 by esprehn@chromium.org, Jan 16 2014

Please do confirm if it's fixed in 33 (it should be). I apologize that the fix didn't make it into 32.

dglazkov@ Users are reporting this on Windows and Linux too, I remember you saying this was something to do with the OS X font fallback path, any idea what's going on there?

Comment 121 by dglazkov@chromium.org, Jan 16 2014

The Windows and Linux both have additional font fallback paths, including platform-provided fallback. It's possible that all these fallbacks fail, but less likely. I remember that comment #69 had a screenshot from Linux, so no -- this is not a Mac-only issue.

Comment 122 by akl...@gmail.com, Jan 16 2014

I can confirm that this happened in Linux (M32).

Comment 123 by robbie.t...@gmail.com, Jan 16 2014

Is there any chance of a emergency patch being pushed to stable? We've given up on trying to convert our fonts to images or SVG due to large time and cost investment required.

Comment 124 by dglazkov@chromium.org, Jan 16 2014

Owner: kareng@google.com
Karen, see comment 123. Both esprehn@ and I are worried that, while not a security or stability issue, this bug affects quality of text and it just so happens that we really need text on the Web. That and lolcats. Can't do without those.

Comment 125 by thakis@chromium.org, Jan 16 2014

Labels: -Merge-Rejected Merge-Requested

Comment 126 by m.go...@gmail.com, Jan 17 2014

@esprehn
The thing with such bugs that are not 100% reproducible is that it's hard to be sure if the bug was fixed, especially on a Canary browser that is not used by people for everyday browsing hence these "special" occasions where it breaks are much less common.

The only way to obtain the info is to see if any Chrome 33 user sees the bug; if there are no reports, then it's probably fixed.

Comment 127 by ojan@chromium.org, Jan 17 2014

Cc: -ojan@chromium.org

Comment 128 by kareng@google.com, Jan 17 2014

i understand but m33 is coming quite soon and it seems unnecessary to add more risk to m32 at this moment when we have plenty else going on, too.

Comment 129 by esprehn@chromium.org, Jan 17 2014

For people watching the branch point + 12 weeks means this should be fixed around the end of February when M33 would go to stable.

Comment 130 by m.go...@gmail.com, Jan 17 2014

It happens all the time for me in Atlassian Stash. Some cod, normally displayed in Monospace, changes to serif, causing the code to become unreadable because of messed up indents. I then have to hover over all lines to fix it and be able to work again.

Frankly, I can't imagine having this problem for next 6 weeks or so (and Chrome 31 existed in the stable channel for way more than 6 weeks). :/

Comment 131 by kareng@google.com, Jan 17 2014

Labels: -Merge-Requested Merge-Rejected
i feel like at the stage we are, taking it is riskier than not taking it.

Comment 132 by dan.del...@gmail.com, Jan 17 2014

Trying to avoid a "me too" comment, but I must add my voice to those requesting an emergency merge to get this into M32. As a front-end developer working closely with a detail-oriented designer, hearing him complain about this issue for the next six weeks poses a serious risk to my sanity. We are also beginning to receive support requests from our users, wondering why our very expensive, normally-well-designed app sometimes looks like MS Word.

Comment 133 by jam...@chromium.org, Jan 17 2014

I don't think "risk" is the right metric here given that this is really busted right now.  It might break something else, but not merging it will leave things definitely broken.

Comment 134 by msuk...@gmail.com, Jan 18 2014

I can confirm this issue can be seen stable Chrome Version 32.0.1700.77. I can reproduce the problem by these steps, but not all the time.

1. View a webpage that uses custom fonts
2. Switch to another tab for a while, or away from the browser.
3. Return to the webpage that uses custom fonts

It does not happen on every site. Sites hosting their own fonts and sites using typekit cloud font service are subject to this problem.

Comment 135 by innatere...@gmail.com, Jan 18 2014

I wish I could provide the confirmation that this is fixed in M33, Windows 7.
I am using 33.0.1705.3, one of the last releases before canary bumped to M34 i.e. a branch point version.

This had happened quite frequently for me on Google Search.
Just did a search, opened some results in new tabs, switched away to browse those results, then switched back to the search and the font changed.
However it was less likely to happen on Wikipedia in my case, so the reproducibility could really vary ,depend, and more often than you have imagined.

For instance I am on a traditional Chinese Windows 7, but set the locale for non-unicode programs to Japanese.
Using Chrome in traditional Chinese UI but set the preferred language for web pages to English and do searches mostly in Japanese on Google Search with the hl= parameter specified to either zh-TW, JP, or en-US.
Plus I have installed the Advanced Font Setting extension and tweaked the fonts for traditional Chinese, Japanese, and Latin scripts.
A nasty environmental use case I afraid might increase the probability of your all-fallbacks-failed state.

Comment 136 by m.go...@gmail.com, Jan 19 2014

@up
The current Windows dev version is 33.0.1750.29 which suggests the last 33 Canary was 33.0.1750.0. Far newer than your 33.0.1705.3.

Comment 137 by innatere...@gmail.com, Jan 19 2014

Oops, my bad, that was a typo. I meant 33.0.1750.3 indeed.

Comment 138 by m.go...@gmail.com, Jan 20 2014

@innatere...
That is worrying... :/ Can someone reopen the bug then?

Comment 139 by thebe...@gmail.com, Jan 20 2014

This is indeed not fixed as the problem is till occurring as it always was since its introduction - haven't even noticed a "fixed" period.

Comment 140 by innatere...@gmail.com, Jan 20 2014

Sorry, apparently my previous comment was confusing.
I was meaning that I can confirm this issue fixed in 33.0.1750.3 canary.

The rest of the comment was
1. To declare why I am sure, because it was so easy for me to repro BEFORE the fix that I could even see it a constant repro. While in 33.0.1750.3 it never occurs again.
2. To give out an instance that this could be really frequent even on Windows, if not in Latin then perhaps in CJK environment? As CJK scripts are considerably nasty, so the probability of all-fallbacks-failed. Suggesting a merging be considered twice.

Comment 141 by jordanra...@gmail.com, Jan 20 2014

I'm still having this issue on Chrome 32.0.1700.77 on OS X Mavericks. It only happens in Chrome on Mac, not PC. It happens on any site, including the one I'm currently developing.

Comment 142 by Deleted ...@, Jan 20 2014

Go to https://www.infowrap.com/en/business/ which uses a custom icon font and follow the steps in the video which documents the issue. http://www.youtube.com/watch?v=AkAoOUrWV9U&feature=youtu.be

Comment 143 by lpccarm...@gmail.com, Jan 21 2014

same here, usually happens when you leave a tab open and come back to ir after a while. can't really reproduce it, it's just random.

Comment 144 by tagliala...@gmail.com, Jan 22 2014

I can confirm. It happened again just now, chrome stable Version 32.0.1700.77, mac osx 10.9.1.

Comment 145 by Deleted ...@, Jan 22 2014

Has problems with Icomoon.io issues

Comment 146 by robbie.t...@gmail.com, Jan 22 2014

This bug seems to have gotten worse over the last 48 hours. Pages are breaking within 5 minutes now. Need a fix ASAP.

Comment 147 by Deleted ...@, Jan 22 2014

when more tabs are opened the bug manifests faster.

Comment 148 by Deleted ...@, Jan 23 2014

I can confirm this issue. Happens after a minute (or more) of inactivity, also on the current tab.
Chrome 32.0.1700.77 (stable) on OS X Mavericks.

No problems with Canary or the previous stable (31).

Comment 149 by tiemevan...@gmail.com, Jan 23 2014

Same problems here (Mac, 32.0.1700.77) with an iconmoon.io font as well. 

Users started reporting issues  4  days ago, I think their browser took 4 days after the release of 32 before updating.

Comment 150 by rsesek@chromium.org, Jan 23 2014

Labels: Restrict-AddIssueComment-EditIssue

Comment 151 by dglazkov@chromium.org, Feb 3 2014

Cc: tkonch...@chromium.org abarth@chromium.org
 Issue 336170  has been merged into this issue.

Comment 152 by eseidel@chromium.org, Feb 3 2014

For anyone new to this bug:

This bug was present in M31 and M32, but should be fixed in M33.  If your seeing this or anything like it in M33, please file a new bug.

M32 is the current stable release.  Releases are historically about 6 weeks apart, about 12 weeks after "dev" branch date seen in:
http://www.chromium.org/developers/calendar

Comment 153 by ksakamoto@chromium.org, Feb 13 2014

Cc: vangelis@chromium.org
 Issue 340984  has been merged into this issue.

Comment 154 by ksakamoto@chromium.org, Mar 3 2014

 Issue 346996  has been merged into this issue.

Comment 155 by ksakamoto@chromium.org, Mar 4 2014

 Issue 336879  has been merged into this issue.

Comment 156 by rponnada@chromium.org, Jun 18 2014

Labels: hasTestcase

Comment 157 by laforge@google.com, Jan 9 2015

Labels: -Cr-Blink-Rendering Cr-Blink-Layout
Migrate from Cr-Blink-Rendering to Cr-Blink-Layout

Comment 158 by ebra...@gnu.org, May 20 2015

 Issue 244421  has been merged into this issue.

Comment 159 by cbiesin...@chromium.org, Nov 10 2015

 Issue 231680  has been merged into this issue.
Showing comments 60 - 159 of 159 Older

Sign in to add a comment