Closed Bug 862222 Opened 7 years ago Closed 6 years ago

Allow to circumvent caching of platform instantiations of webfonts


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

Not set





(Reporter: sebo, Assigned: jfkthame)





(2 files)

Bug 816483 implemented caching for webfonts instantiations.
This avoids unnecessary work to be done when the font is reused somewhere.
Though it is counter-productive for web developers, because there is no way to circumvent this cache to be able to see and analyze those requests.

Therefore I think caching webfonts should consider the browser's cache setting and reloading the page via Ctrl+F5.

Test case:
1. Open the Web Console on (Ctrl+Shift+K)
2. Delete the browser cache
3. Reload the page

=> The request to the font is not shown while it should be shown.

FWIW Chrome 26.0.1410.64 does this already.

Yes, there really should be a way to circumvent this, but right now it's very awkward (and slow, as you have to wait for font instances to expire even after leaving the page) to work around it.
Blocks: 816483
Ever confirmed: true
Duplicate of this bug: 874079
This seems to work OK to make Shift-Reload bypass the webfont cache; it checks for the BYPASS_CACHE flag in the docshell's loadType, and just skips the cache lookup if this is set.
Attachment #752094 - Flags: review?(roc)
Assignee: nobody → jfkthame
I suspect Shift-Reload is probably the most convenient tool for authors who want to ensure they're seeing the latest version of their font during development (for example). However, it'd probably make sense to also watch for the Clear Cache notification and forget the cached fonts in that case, too.
Just to be clear:
With "Shift-Reload" do you mean clicking the reload button while pressing Shift, Ctrl+F5, or both?

I mean whatever UI action triggers a "force-reload" operation, bypassing the usual http cache... Holding Shift while clicking the Reload button does this on OS X (and presumably on all platforms); I don't usually work on Windows, but it looks like Ctrl-F5 does the same there, so AFAIK either one would cause this patch to also bypass the webfont cache.
I think it also makes sense that the webfont cache should be included among the caches that are cleared by "Clear Recent History" if the Cache option is selected. So this patch adds a simple observer to handle this case.
Attachment #752231 - Flags: review?(roc)
Comment on attachment 752231 [details] [diff] [review]
pt 2 - empty the webfont cache in response to cacheservice:empty-cache notification

Review of attachment 752231 [details] [diff] [review]:

::: gfx/thebes/gfxUserFontSet.cpp
@@ +795,5 @@
> +        nsCOMPtr<nsIObserverService> obs =
> +            mozilla::services::GetObserverService();
> +        if (obs) {
> +            obs->AddObserver(new Flusher, NS_CACHESERVICE_EMPTYCACHE_TOPIC_ID,
> +                             false);

I think you need a matching RemoveObserver call somewhere or we leak.
Do we? I thought that this idiom would give the observer service the only reference to the observer, and it'd release it on shutdown. But if that's not correct, I'll fix it tomorrow. :)
I can now see the requests for web fonts again when pressing Ctrl+F5 or Shift+clicking the reload button. Thanks for that!

Though it seems setting browser.cache.disk.enable and browser.cache.memory.enable to false (i.e. disabling the browser cache) don't affect font caching. At least not constantly. Can you confirm that?

1. Opened in a new tab
2. Set the prefs mentioned above to false
3. Opened the Web Console (Ctrl+Shift+K)
4. Reloaded the page twice

=> There are no requests listed for the web fonts, while they should be there due to the browser cache being disabled.

Duplicate of this bug: 889226
You need to log in before you can comment on or make changes to this bug.