654081 - Firefox 4 doesn't cache font file in TTF or WOFF format

Status: RESOLVED WORKSFORME

(Core :: Layout: Text and Fonts, defect)

Description

[Razvan MIHAIU]

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0.0) Gecko/20100101 Firefox/4.0
Build Identifier: Build identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

Firefox 4 doesn't cache font file in TTF or WOFF format.

Sample pages:
http://www.stevesouders.com/tests/font-face/cache.php?t=1304333777
http://www.myrddin.de/world-of-warcraft/

Because of this issue, the custom font is reload on EACH page access. A delay of 1-2 seconds appears before displaying custom fonts for each page access.

All other browsers (including legacy FF - 3.6) are caching the TTF/WOFF files.

I discovered this problem while developing a local page - not accessible from Internet. For this page, I made sure that both the MIME type and expiry headers are properly set:

Server	nginx/0.7.65
Date	Mon, 02 May 2011 10:55:55 GMT
Content-Type	application/x-font-ttf
Last-Modified	Tue, 05 Apr 2011 15:09:54 GMT
Transfer-Encoding	chunked
Connection	keep-alive
Expires	Thu, 31 Dec 2037 23:55:55 GMT
Cache-Control	max-age=315360000
Content-Encoding	gzip


Despite this, FF4 refuses to cache the font files!


Reproducible: Always

Steps to Reproduce:
1. Go to one of the test pages provided above;
2. Navigate around;
3. There is delay when displaying custom fonts even if the page was already visited 2 seconds ago;


Expected Results:  
The browser should cache the font files when instructed so. Expected behavior: when the font is in browser's cache, it should display it immediately (the user shouldn't notice any delay on the GUI)

Comment 1

[Razvan MIHAIU]

Additional info: my test web server is compressing the TTF file (Content-Encoding    gzip);

Even if compression is disabled we are still facing the same isssue => this is NOT related to compression of the file.

Comment 2

[Boris Zbarsky [:bzbarsky]]

So I just started Firefox 4, loaded <http://www.stevesouders.com/tests/font-face/cache.php?t=1304333777>.  It reported "page load time = 8528 ms".  I clicked the "Cache Test" line; it reported "page load time = 20 ms".

So it sure looks like the font is cached fine.

So what's special about your setup?  Do you see the problem in a clean profile?

Comment 3

[Razvan MIHAIU]

Maybe the problem is not related to caching ... not sure at this point.

If I try the cache test page with FF40 on OpenSuse I get a page reload time bigger than 7000ms each time (I tried about 10 times).

But if I try the same from Windows - FF401 I get the same results as you ... about 20ms.

The thing is, on my test page, the custom font is displayed after 1 second or so in both browsers (FF40/Suse & FF401 / Windows). On any other browser (Opera11/Chrome11/IE9) there is no such delay after the initial page load.

The behavior is exactly as seen on this page:
http://www.myrddin.de/world-of-warcraft/

Please navigate around and check the right menu (from the sidebar). As you can see, the menu is using a custom font. The font briefly disappears when navigating among pages (for ~ 1 second on my end).

If this is not a caching issue (both FF with caching and without caching show the same behavior) then what can it be?

About IE9: I tried the debug/networking panel in IE9. This browser clearly shows a 304 answer from the server. I tried the same with Firebug on FF400/Suse and FF401/Windows and I get 200ok each time. In other words, FF is fetching the file each time (if it would cache then it should say 304 not modified).

How do I test with a clean profile? The only addon that I have is Firebug. Should I get rid of it and test again?

Comment 4

[Razvan MIHAIU]

The best thing would be to investigate why FF is not getting a 304 return message for the font file.

The sample page from above seems to show inconsistent results in Chrome in the sense that sometimes the font seems to be cached while on some subsequent tries, the font is displayed with a delay.

Can you add an IP to your hosts file? In that case you could access a local page that I use for testing. This page shows the most consistent behavior: always display right in Chrome/IE9 and always display with a delay on FF4.

Comment 5

[Boris Zbarsky [:bzbarsky]]

> How do I test with a clean profile?

Simplest way is to just create a new profile alongside your old one.  See http://support.mozilla.com/en-US/kb/Managing%20profiles#w_creating-a-profile

> Should I get rid of it and test again?

At least disable it and test again, yes.

