[Webkit-unassigned] [Bug 79312] New: Font-face fonts in a dynamically-added stylesheet don't render when offsetWidth is called

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=79312

           Summary: Font-face fonts in a dynamically-added stylesheet
                    don't render when offsetWidth is called
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Macintosh
               URL: http://seanmcb.com/typekit/webkit/12.02.16_fontface_te
                    st.html
        OS/Version: Unspecified
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: Text
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: sean at typekit.com


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

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.