Open Bug 522223 Opened 15 years ago Updated 2 years ago

Fonts downloaded via @font-face seem to be applied very late in this case

Categories

(Core :: CSS Parsing and Computation, defect)

Product:
Core
Component:
CSS Parsing and Computation
Platform:
x86
macOS
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
blocking2.0 --- -

People

(Reporter: IDontUseMozillaAnyMore, Unassigned)

References

(
URL
)

Details

(Whiteboard: url in comment 0 wrong) 

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3
Build Identifier: 

If you specify a font to be downloaded via an @font-face rule then it is not cached and used for other pages on the same site.

You can see the issue on this site http://www.dit.org wait for the site to load
and then hit any of the orange buttons on the top strip. When you click the
buttons a page will load into a frame on the left hand side of the screen. Each
of those pages uses the same CSS to download the same font. As each is loaded
it shows the issue where the page is rendered in the fallback font and then re-rendered once the font is downloaded. 

If I watch carefully I can even see it happen on my machine
with a fast connection. Given this is the very same font that is used for the
top strip and the titles on each page in the main area then I would never
expect to see the font download at all, other than when loading the initial
page. Except that I do, all the time.

Reproducible: Always

Steps to Reproduce:
1. Visit the site above
2. Click an orange button
3. See the page load on the left.
4. Click another orange button.
5. See the second page load.
Actual Results:  
Each page renders using the fall back font and then redisplays using the downloaded font.

