All users were logged out of Bugzilla on October 13th, 2018
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 http://lukewagner.github.io/AngryBotsPacked/ with "Disable Cache (when toolbox is open)", then I see three XHRs in the logs. If I check out locally (https://github.com/lukewagner/AngryBotsPacked.git) 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.
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.
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?
The pref network.http.use-cache was removed in bug 1198387, fwiw. (This bug is about a different method of disabling the cache.)
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 http://codepen.io/anon/pen/VvpKLb for a remote one. The steps to reproduce, copied from my comment in bug https://bugzilla.mozilla.org/show_bug.cgi?id=1129806 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 (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.
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.
You need to log in before you can comment on or make changes to this bug.