UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.62 Safari/537.36 Example URL: https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/UserTiming/Overview.html#performancemark Steps to reproduce the problem: Haven't been able to track it down properly. Happens after viewing the page for a long time (and it could relate to navigating between tabs). I noticed the issue on the page I included, but have also noticed it elsewhere. Seems to apply when the tab has been open in a background tab for several hours while continuing normal browsing. Never noticed it on an app-like site, such as gmail, facebook or stackoverflow. What is the expected behavior? Text displays in the font chosen by the website What went wrong? Some text elements (seems to be limited to elements marked as monospace by either being a code tag or through a css style, but I have also seen this happen to a sans-serif button) are rendered using a serif font. This is narrower than the correct font, but the element itself size remains the correct size (leaving blank space after the text). When the content is redrawn (e.g. due to a hover effect from mouseover), it returns to the correct font. Other attributes (e.g. colour) appear to work fine. Only ever seen it happen to content which is in some way interactive (or possibly the child of an interactive element?). Applies to the entire element (entire span/link/cell). Seen it happen to <code> within <a> tags (where the <a> tag has a hover style) and <td> within <tr> (where the <tr> has a hover style. Not sure how the <button> fits in (simple button with just text content, but I have only seen that happen once) Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? N/A Chrome version: 29.0.1547.62 Channel: stable OS Version: OS X 10.7.5 Flash Version: Shockwave Flash 11.8 r800 This has been an intermittent issue for at least a few months, possibly longer. It is quite rare (and only on some pages), but when it does happen, it will often influence many elements on the page. I tried to reproduce the issue now to add a screenshot but couldn't (after thinking to post a bug report the broken content had already been re-rendered in the link I posted). When it next happens, I will update this issue with a screenshot and any more details I notice. It could be some time before it happens again.
Aug 31 2013,
After flailing about like a madman on this page https://api.poikos.com/ I got it to happen again, several times. This was from scrolling up and down rapidly (using 2-finger scrolling on a trackpad with momentum if that helps). The page wasn't open for very long. The page is… huge. As I said, it also happened on the w3 page which is much shorter (so likely easier to debug). The first pair of screenshots is 2 td elements in this section: https://api.poikos.com/#api_post_scanid The second pair shows a bunch of var elements (and 1 td element) from this section: https://api.poikos.com/#api_get_scanid The second pair shows how the elements keep their initial size.
Sep 5 2013,
davidje13, Thanks for the report. If possible could you please test this issue with Mac OS X:10.8.4? Thank you.
Sep 11 2013,
I'm using Chrome 29.0.1547.65 on Mac OS X 10.8.4. I have encountered this bug on two sites so far: http://cloud.feedly.com/ (I have observed this happening to article titles a couple of times) and http://www.weethoehetzit.nl/ (where I've seen all the links with the red background -- there are four of them on the front page -- affected). Like davidj..., moving the mouse onto the affected element will cause it to start using the correct font. According to the Developer Tools, the CSS actually refers to the correct font, and toggling any style off will also cause the element to be rendered with the correct font. I cannot reliably reproduce this, but with this bug just happening on http://www.weethoehetzit.nl/, I suspect that this only happens on tabs loading in the background. The tab exhibiting this bug was loaded by cmd-clicking on the red bar links on that site.
Sep 16 2013,
I'm afraid I don't have 10.8.4. This is a work machine which is tricky to update. Hopefully zr40's confirmation is enough? Just to add, I'm pretty sure this is happening very often, but hardly noticeable. Often when I switch back to a tab or re-focus Chrome, I notice the text flicker, and (though it's hard to tell), it appears to be the same bug. Again it might be my imagination but it seems to happen mostly to buttons.
Sep 16 2013,
Ah, I should clarify; I am davidj...@gmail.com. This is my work account.
Oct 5 2013,
I have now also observed this behaviour on article headers on http://cloud.feedly.com. Using chrome 30.0.1599.69 on Mac OS X 10.8.5
Oct 29 2013,
i could not reproduce this issue in latest stable chrome 30.0.1599.101 is there any other repro steps ?
Oct 29 2013,
This bug also appears to be present in Safari 7, so it could be a Webkit/Blink bug. I can't reliably reproduce this with Feedly, but it most often seems to be happening when opening an article from Feedly's "All" view in a new tab using the 'v' key. After spending several minutes reading an article opened this way, returning to Feedly by closing the tab often causes this bug to be visible.
Nov 18 2013,
I'm seeing this happen ALL THE TIME now. For example, I just had a simple Wikipedia page in a non-front tab (http://en.wikipedia.org/wiki/Alabama_Army_National_Guard), and when I came back to it about 3 minutes later, the text had re-rendered into serif. I'm on OS X 10.6.8 running Chrome 33.0.1707.0 dev on this machine, but have seen it on my OS X 10.8.5 machine as well.
Nov 18 2013,
I've also noticed this issue, even on websites that use stock "sans-serif" as font-family get the font to serif after some time. Chrome 32.0.1700.14 (Official Build 234606) beta Mac OS X 10_9_0 (Mavericks) Happens on my iMac and MacBook Air.
Nov 27 2013,
@ davidje13: Are you seeing above issue with latest chrome version "31.0.1650.57"?
Nov 28 2013,
It sounds like this may be another dupe of 236298.
Nov 28 2013,
Sign in to add a comment