I tried your test page.  The font is cached there; I don't see us making an HTTP request for the font at all, because the font is in the cache.  I _do_ see a slight delay in the font appearing, but it seems to be completely unrelated to the cache.  I think we've had other reports of that sort of issue.  Jonathan, do you recall offhand?

As for why your server responds with 200 instead of 304... I have no idea!  What does the request you see Firefox sending look like?

Comment 6

[Razvan MIHAIU]

This is definitively a bug in FF4. These are my findings:

1. Firefox 400 / OpenSuse always has a cache bug; this page:

http://www.stevesouders.com/tests/font-face/cache.php?t=1304353394

always loads in 7000+ms. It is never caching the output from the CGI file (this is
the file that sends the TTF content);

2. Firefox 401 / Windows has a cache bug that doesn't always pops up.

The cache manages to work for this URL:
http://www.stevesouders.com/tests/font-face/cache.php?t=1304353394

At first, I did not understood why it worked there but it was not working in my case.
It turns out that the output of a script (like CGI or PHP) *is* sometimes cached but a simple
TTF file is NEVER cached (even if all the headers are correctly set).

Keeping that in mind, I managed to make it work partially with a trick: I wrote a small
PHP file:

<?php

$file_id = intval($_REQUEST ['file_id']);

$file_name = '';
switch($file_id)
{
	case 1:
		$file_name = '/var/www/dev/static/webfont_s.ttf';
		break;

	default:
		exit();
}

$expires = 60*60*24*14;
header('Content-Type: font/ttf');
header('Pragma: public');
header("Cache-Control: public, maxage=" . $expires);
header('Expires: ' . gmdate('D, d M Y H:i:s', time() + $expires) . ' GMT');
header("Last-Modified: Mon, 1 Jul 1997 05:00:00 GMT");
header('Content-Length: ' . filesize($file));
ob_clean();
flush();
readfile($file_name);
exit();


I think that some developer found the issue and partially got it fixed in 401.
FF 400 is definitively broken for this functionality while on FF401 sometimes this is working.

It may also be a rendering problem as I found that sometimes the file IS taken from cache, but
the font is still displayed with a delay of approximatively 1 second?!

I also found that if the HTML file itself is small theere is a pretty big chance that
the whole thing will work 100%. If the content of the HTML file is more complex
then is almost never works like it should. Also, if you are reloading the SAME file again
and again, you seem to get a better change at making it work.

This is why this file works almost 100% of the cases - it is SMALL & you are always reloading
the same file without visiting someting else in the meantime:
http://www.stevesouders.com/tests/font-face/cache.php?t=1304353394


FF 3.6.16 is working flawlessly in ALL situations (in the exact conditions as FF4).


PS: I tried with Firebug disabled and I got the same results.

Comment 7

[Boris Zbarsky [:bzbarsky]]

OK.  If you have a case that always shows the bug, could you please create an HTTP log following the instructions at https://developer.mozilla.org/en/HTTP_Logging and attach it here using the "Add an attachment" link?

Comment 8

[Razvan MIHAIU]

Attachment: Firefox 4.00 / Open Suse loads a web page that has problems with caching TTF files

Comment 9

[Razvan MIHAIU]

I added the attachment for FF4.0 on OpenSuse.

The browser would start with http://dev1.ro and the problem could be seen immediately on that page (all the fonts from the file book_antiqua-webfont_s.ttf are loaded with 1 second delay.

Just to make things a bit more clear, I navigated 1 more page: the same delay in font rendering can be seen.

What is interesting is that there are a lot of "resolving ..." lines in the file despite the fact that only 1 tab was open. It looks like FF is inquiring the DNS for all the links on the page (most probably this is done just in DEBUG mode).

Comment 10

[Jo Hermans]

