931752 - Webfonts are still cached when the browser cache is disabled

Status: UNCONFIRMED

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

Description

[Sebastian Zartner [:sebo]]

As described in comment 13 of bug 862222 platform instantiations of webfonts should not be cached when the browser cache is disabled.

1. Set browser.cache.disk.enable and browser.cache.memory.enable to false
2. Open https://getfirebug.com/ in a new tab
3. Open the Network panel of the DevTools (Ctrl+Shift+Q)
4. Click the "Fonts" filter
5. Reload the page (via F5)

=> The fonts https://getfirebug.com/fonts/TitilliumMaps26L001.woff and https://getfirebug.com/fonts/TitilliumMaps26L002.woff should be listed but they aren't.

Sebastian

Comment 1

[Honza Bambas (:mayhemer)]

Sebastian, are you testing with default settings (the old cache) or with the new cache (i.e. with browser.cache.use_new_backend at 1) ?

In the first case, this is WONTFIX.

In the letter case, this is known to not work - the preferences are not implemented (see bug 913820).

Also, I don't think that testing just with Firebug is the way to say there is a bug.  You should check about:cache rather.  And also don't forget to empty the cache before you do your testing.

Comment 2

[Jonathan Kew [:jfkthame]]

I'm not sure how relevant the browser cache backend setting or bug 913820 is here. The webfont cache from bug 816483 is on a different level altogether from HTTP caching.

