1129806 - (netmonitor-cache) [meta] Browser Cache

Status: NEW

(DevTools :: Netmonitor, task)

Description

[Nitin]

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.

Comment 1

[Nitin]

http://stackoverflow.com/questions/27508114/disable-cache-option-in-developer-tools-doesnt-work

Comment 2

[Michael]

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.

Comment 3

[Michael]

Attachment: index.html

Example

Comment 4

[Michael]

Attachment: app.js

Example

Comment 5

[Michael]

Attachment: header.tpl.html

Example

Comment 6

[Michael]

Attachment: navigation.tpl.html

Example

Comment 7

[Michael]

Attachment: dashboard.tpl.html

Example

Comment 8

[Michael]

^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.

Comment 9

[Nicolas Frandeboeuf]

I can confirm this issue : even by checking it, the requests panel clearly still displays "cached" for several of my files.

Comment 10

[eric.sirianni]

+1

This bug makes it impossible to do any sort of real web development in Firefox.

Comment 11

[danilofcestari]

+1

I love Firefox, but due to this (and others like 978866) I'm forced to ditch FF and use Chrome.

Comment 12

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

I assume Angular is loading these templates with XHR requests?

The first step to progress is resolving bug 1027579.

Comment 13

[eric.sirianni]

My (non-angular) app uses requirejs which loads scripts with XHR requests.  So yes, it appears that the root cause is bug 1027579.

Comment 14

[danilofcestari]

Hmm I'm using RequireJS here as well. So I guess that solving bug 1027579 would make sense.

Comment 15

[Fernando Gutiérrez]

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 http://codepen.io/anon/pen/VvpKLb

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.

Comment 16

[Fernando Gutiérrez]

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.

Comment 17

[Fernando Gutiérrez]

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.

Comment 18

[Tactical Freak]

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... :/

Comment 19

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

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.

Comment 20

[Tactical Freak]

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.

Comment 21

[Fernando Gutiérrez]

I can confirm videos (in this case .webm) are still being cached in version 43.0a2

Comment 22

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

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)

Comment 23

[Patrick Brosset <:pbro>]

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).

Comment 24

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

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.

Comment 25

[Bryan Clark (DevTools PM) [:clarkbw]]

When we turn our focus to polish again I would set this as a P1.  It is a core requirement.