RESOLVED DUPLICATE of bug 7918679312
Font-face fonts in a dynamically-added stylesheet don't render when offsetWidth is called 
https://bugs.webkit.org/show_bug.cgi?id=79312
Summary Font-face fonts in a dynamically-added stylesheet don't render when offsetWid...
Sean McBride
Reported 2012-02-22 17:57:00 PST
This is a bug that we recently found in Chrome 18 and tracked back to Webkit (because it can be reproduced in Webkit nightly). It affects all Typekit kits on webpages and will prevent the fonts from showing up when the page loads. Even if we incorporate a workaround into our JS code, we'll still have many old kits that don't republish. So, although it seems like a minor/unusual issue, it's kind of a big issue. The bug is triggered when a stylesheet <link> tag containing some @font-face declarations is dynamically added to a webpage. Immediately afterwards, if you trigger a short timeout and then call offsetWidth on an element in the document, the fonts will fail to render until you totally redraw the page or open the web inspector to the Elements pane. There are many small changes that will prevent the bug from triggering, including setting a longer timeout, not using a timeout at all, not dynamically inserting the <link> tag, using a dynamically inserted <style> tag instead, or adding an empty <style> tag in the markup after the <script> tag, among others. This seems to suggest a timing issue or race condition in the external stylesheet combined with using offsetWidth. To reproduce: - Go to http://seanmcb.com/typekit/webkit/12.02.16_fontface_test.html - If the bug doesn't trigger immediately, hit the reload button - Observe that the first headline renders in a fallback serif instead of Sniglet - Open the web inspector to the Elements pane - Observe that the first headline now renders in Sniglet - Open the other "control" example pages to see how changing various things about the page prevents the bug from triggering On Mac OSX 10.7.3: - Google Chrome 17.0.963.56 (Official Build 121963) with Webkit 535.11 (@107413) does NOT reproduce the issue - Google Chrome 18.0.1025.33 (Official Build 122015) with Webkit 535.19 (@107711) DOES reproduce the issue - Safari Version 5.1.3 (7534.53.10) does NOT reproduce the issue - Webkit Nightly r108405 DOES reproduce the issue - Webkit Nightly r108509 DOES reproduce the issue On Windows 7: - Webkit Nightly Version r108511 does NOT reproduce the issue
Attachments
Add attachment proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1 2012-02-23 10:48:13 PST
Is this same as bug 79186?
Sean McBride
Comment 2 2012-02-23 12:43:27 PST
It definitely looks related to bug 79186. That one involves a dynamically inserted link after a timeout. This one involves a dynamically inserted link immediately, followed by using offsetWidth on any element after a timeout. Slightly different triggers, but it seems likely that they could have the same root cause?
Sean McBride
Comment 3 2012-02-23 13:12:57 PST
Looks like this bug https://bugs.webkit.org/show_bug.cgi?id=79021 and this Chromium bug http://code.google.com/p/chromium/issues/detail?id=114928 are also similar. After finding http://trac.webkit.org/changeset/108574 and downloading the latest webkit nightly, I've verified that my test case no longer triggers the bug. So it looks like this fixed my issue too. Sorry for the duplicate bug. When I first found this issue and searched before I started working on isolating it, bug 79186 hadn't been filed yet. It's awesome that this is already fixed. Now I just have to figure out if the affected versions will make it into any non-beta browsers that we need to incorporate workarounds for. *** This bug has been marked as a duplicate of bug 79186 ***
Note You need to log in before you can comment on or make changes to this bug.