Losing face with IE8

Posted on 23rd February 2010 by Kenneth

I’ve discovered a bug in IE8.
It’s definitely a browser bug, as I shall demonstrate.

If you are using @font-face for your main site, and for your iframe, then you may find that the font-face is removed and replaced with arial or helvetica when the iframe is removed from the page. This is a common effect of modal iframe lightbox systems, like shadowbox or thickbox.

My assumption is that the iframe is ‘stealing’ the font-face EOT file, and killing references to it when the iframe is removed. This affects the main page.

In tests, I’ve found that this effect depends on both the cache and the element with focus when the iframe is removed. This dependance (especially on the cache) makes this effect quite hard to reliably reproduce.

Interestingly, the effect does not cause a repaint of the page. You need to scroll or move a window over the top to cause a repaint, revealing the unstyled text. Note also that it is the font rendering that has changed, but not the letter positioning – causing our ‘unstyled’ font to look even worse than plain text.

As promised, a demo:
You’ll need IE8. You want this page to be cached (try refresh, but not ctrl-refresh, with cache status as automatic). Note that the ‘kill frame’ link below does not return false.

This text is styled


Click this link to kill the iframe.
Now resize the window to try and trigger a repaint.
(This effect is quite unreliable, so you may need to refresh and kill a few times to see it happen. If you just can’t Click here for a screenshot)

My workaround solution is to reload the main page stylesheet after the box is closed.
Hardly pretty, but it should work. I’ll leave it to the hardcore CSS/JS fraternity to try and reload the font-face lines themselves.

Add an ID to your stylesheet tag:

<link id="main-css" rel="stylesheet" type="text/css" href="/css/styles.css" />

Then, after your box closes, reload it:

document.getElementById('main-css').href=document.getElementById('main-css').href;
//or in jQuery
$('#main-css')[0].href=$('#main-css')[0].href;

Additional:
Make sure your iframe doctype matches the container. It’s possible that if they don’t match, then only one will show the fonts.

This entry was posted in Projects and tagged , , , . Bookmark the permalink.
  • http://www.wowcher.co.uk/ Carl Brown

    I'm glad i'm not alone…..i just came across this bug today. I have a site which doesn't use the @font-face rule (http://www.londonsbest.com), but it includes an iFrame for a site which does (http://www.wowcher.co.uk). Sometimes, and only sometimes, when you refresh the page, text on the parent frame changes to the font specified in the iframe's page's CSS. Sometimes its all of the text, sometimes only small sections (like the footer, for example). As soon as you interact with the page in anyway, the text returns to the normal font. As it happens, the DOCTYPEs are the same on each site. Hopefully refreshing the CSS will cure the problem.
    I'll let you know if i come across a better solution!

  • Brian

    I'm wondering if an issue I'm having is related to that of this post. Please take a look and let me have your thoughts.
    http://forum.developers.facebook.com/viewtopic….

  • kennethkufluk

    Yes, that's the same problem. My proposed solution should work for you, but you'd need to use it on a focus change.

  • http://twitter.com/dondondon Don O.

    I have this problem as well, but I am confused on how to use your solution. If I want my font-face’s restored immediately after the page and iframe is fully loaded, why do I have to reload the stylesheet on a focus change?

  • Sean McBride

    Kenneth, have you made any more discoveries related to this bug?

    I’m running into the a very similar issue. I’m dynamically adding @font-face rules to an iframe, and every time another @font-face is added, the fonts in the parent frame show up either as the newly loaded font, or as a weirdly-spaced version of the original font.

    I can’t figure out a better solution other than forcing a repaint, but you still see a flash of weird fonts in the parent frame, which is still pretty unacceptable.

  • Anonymous

    I wish I had. My problem was the sheer difficulty of getting a reproducible bug. Even after I’d written this article and thought I had it 100%, I found it still worked intermittently.

    If you’ve got a better test case, I’d run it past the guys from MS to see if they can see what’s really happening under the covers.

    Is it still an issue in IE9?

  • Sam Trenholme

    No, IE9 has fixed the issue, and, annoyingly enough, IE9 fixes the issue even when using “IE8″ rendering mode.

  • Fede Freedom

    Thanks man, your fix worked great!

  • Pingback: IE8 web font iframe bug workarounds | SeekPHP.com

  • Manifm

    Thanks, it work prefect for me

  • http://profiles.google.com/emmecinque Mike McNally

    Two things: first, the astro background and its impact on my browser’s responsiveness get kind-of old after a couple of visits. Perhaps there could be a way to shut it off.

    Now, the real deal is this: I’ve found that having more than two fonts listed in the “font-family” property setting where the web font is actually *used* is necessary to trigger the bug. In other words, “font-famly: your-font, sans-serif;” works fine, while “font-family: your-font, Arial, sans-serif;” does not.

    Also it’s been suggested in an answer to a Stackoverflow question on the topic that simply disabling and re-enabling the style element suffices to “reload” the font-face declarations. However, that’s moot for me because dropping the font-family list down to two seems to do the trick (for me).

  • http://profiles.google.com/emmecinque Mike McNally

    See this Stackoverflow thread for some fascinating discoveries: http://stackoverflow.com/questions/7768029/ie8-web-font-iframe-bug-workarounds

  • MBonera

    Thank you very much! It works fine!
    Morrizor – Italy

  • Pingback: Meredith Dodge - @font-face problem with Facebook in IE8