1710373 - Network monitor doesn't show network requests for all cached content

Status: NEW

(DevTools :: Netmonitor, defect, P3)

Description

[julien]

Attachment: firefox-cache-issue.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:88.0) Gecko/20100101 Firefox/88.0

Steps to reproduce:

• Updated a CSS server side
• Refreshed the page, with the console opened, and "disable cache" not ticked

Actual results:

All assets are properly displayed and gets a proper "304 Not Modified" answer, but one of the asset (the first CSS) does not show on the network pane.

But If I go to "about:cache" I do see its "hit" being incremented.

Expected results:

I expected to see where the CSS were fetched from (the cache) and maybe why it was fetched from the cache.

It's probably a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=764958 which looks fixed.

It happen on https://docs.python.org/zh-cn/3.10/ for me now, but it probably depends on what I currently have in my cache, so I think it's not easy to reproduce.

See attached file where I don't have pydoctheme.css in the nework tab, while I have for example pygments.css which is served with the exact same headers and included in the HTML with the exact same syntax.

Comment 1

[julien]

More info: When I first hit the page the CSS gets "raced" by the cache, it's when I refresh the page that the "pydoctheme.css" don't show up.

Comment 2

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

The Bugbug bot thinks this bug should belong to the 'Core::Networking: HTTP' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 3

[Julian Descottes [:jdescottes]]

Hi Hubert!

If you want to try to reproduce this edit scenario using sjs files, here's an example from the current codebase:

• https://searchfox.org/mozilla-central/source/devtools/client/inspector/rules/test/sjs_imported_stylesheet_edit.sjs
• used in https://searchfox.org/mozilla-central/source/devtools/client/inspector/rules/test/browser_rules_imported_stylesheet_edit.js

The files are both heavily commented, but the tldr is that depending on the GET parameters sent to the sjs files, we return different responses.
Although the STRs seem really complex here, not sure it will be enough to reproduce the bug.

Comment 4

[Hubert Boma Manilla (:bomsy)]

Thanks for the info julian, really helpful

Ok so i seem to be able to reproduce this. I tried again with the python docs link

STR

1. Go to "https://docs.python.org/zh-cn/3.10/"
2. Open the netmonitor.
3. Make sure "Disable cache" is not ticked.
4. Reload the page

AR

The "pydoctheme.css?2021.5.dev" request is not on the list

ER

The "pydoctheme.css?2021.5.dev" request should be on the list

Hi Julien, Does this STR correctly represent the issue you are seeing?

Comment 5

[Hubert Boma Manilla (:bomsy)]

Attachment: Chrome.png

I also tried to test in chrome and it seems to show up. See screenshot

Comment 6

[Julien Palard]

Hi Hubert,

(In reply to Hubert Boma Manilla (:bomsy) from comment #4)

Hi Julien, Does this STR correctly represent the issue you are seeing?

Yes!!

I do understand this is can be controversial as the tab is named "Network" and there may be no network at all involved in getting this file (I don't know)...

But it's not easy to diagnose cache issues, for me at least, so when no information is displayed at all I'm a bit lost (I'm not a front-end dev at all, I read the RFC 7234, but I think some feedback from the browser would be great too).

« Explicit is better », like we say: if I can get a line telling me something like "this file was found in the cache, no validation has been done using the network because {clear_unambiguous_reason}." I think it would help.

Comment 7

[Hubert Boma Manilla (:bomsy)]

Thanks for the confirmation.

I think requests from the cache should to be shown.

Comment 8

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

Clear a needinfo that is pending on an inactive user.

For more information, please visit auto_nag documentation.

Comment 9

[Julian Descottes [:jdescottes]]

Will most likely be fixed via Bug 1916960