Open Bug 1129806 (netmonitor-cache) Opened 6 years ago Updated 2 months ago

[meta] Cache Tooling


(DevTools :: Netmonitor, task)

37 Branch
Not set


(Not tracked)


(Reporter: nitin.cool4urchat, Unassigned)


(Depends on 27 open bugs)


(Keywords: meta, Whiteboard: [polish-backlog])


(5 files)

523 bytes, text/html
985 bytes, application/javascript
138 bytes, text/html
186 bytes, text/html
97 bytes, text/html
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.93 Safari/537.36

Steps to reproduce:

1. Open Firefox Developer Edition
2. Press F12 or open developer settings
3. Click on gear icon on the top-right to see the Toolbox Options
4. Under "Advanced Settings", check "Disable Cache (when toolbox is open)"
5. Refresh the site, the changes made are not reflected. Files are still picked up from cache, changes are picked up perfectly fine in Chrome when cache is disabled.

Actual results:

The changes made in site are not reflected even though "Disable Cache" is checked and ToolBox is open.

Expected results:

The changes should be reflected and files should not be picked from cache.
Component: Untriaged → Developer Tools
Found this today too.  Attached AngularJS application example.  navigation.tpl.html will load once from server and then continually through cache with an 304 return code.

Even with "Disable Cache (when toolbox is open)" up checked, the navigiation.tpl.html file will never update when the file has been updated on server side.  Cache must be cleared.

index.html creates header.tpl.html request and header.tpl.html creates navigation.tpl.html request.
Attached file index.html
Attached file app.js
Attached file header.tpl.html
Attached file navigation.tpl.html
Attached file dashboard.tpl.html
^Even with "Disable Cache (when toolbox is open)" un checked, the navigiation.tpl.html file will never update when the file has been updated on server side.  Cache must be cleared.
I assume Angular is loading these templates with XHR requests?

The first step to progress is resolving bug 1027579.
Depends on: 1027579
My (non-angular) app uses requirejs which loads scripts with XHR requests.  So yes, it appears that the root cause is bug 1027579.
Hmm I'm using RequireJS here as well. So I guess that solving bug 1027579 would make sense.
Videos are also ignoring the "disable cache (when toolbox is open)".

1. Open a new tab, go to the debug menu (f12).
2. Go to media tab in network monitor.
3. Load

You will see a GET with type webm.

Push f5 and it will disappear. The only way to make it show up again is closing the tab and doing this again. This usually works, but not always. For example, it won't work if you already have the same url in a different tab. There are probably other corner cases, because I've noticed sometimes it doesn't work when it should.
I forgot to say that in order to see the first request (the only one where the video is downloaded) you need to open a new tab and then open a random webpage, like google. Then you can open the tools with f12, and after that you are ready to paste the test case url and observe the first time it loads.

If you just open the dev tools in a new tab, before loading any urls, the tools will close as soon as you try to load a webpage, and you won't be able to observe the first load. You can also ignore all this and use something external like fiddler. It's also useful to make sure the requests are actually being served from the cache. It's not a visual bug.
I said you couldn't have another tab with the same url if you wanted to see the first load not hitting the cache. It seems it's more generic. If the same video file (I suppose the same will happen with other kinds of files?) is already being displayed in another tab, even if it's a different webpage, it will always be loaded from the cache. Even the first time you load a different webpage. You need to close all the instances of the file, and then it will ignore the cache the first time it loads.
Yep, it has been more than one year that I have this issue.

At work we use Chrome, and it works fine.
But when I do work from home, I like to use my own FF...

But I still see 'cached' from the network pane, even though the cache is supposedly disabled when the toolbox is open. It just doesn't work.
The only workaround I've found is to use the add-on 'Empty Cache Button' which I bound to CTRL+R using another add-on named 'Customizable Shortcuts'.
Yes, I went through all these troubles...

I am now the only one at the office that is still using FF: my devs coworkers just dumped FF for Chrome which is so nice to code with. And then as a result our apps are less tested on FF, performance is not as good as with Chrome as a result, and also our CSS is more 'fragile' in FF... well everything is less good in other words.

Which also make the experience for our customers less good with FF, which will also deter people to use FF on the long run. Even my coworkers use Chrome in their personal life now as a result.

I'm not sure the FF dev team realizes how deep the impact of this bugged mandatory feature is.
--> If devs can't use FF to dev webapps, do you expect end-users to have a smooth experience on these same webapps, and the end-users to use FF as well on the long run?

Just because of that little issue. Just because no one can work and do web-development properly with Firefox.
I'm the last one still using FF at work, and I'm seriously considering Chrome now... :/
Can you re-test in Dev. Edition 43 or Nightly 44?

Bug 1027579 landed in 43, so it should have resolved this, at least in some situations.  If there are still more cases remaining, we need to track those down and fix them.
Ever confirmed: true
Flags: needinfo?(RedKage)
I just tried with the Developper edition 43.0a2.
And... I'm not sure.
There are no more 'cached' XHR requests from the network tab, and the data is refreshed properly.
So, it seems to work. Something changed anyway.

But... it does always this. That is, even when the inspector is not opened, or even with the 'disable cache' option is unchecked.

So I'm not sure, maybe that's normal behavior since my code doesn't send any cache header.
But the previous versions were still saving these files in cache though.

The file I'm testing with is a JSON that I grab using a jQuery Ajax GET.
Flags: needinfo?(RedKage)
I can confirm videos (in this case .webm) are still being cached in version 43.0a2
Priority: -- → P1
Whiteboard: [polish-backlog]
Converting this to a meta-bug to track all remaining issues with disable cache.  We'll need to test each file type and request as exhaustively as we can, to be sure all code paths are covered.  As the comments here and in other bugs show, there's still work to be done.

I am hoping to look into this soon.  In the mean time, if people see issues with specific request types or file types **when testing with Nightly to ensure you have the latest code**, please let us know here.

So far, the main issues I've heard are:

* XHR requests (may or may not be fixed after bug 1027579)
* SWF files (bug 1218635)
Depends on: 1218635
Keywords: meta
OS: Windows 8.1 → All
Hardware: x86_64 → All
Summary: Disable cache option in developer tools doesn't work → [meta] Disable cache option in developer tools doesn't work
Triaging. Was marked as P1 as part of a polish backlog 6 months ago, but not actively being worked on and not a P1 anymore according to our new triage process (filter on CLIMBING SHOES).
Priority: P1 → P3
I would at least keep this as a P2.  It's really pretty embarrassing / terrible / etc. if disable cache works "sometimes".  I would even say P1, but not sure who could drop things and focus on it.
Priority: P3 → P2
When we turn our focus to polish again I would set this as a P1.  It is a core requirement.
Duplicate of this bug: 1277514
Product: Firefox → DevTools
Type: defect → task
Component: General → Netmonitor
Priority: P2 → --
Summary: [meta] Disable cache option in developer tools doesn't work → [meta] Cache Tooling
Alias: dt-disable-cache → netmonitor-cache
Depends on: 1616950
You need to log in before you can comment on or make changes to this bug.