All users were logged out of Bugzilla on October 13th, 2018

"Disable Cache (when toolbox is open)" option doesn't always work for localhost



4 years ago
4 months ago


(Reporter: luke, Unassigned)



Firefox Tracking Flags

(firefox40 affected)



(1 attachment)



4 years ago
When serving a webapp from localhost addresses (using 'python -m SimpleHTTPServer'), it appears that "Disable Cache (when toolbox is open)" isn't prevent caching of all resources (confirmed by the network panel and SimpleHTTPServer's output).  When the same app is served from a remote address, caching is correctly disabled by this option.  Setting network.http.use-cache=false also correctly inhibits caching in the localhost case, so the problem seems somewhat specific to this devtools option.

As an example, if I visit with "Disable Cache (when toolbox is open)", then I see three XHRs in the logs.  If I check out locally ( and serve by running 'python -m SimpleHTTPServer' in the root dir, then after the second load, I only see one XHR in the logs.  Setting network.http.use-cache=false goes back to three XHRs in the logs.

What's weird is that *some* of the resources are re-fetched when this option is set, just not all of them.
Is it just XHRs that are misbehaving or other request types too?  There is bug 1027579 to help DevTools "really" disable cache for more request types, maybe this is a dupe of that.
Flags: needinfo?(luke)
I do think that the distinction between local vs. remote pages is new info though, I've not seen that mentioned in other bugs before.

Comment 3

4 years ago
No, in one case (AngryBots-glue.js) I'm seeing a normal script load getting cached.

Another piece of info: it seems like different files are cached each time (specifically some subset of AngryBots-asm.packed.js, AngryBots-glue.js, and AngryBots-mem.js).  These are the last files loaded (a few seconds after initial load.  All the tiny resources loaded at the beginning are never cached.  Is there anything timing dependent about this feature?
Flags: needinfo?(luke)

Comment 4

3 years ago
The pref network.http.use-cache was removed in bug 1198387, fwiw. (This bug is about a different method of disabling the cache.)

Comment 5

3 years ago
Created attachment 8668966 [details]
Video tag test case

I confirm that "Disable Cache (when toolbox is open)" isn't working with the video sources of a video tag. However, I'm seeing the same behavior both when hosting index.html locally and remotely.
See the attached file for a local version and for a remote one.

The steps to reproduce, copied from my comment in bug

1. Open a new tab, go to the debug menu (f12).
2. Go to media tab in network monitor.
3. Load (or a locally hosted version - see note at the bottom)

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.

Note: testing it locally will never show the video file being requested, because you can't open the dev tools before the first time you visit the url. You can open the dev tools, enter a remote url and see the first request, but if the url is local, the dev tools window will close. This is probably another bug, and I don't know if it's been reported. Anyway, I checked with fiddler that it's requesting the video the first time, just like it happens the remote url. I also use fiddler to confirm it wasn't just a visual bug in the dev tools. It's actually being cached, the GET request is never sent.

Comment 6

3 years ago
Ignore what I said about the dev tools closing only with local urls. It always happens.
In order to see the first request, you need to:

1. Open a new tab
2. Open a random webpage, like google.
3. Open the tools with f12.
4. In the same tab, open the url of the test case (remote or local, it doesn't matter)

...or just use fiddler.


4 months ago
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.