But maybe it should also respect the browser.cache.memory.enable setting? Or maybe there should be a separate pref that controls whether the platform instantiations of webfonts can be cached and shared? (What's the use-case here for wanting to disable it? If it's purely for testing purposes, isn't the force-reload functionality from bug 862222 sufficient?)

Comment 3

[Honza Bambas (:mayhemer)]

(In reply to Jonathan Kew (:jfkthame) from comment #2)
> I'm not sure how relevant the browser cache backend setting or bug 913820 is
> here. The webfont cache from bug 816483 is on a different level altogether
> from HTTP caching.

I was not aware.

> 
> But maybe it should also respect the browser.cache.memory.enable setting? 

I don't think it should unless the web fonts are persisted.

> Or
> maybe there should be a separate pref that controls whether the platform
> instantiations of webfonts can be cached and shared? (What's the use-case
> here for wanting to disable it? If it's purely for testing purposes, isn't
> the force-reload functionality from bug 862222 sufficient?)

In my personal opinion, there should be a pref for everything, if possible.  However, existence of this bug itself show our preferences already are confusing enough.

Comment 4

[Sebastian Zartner [:sebo]]

(In reply to Honza Bambas (:mayhemer) from comment #3)
> > But maybe it should also respect the browser.cache.memory.enable setting? 
> 
> I don't think it should unless the web fonts are persisted.
To my knowledge they are. Jonathan, can you confirm that?

> > Or
> > maybe there should be a separate pref that controls whether the platform
> > instantiations of webfonts can be cached and shared? (What's the use-case
> > here for wanting to disable it? If it's purely for testing purposes, isn't
> > the force-reload functionality from bug 862222 sufficient?)
> 
> In my personal opinion, there should be a pref for everything, if possible. 
> However, existence of this bug itself show our preferences already are
> confusing enough.
The user case for Firebug users is surely for testing purposes. Other users may always want to get the latest version of a website. If the functionality of bug 862222 were enough, I wouldn't have created this issue. :-) People having the browser cache disabled expect the whole cache to be disabled, not just parts of it.
Because of this it would be logical to reuse the existing prefs mentioned above. Though for the Firebug Working Group it wouldn't be a problem, if there were an extra pref only controlling the fonts cache.

Sebastian

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to Sebastian Zartner from comment #4)
> (In reply to Honza Bambas (:mayhemer) from comment #3)
> > > But maybe it should also respect the browser.cache.memory.enable setting? 
> > 
> > I don't think it should unless the web fonts are persisted.
> To my knowledge they are. Jonathan, can you confirm that?

They aren't, assuming "persisted" means they persist from one browser session to the next.

> The user case for Firebug users is surely for testing purposes. Other users
> may always want to get the latest version of a website. If the functionality
> of bug 862222 were enough, I wouldn't have created this issue. :-) People
> having the browser cache disabled expect the whole cache to be disabled, not
> just parts of it.
> Because of this it would be logical to reuse the existing prefs mentioned
> above. Though for the Firebug Working Group it wouldn't be a problem, if
> there were an extra pref only controlling the fonts cache.

Currently fonts behave just like images. For an image with a given URL, we always reuse an already-loaded image with the same URL if there is one, regardless of prefs (AFAIK). Are images a problem for you?

Comment 6

[Sebastian Zartner [:sebo]]

> They aren't, assuming "persisted" means they persist from one browser session to the next.
Just checked using Wireshark on http://www.torbenleuschner.de/blog/601/html5-formulare-neue-input-types-attribute-und-mehr/ and there is no request to http://www.torbenleuschner.de/font/muli-light-webfont.woff after restarting the browser. So they obviously are persisted across browser sessions.

> Currently fonts behave just like images.
Not exactly. There's one request for an image when a page is loaded (independent of how often it is used within a page) while for fonts there isn't.

> Are images a problem for you?
No, for the reason mentioned above.

Sebastian

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to Sebastian Zartner from comment #6)
> > They aren't, assuming "persisted" means they persist from one browser session to the next.
> Just checked using Wireshark on
> http://www.torbenleuschner.de/blog/601/html5-formulare-neue-input-types-
> attribute-und-mehr/ and there is no request to
> http://www.torbenleuschner.de/font/muli-light-webfont.woff after restarting
> the browser. So they obviously are persisted across browser sessions.

That must be the Necko-level HTTP cache. The cache introduced in bug 816483 definitely does not persist across browser sessions.

Comment 8

[Honza Bambas (:mayhemer)]

If browser.cache.disk.enable = false would be broken for fonts, then it would be broken for anything.

Can please someone from QA confirm this bug?

Comment 9

[Jonathan Kew [:jfkthame]]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #7)
> (In reply to Sebastian Zartner from comment #6)
> > > They aren't, assuming "persisted" means they persist from one browser session to the next.
> > Just checked using Wireshark on
> > http://www.torbenleuschner.de/blog/601/html5-formulare-neue-input-types-
> > attribute-und-mehr/ and there is no request to
> > http://www.torbenleuschner.de/font/muli-light-webfont.woff after restarting
> > the browser. So they obviously are persisted across browser sessions.
> 
> That must be the Necko-level HTTP cache. The cache introduced in bug 816483
> definitely does not persist across browser sessions.

To expand on this a bit: the "webfont cache" is about caching and sharing the platform graphics system's instantiation of the downloaded font, which is private to the running application, and does not survive quitting the browser.

But quite separately from this, the normal Necko-level cache may have cached the raw downloaded resource, so that next time it's needed (if the instantiated platform font object has been discarded, certainly after a restart) it doesn't have to be re-fetched from the network.

Comment 10

[Sebastian Zartner [:sebo]]

(In reply to Jonathan Kew (:jfkthame) from comment #9)
> (In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #7)
> > (In reply to Sebastian Zartner from comment #6)
> > > > They aren't, assuming "persisted" means they persist from one browser session to the next.
> > > Just checked using Wireshark on
> > > http://www.torbenleuschner.de/blog/601/html5-formulare-neue-input-types-
> > > attribute-und-mehr/ and there is no request to
> > > http://www.torbenleuschner.de/font/muli-light-webfont.woff after restarting
> > > the browser. So they obviously are persisted across browser sessions.
> > 
> > That must be the Necko-level HTTP cache. The cache introduced in bug 816483
> > definitely does not persist across browser sessions.
> 
> To expand on this a bit: the "webfont cache" is about caching and sharing
> the platform graphics system's instantiation of the downloaded font, which
> is private to the running application, and does not survive quitting the
> browser.
> 
> But quite separately from this, the normal Necko-level cache may have cached
> the raw downloaded resource, so that next time it's needed (if the
> instantiated platform font object has been discarded, certainly after a
> restart) it doesn't have to be re-fetched from the network.

Need to correct myself. I didn't have browser.cache.disk.enable = false when doing the testing with Wireshark. When it's set to false there will be a request done after browser restart.

So to come back to the initial request: The "webfont cache" should respect the browser cache settings when reloading a website.

Sebastian

Comment 11

[Honza Bambas (:mayhemer)]

Dropping qawanted then.

IMO, the browser.cache.disk.enable is badly named.  It should be under network namespace, at least because it's a platform feature and not a browser specific feature.  Then, there should be a different preference for webfont cache to disable it (maybe there already is?)

For me: WONTFIX or INVALID.

Comment 12

[Sebastian Zartner [:sebo]]

> Then, there should be a different preference for webfont cache to disable it (maybe there already is?)

AFAIK there isn't. That's what this report is asking for.
Whether an existing pref is reused for this or a new one is introduced doesn't matter for us as long as we (the Firebug Working Group) get the possibility to disable webfont caching.

Sebastian

Comment 13

[Sebastian Zartner [:sebo]]

Shouldn't bug 1030718 be rather marked as a duplicate of this one? My first sentence on comment #0 indicates the same request.

Sebastian