1027122 - Fonts loaded from cache are missing from DevTools network tab

Status: REOPENED

(DevTools :: Netmonitor, defect, P3)

Description

[Jon Rimmer]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Firefox/32.0 (Beta/Release)
Build ID: 20140616004003

Steps to reproduce:

1. Navigate to a site using custom fonts and returns 304 for unmodified resources.
2. Open the DevTools.
3. Activate the network tab.
4. Reload the page.


Actual results:

Initial font requests will show up in the list with a 200 status response, but subsequent loads will not show any font request/response.


Expected results:

Font loads from the cache should be shown in the list with a 304 status response.

Comment 1

[Nickolay_Ponomarev]

Do you see the network requests *on the server*, though?

Looks like there is some weirdness around fonts caching, c.f. bug 931752 comment 9 and bug 1021750.

Comment 2

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Yes, this is long standing bug, would finally deserve to be fixed.
Honza

Comment 3

[Jan Honza Odvarko [:Honza] (always need-info? me)]

I am trying to reproduce this issue with the following STR:

1. Load https://www.coca-cola.co.uk/stories/history/advertising/the-logo-story
2. Open the DevTools.
3. Activate the network tab, select the 'Fonts' filter
4. Reload the page.
5. You should see requests for custom fonts.

@jon: does this bug still exists for you? It seems to be working for me now.
(using Firefox Nightly 65)

Honza

Comment 4

[Jan Honza Odvarko [:Honza] (always need-info? me)]

I am able to reproduce the problem using the following STR:

1. Load https://www.coca-cola.co.uk/stories/history/advertising/the-logo-story
2. Open the DevTools.
3. Activate the network tab, select the 'Fonts' filter
4. Reload the page.
5. Initial font requests will show up, but they are not there if the page is reloaded

If the Disable Cache is selected font requests are back.

Honza

Comment 5

[Jan Honza Odvarko [:Honza] (always need-info? me)]

@Valentin: it looks like that when loading the page for the first time font requests have cause type "font" and when reloading some of them have cause type "stylesheet" and some of the request slooks like the are loaded directly from the cache and there is no HTTP event. I am not event seeing http-on-examine-cached-response events.

Is this expected behavior?

Honza

Comment 6

[Valentin Gosu [:valentin] (he/him)]

(In reply to Jan Honza Odvarko [:Honza] (always need-info? me) from comment #5)

@Valentin: it looks like that when loading the page for the first time font requests have cause type "font" and when reloading some of them have cause type "stylesheet" and some of the request slooks like the are loaded directly from the cache and there is no HTTP event. I am not event seeing http-on-examine-cached-response events.
Is this expected behavior?

I am not sure exactly how fonts are loaded through Necko.
From what I can see we have a FontCache in GFX, and Anne tells me that the caching goes through DOM/layout somehow.
Let's see if Jonathan can provide some insight here.

Comment 7

[Jonathan Kew [:jfkthame]]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #6)

From what I can see we have a FontCache in GFX,

That's not the cache you're looking for...

Let's see if Jonathan can provide some insight here.

I think what's relevant here is the gfxUserFontSet::UserFontCache, which sits above any necko-level caching and directly returns ready-to-use platform font instances to gfx without re-requesting resources from the network layer. This is important for page-load/reflow performance when the same font resource is reused across multiple pages of a site, but it means that if the same resource is used repeatedly (by the same site), you won't see fresh network requests each time for fonts that are already cached at this level.

Simply re-fetching the resources from a networking-level cache would be significantly less performant because we'd still pay the cost of re-analyzing the resource and instantiating a new platform font instance.

I suppose if this is considered a bug, we could fire off the network request, and if we get back a 304 Not Modified response, then check if there's an already-instantiated font in the UserFontCache. I'd be concerned this still adds extra overhead/latency, though, especially if the network layer is busy with other requests and may take some time to even respond with 304.

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

A needinfo is requested from the reporter, however, the reporter is inactive on Bugzilla. Closing the bug as incomplete.

For more information, please visit auto_nag documentation.

Comment 10

[Jan Honza Odvarko [:Honza] (always need-info? me)]

I can still repro on my machine using STRs from comment #4

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Honza, the patch on bug 1814961 landed earlier today and the latest Firefox Nightly build contains the fix. Would you mind checking if you can still reproduce the problem?

Comment 12

[Jan Honza Odvarko [:Honza] (always need-info? me)]

I can still repro the issue.

I believe that the comment #7 explains the state accuratelly. The font is loaded from gfxUserFontSet::UserFontCache, which represents another cache (for optimization) and so, we don't see any network not browser cache activity.