Expected Results:  
Given that the same font is used by the orange buttons at the top of the screen and each of the pages on the left hand side the font should already be downloaded and ready for use by the page. No fall back rendering should be required.
Summary: Fonts downloaded vis @font-face are not reused between pages on the same site → Fonts downloaded via @font-face are not reused between pages on the same site
Does the behavior change if you eliminate the cache-control headers that are being sent along with the pages at this site? I'm wondering if they are affecting the linked resources as well as the actual HTML pages.
http://www.ditl.org/ is the right url to be testing.
Whiteboard: url in comment 0 wrong
So I just did an HTTP log (directions at http://www.mozilla.org/projects/netlib/http/http-debugging.html and anyone can do this with any Firefox build).  The .ttf file is in fact cached on the HTTP level after the first time and read from the cache every single time after that.  The font file is about 30KB, so shouldn't take very long at all to read from cache.

I just checked this last, and from nsUserFontSet::StartLoad being called to nsFontFaceLoader::OnStreamComplete being called takes about 20ms for the cached loads (according to some printfs of PR_Now()).

At the same time, I most definitely see the text in a different font before it switches to the "right" font while all of the above is going on.  Jonathan, want to look into what's going on here?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Fonts downloaded via @font-face are not reused between pages on the same site → Fonts downloaded via @font-face seem to be applied very late in this case
Disabling JS, then loading http://www.ditl.org/listspecies.php?fed should be a simple way to reproduce.  Reloading leads to pretty obvious lags in the user font being applied.

I tried saving page complete and dropping in the TTF, but the version loaded from my hard drive does NOT show the problem.  :(
OK, that's not a good testcase.  Reloading in fact forces revalidation (so a server round-trip), which is a 300ms or so delay in my case.  Definitely user-visible.  If I just hit "enter" in the url bar on the url in comment 4 I do NOT see the issue.

However with script disabled I do still see the issue on the http://www.ditl.org/ page while clicking the orange buttons at the top.
data:text/html,<iframe%20src="http://www.ditl.org/listspecies.php?fed"%20width="100%"%20height="100%"></iframe>

does show the problem quite nicely when hitting enter in the url bar (script still disabled).
And in that case we are definitely reading the font from cache in about 20ms each time.
blocking2.0: --- → ?
Flags: blocking1.9.2?
Yes perhaps you are loading the font from cache for that page, however, if you go to another page from the same site then the font is re-downloaded and you see the delay. Surely once the font is downloaded for a given site it should be used from the cache for each page loaded from the site.
Ian, perhaps you didn't understand.  I checked the actual network traffic.  The font is NOT being redownloaded.  There _is_ a delay applying it, though.  That can be easily seen with the data: URL small testcase.
Yes, I did understand, however, you are talking about reloads of the same page over again. I was talking about loading one page which uses the font and then loading another different page which also uses the same CSS to download the same font. In this case both pages download the font. Or at least it seems that way.

You (collectively) seem to be saying that it is cached after the first load of the page. Given that the same font is used to display the top strip of buttons using the same CSS that font should already be downloaded and available in the cache when you load the page for the first time. This also goes for the other pages that load when you click the other buttons on the top orange/blue strip.
> Or at least it seems that way.

It seems to you wrong.  Comment 3 applies to loading different pages on the site.  Comment 9 is accurate as to what's happening in that situation.
That not what I read that message to say. It clearly says "The .ttf file is in fact cached on the HTTP level after the first time and read from the cache every single time after that.". The key issue being "after the first time". Perhaps Boris can clarify which of us is correct.

I'm not particularly bothered which of us is correct so long Firefox does not download the font more than once no matter how many pages I visit on the same site. I would also like to see the think you are discussing fixed obviously :)
Just a note the page pointed to comment #3 has the wrong URL for the nightly builds. It should be http://ftp.mozilla.org/pub/mozilla.org/mozilla.org/firefox/nightly/latest-trunk/ The one pointed to is from 2005.
"first time" == "the first time after browser startup when you try to fetch that particular url", not "the first time you load a given web page".

I do encourage you to just make an HTTP log while doing whatever steps you want and then look at it, if you want to see what's going on in terms of network requests.
Apologies then. I just wanted to make sure this item was also on the radar. Glad to here it is.
How do I see the problem using the testcase in comment 6?  I don't see any text in that page; it looks like it's all images.
However, when loading http://www.ditl.org/strip2text.php, I'm seeing that we don't seem to be doing the necessary relayout for the new font metrics.
David, sorry for not getting this in the bug...  Jonathan and I discovered that you need to load the url in the url field first; the site does some sort of sniffing on that front page and sets cookies to indicate whether to use images or @font-face.  Make sure script is _enabled_ when you do that.

Once you've done that, you should be able to reproduce with the data: testcase, whether script is enabled or not.
Apologies to the last three entries. There used to be some code in there that fell back to images if the font wasn't available. It should have been removed by now but hadn't been. You should now find that it always uses the CSS. Hope this helps with the testing.
as for comment #17 if you are expecting the width of the cells at the top to change depending upon the font then I can tell you that it wont. It's not currently setup to do that.
(In reply to comment #17)
> However, when loading http://www.ditl.org/strip2text.php, I'm seeing that we
> don't seem to be doing the necessary relayout for the new font metrics.

This is a separate bug, not present on Windows or on the (currently used) ATSUI font backend on Mac.  I filed it as bug 523717.

On Linux, I don't see the bug you guys are seeing; could it be Mac only?
I can reproduce this on Windows (in a VM running on Mac).  It's harder to notice there, but certainly shows up on the original site when I click the "Fleets" button at the top.
On Linux in a vm I don't see the problem, but there's more general flicker when the frame loads...

And note that the frame bit seems to be required to show the bug.
Flags: blocking1.9.2? → wanted1.9.2+
I've noticed this a bunch on http://www.rypple.com - if I open a tab with that site, I see the flicker from bug 499292. As long as the tab is open or in bfcache, the flicker won't reoccur. If I close the tab and wait a bit (so it expires from bfcache) then the flicker returns.

We really should be caching that font file.
Mike, you see flicker in an instance of rypple being loaded in tab B disappear if rypple is already loaded in tab A?

Note that the rypple case is complicated by their usage of typekit (e.g. I can't even find their font-face rules so far).  It's probably worth having a separate bug on it.
(In reply to comment #25)
> Note that the rypple case is complicated by their usage of typekit (e.g. I
> can't even find their font-face rules so far).  It's probably worth having a
> separate bug on it.

Typekit uses data URL's to store the font data in the @font-face definitions.  Data URL's are currently handled in the same async way that other font data is handled which probably shouldn't be the case.  That's covered in bug 512566.
Is this still a problem? I suspect that bug 816483 might have addressed the original issue here, but I was not able to reproduce it in brief testing with a pre-816483 browser release, so also I wonder if the site has changed in such a way that it is no longer a good testcase.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.