(In reply to comment #9)
> What is interesting is that there are a lot of "resolving ..." lines in the
> file despite the fact that only 1 tab was open. It looks like FF is inquiring
> the DNS for all the links on the page (most probably this is done just in DEBUG
> mode).

That's the normal DNS prefetching. Do you have DNS problems ?

There's no 'debug' mode actually, even if you use the nightly builds, unless you compile it yourself.

Comment 11

[Razvan MIHAIU]

No, I don't have problems with the DNS. I was not aware of the DNS prefetching. 

You are probably doing that thinking that the user will click links on the page. When looking at it from this point of view it makes sense.

Comment 12

[Boris Zbarsky [:bzbarsky]]

> I added the attachment for FF4.0 on OpenSuse.

Thanks.

So what I see there is that the font lives at <http://static1.dev1.ro/flexminds-plugin/book_antiqua-webfont_s.ttf> but the page linking to it lives at <http://dev1.ro>.  This is a cross-site access, and the font does not send the right CORS headers to be usable cross-site, so the font access is disallowed.  That means that the HTTP connection is closed before we have all the font data.  That means the data is not cached, of course, so the next time you ask for the font we have to ask the server again.  And incidentally the font is not actually used for the page.

Fixing the server at static1.dev1.ro to send the right headers with the font should make things work there.

Comment 13

[Razvan MIHAIU]

Accessing a subdomain is cross-site-access?

Allright, I will try that but I have some doubts: the font is DEFINITIVELY used on the page. I can attach a screen shot if you want: with & without this font. The difference is quite visible.

If this would be the matter, then the font should not be used at all. Screenshots are coming.

Comment 14

[Razvan MIHAIU]

Attachment: dev1.ro with the font BookAntiqua

Comment 15

[Razvan MIHAIU]

Attachment: dev1.ro without the font BookAntiqua

Comment 16

[Razvan MIHAIU]

Attachment: dev1.ro with the font BookAntiqua

Comment 17

[Boris Zbarsky [:bzbarsky]]

> Accessing a subdomain is cross-site-access?

Yes.

> the font is DEFINITIVELY used on the page.

Dunno.  All I have to go on is your attached log, and it shows the font loads being killed off by the same-origin policy.

Comment 18

[Razvan MIHAIU]

Please check the screen shots.

From my side, I will do the required changes to the server.

Comment 19

[Razvan MIHAIU]

Attachment: Output from Firebug after adding the header "Access-Control-Allow-Origin *"

Comment 20

[Razvan MIHAIU]

Attachment: Firefox 4.01 / OpenSuse log after adding the header "Access-Control-Allow-Origin *"

Comment 21

[Razvan MIHAIU]

I added the header "Access-Control-Allow-Origin *" for the subdomain static1.dev1.ro but I don't see any difference in behavior.

Please find attached a Firebug screenshot - two things you can see there:
1. the header "Access-Control-Allow-Origin *" - is being sent;
2. there is no "cache" tab on Firebug;

On the front-end I see the same delay when rendering the BookAntiqua font.

Please note that in the meantime I upgraded my Firefox version to 4.01 / OpenSuse. The previous log was from Firefox 4.00 / OpenSuse.

Comment 22

[Razvan MIHAIU]

I decided to switch to the font "Palatino Linotype" which is very very similar to Book Antiqua. This font is also very widely available.

Nevertheless, I think that the caching or rendering problem in FF4 should be addressed. I am following this and provide support whenever needed.

Comment 23

[Boris Zbarsky [:bzbarsky]]

Hmm.  That second log shows us caching the file correctly... but when we ask for access to the cache entry the second time we get write-only access.

Honza, any idea what's going on there?

Razvan: can you please do that last log again but set the modules being logged to "cache:5,nsHttp:5" (so no need to log the host resolver or socket stuff, but do log cache stuff)?

Comment 24

[Razvan MIHAIU]

Attachment: The requested log - 'cache' and 'nsHttp' only!

Comment 25

[Razvan MIHAIU]

I reverted back to this morning's CSS - the one with the custom font - and run this only with 'cache' and 'nsHttp'. Please check.

Comment 26

[Boris Zbarsky [:bzbarsky]]

The relevant part of that log (the response to the ttf file request):

-1012926720[7fbbd4664e10]: http response [
-1012926720[7fbbd4664e10]:   HTTP/1.1 404 Not Found
-1012926720[7fbbd4664e10]:   Server: nginx
-1012926720[7fbbd4664e10]:   Date: Thu, 05 May 2011 17:18:52 GMT
-1012926720[7fbbd4664e10]:   Content-Type: text/html
-1012926720[7fbbd4664e10]:   Content-Length: 162
-1012926720[7fbbd4664e10]:   Connection: keep-alive
-1012926720[7fbbd4664e10]: ]

Comment 27

[Honza Bambas (:mayhemer)]

I'll take a look.

Comment 28

[Honza Bambas (:mayhemer)]

Razvan, is this bug still actual?  Do you still have some way to reproduce?  Sorry to take this so long time to respond.

Comment 29

[Honza Bambas (:mayhemer)]

Based on zero response and no duplicates I'm closing this as WFM.  Razvan, feel free to reopen when still reproducible.