1293662 - Does the "disable cache while devtools are open" option affect file:/// loaded web pages?

Status: RESOLVED WORKSFORME

(DevTools :: General, defect, P2)

Description

[Soledad Penades [:sole] [:spenades]]

I am working on some simple static html that loads a CSS file, all opened with a file:/// url, and Firefox is very aggressively caching the CSS.

I tried using devtools option to 'disable cache' but I see no difference at all—the file keeps being cached and I have to force lots of refresh or wait until it whimsically decides to load the new version.

Using firefox nightly 20160808, on a Mac OS El capitan computer.

Comment 1

[Patrick Brosset <:pbro>]

As per the DevTools triage process doc [1], a P1 is defined as:
- a security hole
- causing data-loss
- causing a crash
- stopping the tools working
- embarrassing
Should be fixed within 24h and your manager should know about it and, between you, assign it to someone who can fix it.

This bug has been set as a P1 more than 2 months ago. It does sound like a P1 (an embarrassing problem where the tool says it would disable the cache but really doesn't).

So:
- either someone volunteers to fix this bug now,
- or we decide that it's not so urgent and demote it to P2.

Pinging Mike who, I think, knows about the cache disabling feature.

[1] https://docs.google.com/document/d/1uG0foc0pphXJB489_8ClKjYr1wbRXeFyrkd_kIOv9ao/edit#

Comment 2

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

All browsers cache file:/// urls, at least in the BFCache.

It took platform a while to get around to implementing the disable cache flag because they were working on cache2. Previous to their changes it was more of a "disable cache until the onload event is fired" option.

I know jfkthame worked on that, at least a little. Whoever worked on it should check why local files are still cached when disable cache is selected.

Comment 3

[Jonathan Kew [:jfkthame]]

(In reply to Michael Ratcliffe [:miker] [:mratcliffe] from comment #2)
> All browsers cache file:/// urls, at least in the BFCache.
> 
> It took platform a while to get around to implementing the disable cache
> flag because they were working on cache2. Previous to their changes it was
> more of a "disable cache until the onload event is fired" option.
> 
> I know jfkthame worked on that, at least a little. Whoever worked on it
> should check why local files are still cached when disable cache is selected.

I remember doing and/or reviewing some work related to bypassing the _downloadable font_ cache, which is a separate level from the general network cache. (Bug 1027579, bug 862222.)

But it sounds like _this_ bug is talking about other resources (such as stylesheets) being cached when loaded from file:/// URLs, not an issue with the @font-face cache.

I'm guessing this may be a necko-level caching issue, about which I know nothing, sorry.

Comment 4

[Jonathan Kew [:jfkthame]]

So I was a bit curious, and tried to reproduce this. But AFAICS it's not happening for me. I created a simple HTML file and an associated CSS file, both loaded locally via file:/// URLs. If I modify the CSS file and click the Reload button, the change takes effect as expected, without me having to do anything in particular to bypass/disable caching.

(Note that the option in devtools is "Disable HTTP cache...", so if that label is accurate, it wouldn't be expected to be relevant to file:/// URLs, as they're not loaded via HTTP. But as described above, I'm not seeing file:/// resources being cached anyway.)

:sole, maybe you could provide a complete example (e.g. an archive with HTML and CSS files to be extracted locally), with a description of the exact steps to reproduce the problem you're seeing?

Comment 5

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

Sole: I can't reproduce this either... can you provide a demo?

Comment 6

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

Filter on Brobdingnagian.

Comment 7

[Soledad Penades [:sole] [:spenades]]

I don't have an example handy. I'll close this and if it happens again I'll reopen.