973730 - "Disable cache" isn't working in Nightly 30

Status: RESOLVED INVALID

(DevTools :: General, defect)

Description

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

https://twitter.com/m_hughes/status/435489969616846848

> 'Disable Cache' not working in latest nighty. All my responses come back as 304.

Comment 2

[Matt Hughes]

Steps to reproduce:

- Using nightly
- Open nytimes.com
- Open dev tools
- Open preferences
- Click disable cache
- This refreshes the page
- Refresh again
- Note 304 cached requests in Network inspector (chartbeat.js at the least has 304 response)

Comment 3

[Matt Hughes]

I can't really see the pattern, but some requests have:

Pragma: 'no-cache'
Cache-Control: 'no-cache'

set, but not all requests.  Maybe XHR requests aren't getting the cache control treatment? Conversely, the requests that don't have those flags set do have If-None-Match headers in the request.

GMail seems to be a good example of more problems than nytimes.com.

Comment 4

[Honza Bambas (:mayhemer)]

We recently didn't change much around the new HTTP cache v2 and its API usage around the platform.

Can you please find the regression range when this started to break?

Comment 5

[Honza Bambas (:mayhemer)]

Cannot reproduce with the latest m-c debug build, clean profile.  No 304 in the console. Did:

clean profile
http://www.nytimes.com/, so that it's cached now
F12, clean the console, leave only Network on to avoid bloat
Preferences
"Disable Cache" checked -> page reloads
Inspecting console shows no 304 responses


Tested for both the old cache and the new cache.

Comment 6

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

I was able to reproduce the issue on both Mac and Win 7, on the latest nightly, by using steps from comment 2 and comment 5: I always get a 304 response for chartbeat.js after selecting "Disable Cache" for http://www.nytimes.com/.

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Firefox/31.0
Build ID: 20140318030202

The issue seems to have been there since the option was introduced on December 19th:
Last good revision: 862cb6a1cc88 (2013-12-18)
First bad revision: 5c7fa2bfea8b (2013-12-19)
Pushlog: 
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=862cb6a1cc88&tochange=5c7fa2bfea8b

Also, I noticed that with "network.http.use-cache" set to "false", I can get a lot of 304 responses on each reload of the page. This behavior changed in September:
Last good revision: 8f8a683dfc42 (2013-09-20)
First bad revision: a2c31dc69ab3 (2013-09-21)
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8f8a683dfc42&tochange=a2c31dc69ab3

Comment 7

[Honza Bambas (:mayhemer)]

(In reply to Florin Mezei, QA [:FlorinMezei] from comment #6)
> Also, I noticed that with "network.http.use-cache" set to "false", I can get
> a lot of 304 responses on each reload of the page. This behavior changed in
> September:

Filed bug 984994.

Comment 8

[Honza Bambas (:mayhemer)]

For this bug (I can confirm it!), seems like at [1] LOAD_BYPASS_CACHE is not propagated to all loads from the docshell.  chartbeat.js may be loaded by a subframe or by xhr where the load flags are not propagated.


[1] http://hg.mozilla.org/mozilla-central/annotate/082761b7bc54/toolkit/devtools/server/actors/webbrowser.js#l821

Comment 9

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

Filter on 1ff0543e-b501-4893-a72b-e4773c01e655

Comment 10

[Sebastian Zartner [:sebo]]

I can't reproduce this on Nightly 45.0a1 (2015-11-10). Nick, do you still see this issue?

Sebastian

Comment 11

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

I never saw the issue, only filed for someone else who complained on twitter.

Comment 12

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

Let's check with Matt to see if they can still reproduce.

Comment 13

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

Not enough info to reproduce.  Please reopen if more info becomes available.