I have done some test and I've seen that sometimes webfonts aren't loaded properly. Here some link: http://www.onsitus.it/css3/web-fonts/ http://css.flepstudio.org/css3/font-face.html

So, you didn't give steps to reproduce that allow us to tell whether this bug is fixed, but since I observe a problem that I think is what you're talking about, I'm going to change the description of this bug to match that one problem. Steps to reproduce: 1. load http://www.onsitus.it/css3/web-fonts/ 2. look at the third of the four samples, showing "Starcraft Normal.ttf" Expected results: text rendered with font looks just like image above it (except a little bigger) Actual results: text is in a basic serif font I'm seeing this behavior on Windows, but it works as expected on Linux. Does this accurately describe the problem you are reporting, or was there another font that didn't work for you?

On windows, the example shown in http://css.flepstudio.org/css3/font-face.html (eldiablo.ttf) doesn't work in Firefox. Opera and Safari works as expected.

(In reply to comment #2) > On windows, the example shown in http://css.flepstudio.org/css3/font-face.html > (eldiablo.ttf) doesn't work in Firefox. Opera and Safari works as expected. I filed that as a separate bug report: bug 475182, since it's cross-platform and therefore very likely a separate bug.

Not sure why this works on non-windows paltforms, but I think this bug is INVLAID. Doesn't this: src: url('http://www.onsitus.it/css3/web-fonts/Starcraft Normal.ttf'); need to be escaped as in: src: url('http://www.onsitus.it/css3/web-fonts/Starcraft%20Normal.ttf');

If it's not escaped we'll fix it up exactly that way.

(In reply to comment #5) > If it's not escaped we'll fix it up exactly that way. Yes. It would seem that is not the issue. I copied the entire page to my website and tried correcting the URI to one of the 2 properly escaped ones (both with the ' ' represented as '\ ' and '%20') and that made no difference. Still works under Linux and fails under Windows.

A bit more testing reveled that the space in the filename was just a red herring. The issue has nothing to do with the filename, but somehow with the contents of the font file itself.

These Microsoft-fonts (.EOT) also don't work on Firefox 3.1 (IE8 works properly) http://www.microsoft.com/typography/web/embedding/ Do you think we should file a new bug for this?

(In reply to comment #8) > These Microsoft-fonts (.EOT) also don't work on Firefox 3.1 (IE8 works > properly) http://www.microsoft.com/typography/web/embedding/ > > Do you think we should file a new bug for this? Firefox/Opera/Safari do not support EOT fonts. This is as intended, no need to file a bug.

Simplified testcase Steps: 1. Download testcase to a folder 2. Download the problem font to the same folder http://www.onsitus.it/css3/web-fonts/Starcraft Normal.ttf 3. Open the locally-saved testcase Result: the text shows in the default font rather than the downloaded font The reason this occurs is that the font contains a zero-length version name record and the EOT header code is using the length to flag whether a name was found: http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/src/gfxFontUtils.cpp#1213 In general I think we should avoid loading fonts with funky problems like this but in this case, I don't think we need to be so picky since it's a relatively benign error (compared to a name record that with an offset past the end of the file for example).

Maintain a flag that goes to zero when all needed names have been found, rather than assuming length == 0 means name was not found.

One way to diagnose problems like this when they arise is to enable logging that ships in normal production builds. 1. Open console window 2. Change default directory to the where firefox.exe is located 3. Set environment vars below: NSPR_LOG_MODULES=userfonts:5,fontdownloader:5 NSPR_LOG_FILE=userfonts.out 4. Run Firefox: ./firefox 5. Load pages with problem fonts. After the pages load, information about the font download will be saved in userfonts.out. In this case, it looks something like: 0[723280]: userfonts (38df040) added (Starcraft) with style: normal weight: 400 stretch: 0 0[723280]: fontdownloader (38ddbc0) download start - font uri: (file:///C:/dev/webfontstest/Starcraft%20Normal.ttf) referrer uri: (file:///C:/dev/webfontstest/starcraft.html) 0[723280]: userfonts (38df040) [src 0] loading uri: (file:///C:/dev/webfontstest/Starcraft%20Normal.ttf) for (Starcraft) 0[723280]: fontdownloader (38ddbc0) download completed - font uri: (file:///C:/dev/webfontstest/Starcraft%20Normal.ttf) 0[723280]: userfonts (38df040) [src 0] failed uri: (file:///C:/dev/webfontstest/Starcraft%20Normal.ttf) for (Starcraft) error making platform font 0[723280]: userfonts (38df040) failed all src for (Starcraft) 0[723280]: userfonts (38df040) failed all faces, remove family (Starcraft) The "error making platform font" means that the download succeeded (i.e. no access control restrictions or network errors) but for some reason the font could not be loaded. This might be in Mozilla code that's doing font validation or it might be in OS code used to load the font.

This should not block but it's fine to set wanted1.9.1.

Ready to be checked-in?

pushed http://hg.mozilla.org/mozilla-central/rev/d08d06bdd4c9

Comment on attachment 358808 [details] [diff] [review] patch, v.0.1, use a flag to detect when all names found low impact, minor fix

Comment on attachment 358808 [details] [diff] [review] patch, v.0.1, use a flag to detect when all names found a191=beltzner

Checkin-needed for 1.9.1 branch.

pushed to 1.9.1 http://hg.mozilla.org/releases/mozilla-1.9.1/rev/cad700a6b3c3