1534434 - Checking "disable cache" in the devtools network panel causes inappropriate view-source caching

Status: NEW

(Core :: Networking: Cache, defect, P3)

Description

[David Flanagan [:djf]]

When "disable cache" is checked in the devtools network panel, I'm finding that typing Cmd-U to view source is showing me an old version of my page, and the source I'm seeing is not in sync with what is being displayed in the devtools inspector panel. This caused me to lose an hour or two in debugging time because I thought that my server was not sending updated content when I edited the template files when in fact the problem was that Firefox was showing me old versions of the source.

I'm using macOS. I've reproduced this in Firefox (65) and Nightly (67). I'm not sure I've got the component set correctly; please fix it if I'm wrong.

Steps to reproduce:

1. Start a local static webserver. (I don't see the bug with file: URLs). This is what I did: cd tmp; python -m SimpleHTTPServer 1234

2. Create a file /tmp/foo.html to serve with the webserver. Make the content of the file "foo"

3. Open the file in firefox: localhost:1234/foo.html

4. Open dev tools, click on the network panel, click "Disable cache"

5. Type Cmd+U (on Mac, anyway) to view source and see the source "foo".

6. Modify the contents of the foo.html file so that it contains the text "bar"

7. In the original tab, type Cmd+R to reload, see that the displayed text changes to bar

8. Type Cmd+U again to view source. Notice that the source still reads "foo". This is the bug. The source has been updated, but I'm seeing the old source. (If I type Cmd+R in the view-source tab, it does correctly update, but I should not have to do that)

If you repeat those steps without checking the "disable cache" checkbox, then the bug does not occur. So somehow, strangely, turning off a cache in the network panel seems to enable some kind of caching for view source.

Comment 1

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Thanks for the report, I can see the bug on my machine (Win10) too.

Honza

Comment 2

[Jan Honza Odvarko [:Honza] (always need-info? me)]

@Mike, I remember that you were working on disable-cache feature. Do you know what could be the problem here?
Honza

Comment 3

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

I investigated this for a while and then realized that it is working correctly.

Disable cache only disables the cache for the current tab and it only does that whilst the toolbox is open. View source is opened in a new tab so the source will come from the cache.

Comment 4

[Jan Honza Odvarko [:Honza] (always need-info? me)]

(In reply to Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe] from comment #3)

I investigated this for a while and then realized that it is working correctly.

Disable cache only disables the cache for the current tab and it only does that whilst the toolbox is open. View source is opened in a new tab so the source will come from the cache.

Thanks Mike for the analysis!

If the cache is disabled for the current tab only and view source is opened in a new tab - why view-source is cached when turning off the cache in the Net panel? And, view-source works fine when caching is on - i.e. "Disable cache" checkbox not checked. That doesn't feel correct. Could that indicate a platform issue?

Honza

Comment 5

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

(In reply to Jan Honza Odvarko [:Honza] (always need-info? me) from comment #4)

If the cache is disabled for the current tab only and view source is opened in a new tab - why view-source is cached when turning off the cache in the Net panel? And, view-source works fine when caching is on - i.e. "Disable cache" checkbox not checked. That doesn't feel correct. Could that indicate a platform issue?

Absolutely... this is how we disable the cache for the current tab:

/**
 * Disable or enable the cache via docShell.
 */
_setCacheDisabled(disabled) {
  const enable = Ci.nsIRequest.LOAD_NORMAL;
  const disable = Ci.nsIRequest.LOAD_BYPASS_CACHE |
                Ci.nsIRequest.INHIBIT_CACHING;

  this.docShell.defaultLoadFlags = disabled ? disable : enable;
}

https://searchfox.org/mozilla-central/source/devtools/server/actors/targets/browsing-context.js#1087-1096

That certainly shouldn't affect the view source window.

@Honza B. Seems like this must be a platform issue.

Comment 6

[Jan Honza Odvarko [:Honza] (always need-info? me)]

@Mike: thanks for triaging this!

Honza

Comment 7

[Honza Bambas (:mayhemer)]

The tab (=docshell) with devtools open and "disable cache" checked just changes the load flags for this tab (=docshell). ctrl-U (win) will open a completely new window with viewsource:http://..., it won't even touch any devtools hooks.

When channels (being triggered as part of the docshell = tab) are set those exact flags, we don't touch (delete) the cache entries, they remain possibly usable in the cache. Normal loads, which viewsource is as well, will look those cache entries up and will find them.

So, as I understand the frustration and somewhat unexpected behavior for those who don't know these details (who would know, right? :)) I can see following possibilities for a fix:

• (complicated) somehow propagate the loadflags on the newly open viewsource: tab; this would have to happen somehow via some kind of window open hook in devtools (no idea if something like this is possible) and pass the caching set of default load flags on to that window's docshell; this would not change the current future loads behavior

• (simple) don't set the INHIBIT_CACHING flag to just overwrite existing cache entries when a page is reloaded with devtools[disable cache=true]; this would effect future loads, but I don't think that would be a problem (unless I'm missing some definition of how the disable cache feature has to work and why that flag has been put there at the beginning)

The simple solution will make us end up here:
https://searchfox.org/mozilla-central/rev/4763b8d576ce52625d245d1ab6d9404ea025b026/netwerk/protocol/http/nsHttpChannel.cpp#3857-3858

which reloads and rewrites any existing cache entries.

Comment 8

[Kershaw Chang [:kershaw]]

:Honza, the priority of this bug is P3, which is set by you.
In necko team, P3 bugs are our backlog list. If you think this is important to fix, feel free to adjust the priority.

Comment 9

[Jan Honza Odvarko [:Honza] (always need-info? me)]

(In reply to Kershaw Chang [:kershaw] from comment #8)

:Honza, the priority of this bug is P3, which is set by you.
In necko team, P3 bugs are our backlog list. If you think this is important to fix, feel free to adjust the priority.

Thanks for heads up! I am changing to P2 since this behavior is frustrating and the simple solution suggested by : mayhemer sounds like a good plan.

Honza

Comment 10

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

@mayhemer From memory I am pretty sure that INHIBIT_CACHING was needed to stop XHR results from coming from the cache... can you clarify this?

Comment 11

[Honza Bambas (:mayhemer)]

(In reply to Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe] from comment #10)

@mayhemer From memory I am pretty sure that INHIBIT_CACHING was needed to stop XHR results from coming from the cache... can you clarify this?

I don't think so. INHIBIT_CACHING prevents rewrite of anything pre-existing in the cache, nothing else.