New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 44122 link

Starred by 91 users

Issue metadata

Status: Duplicate
Merged: issue 94090
Owner:
Last visit > 30 days ago
Closed: Jan 2013
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

Chrome Forced Refresh does not ignore cache

Reported by archaic....@gmail.com, May 13 2010

Issue description

Chrome Version       : <Copy from: 'about:version'>
URLs (if applicable) : Many
Other browsers tested: Firefox, Safari, IE7, IE8
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 4: OK
  Firefox 3.x: OK
         IE 7: OK
         IE 8: OK

What steps will reproduce the problem?
1. View a webpage
2. Update some of the css (for example an div's background image)
3. Refresh the page (Shift-F5, or CTRL-F5 both do not work)

What is the expected result?
The cache is ignored

What happens instead?
The opposite

Please provide any additional information below. Attach a screenshot if
possible.

 
chrome.JPG
120 KB View Download
firefox.JPG
123 KB View Download
Sorry, chrome version 5.0.375.38 beta

Comment 2 by evan@chromium.org, Jun 7 2010

Can you attach a test case?

Comment 3 by kapa...@gmail.com, Nov 24 2010

Chrome v7.0.517.44 does the same.
Shift + F5 should reload the page ignoring cache, but it doesn't.
For example :
if a webmaster replaces a swf file by a new one on his site, Chrome will go on showing the old one, and won't show the new until we manually clear his cache.

Comment 4 by jrso...@gmail.com, Apr 15 2011

This is still a problem in Chrome 10.0.648.204

Simply web developers require regular refreshing of the page they are working on. As described in the original report all other browsers have a method of refreshing that forces a new call to the web server instead of relying on the local cache. Google's Chrome browser does not. The only way to do this is to completely clear the cache which takes too long just to check a single web page.

Due to this reason I cannot use Chrome in development of a web site. This problem has been identified almost three years ago and it still has not been addressed by the Chrome team.

Comment 5 Deleted

Comment 6 by samh1...@gmail.com, May 19 2011

Apparently this is fixed, not sure when, but I'm on 11.0.696.68 (Official Build 84545) and Ctrl-clicking the reload button reloads while dumping the cache.
I'm still getting this in Chrome 15.0.874.106.

When developing a site I make a CSS change and hit refresh and the CSS change is not visible.

Initially the problem did not occur all the time. Sometimes holding ctrl and clicking refresh would perform the full refresh, but sometimes I would have to ctrl+click several times before my site changes were picked up. 

I then added a cookie to my site (created server side) and now there is no way to force a refresh at all, nothing works except going into Chrome settings and manually clearing the cache.

(I have also tried shift+click refresh, ctrl+f5 and shift+f5)

Comment 8 by oshe...@gmail.com, Jan 17 2012

Using 17.0.963.33 (Developer Build 0 Linux), ctrl-f5 did not force refresh, neither did ctrl+click refresh, but shift-f5 did.
I use force-refresh many times a day. It works for my development, but it fails sometimes when I use it to load my development environment (Orion web ide). The IDE developers believe this is Chrome bug.

As I look around there are lots of reports of force-refresh fails, followed by a equal number of requests for test cases.  Here I am thinking out loud to fish for ideas.

I guess there is a subtle issue that makes the force-refresh work most of the time, but fail in some cases. I guess developers who see the failure don't know what to look for in a test case.

In addition, reproducing the problem is a challenge since you will have to set up the cache before trying force-refresh. This setup involves values (headers, timestamps, browser settings, previous browser history) that are not directly available to developers who see the force-refresh failures. 

Another bug has a link to hints on reporting such bugs:
http://www.chromium.org/for-testers/providing-network-details
Is there even an equivalent keystroke on the Mac? I haven't been able to get Chrome to reload the page ignoring the cache ever, let alone "most of the time". This is the one thing that is keeping me on Safari for my web development and frankly I'd much rather be using Chrome.

Comment 11 by Deleted ...@, Apr 11 2012

You can of course just open up the development console panel and disable the cache:


Screen Shot 2012-04-11 at 3.26.45 PM.png
8.6 KB View Download

Comment 12 by esp...@gmail.com, Apr 11 2012

@GJ Yes, that does work. It's what I've been doing.

It will only continue to work while you leave that panel open though, which is easy to forget when wondering where your changes went.

I've been hitting this alot with javascsript assets that i'm changing in development..

I change a Javascript file, but the code Chrome is using remains the same until I completely close out the browser...

Comment 14 by Deleted ...@, Apr 24 2012

Occurs with images as well. Editing some images on our embedded device and force refreshing the page does not reload the image and requires the cache to be emptied or Incognito.
I've this error, and it's really horrible for development.

In my case it's a JS file loaded in a website hosted locally(in IIS)

Version: 18.0.1025.168 m
Getting the same type of behavior. I can reload the .js and notice the changes, but Chrome still uses an old version, no matter how many refreshes (ctrl+f5 and shift+f5 do nothing).

Using 18.0.1025.162 m.
I am experiencing this issue with 19.0.1084.52 m

Comment 18 by vini...@gmail.com, Jun 4 2012

I have the same annoying problem. Chrome version is 19.0.1084.52 m.

I have to clear the cache manually to workaround it.
I have hit Shift + F5 at least twice for refreshing regular .js <script>'s. It's the same for localhost and normal host resources. 19.0.1084.52 m on Win 7. Also nearly all of my friends who are using Chrome report the same issue. Please change the type of this issue from "bug" to "feature" if this is not going to change.
After two years, still same problem in version 19.0.1084.52 m! Chrome doesn't refresh SVG objects. Workaround for the frustrated web developers: you can use incognito mode, in which Chrome doesn't use cache.
I really don't understand why this isn't a priority. With this not fixed, Chrome is basically forcing developers to use anything other than Chrome. Other browsers (even IE!) properly dump cache when you ask for a forced-refresh.

For the love of development please fix.
Cmd-Shift-R (hard refresh) usually works for me, but occasionally I still find that I have to clear the cache (inspecting resources in the panel confirms that they are out of date). Can't reliably reproduce it.

Chrome 19.0.1084.56
Oh, by the way there are other solutions for refreshing CSS without even hitting F5 once. Two examples are: the Pendule extension (STYLE SHEETS > Reload CSS) and the CSS Reloader extension (haven't tried this one out).

Comment 24 by Deleted ...@, Jun 25 2012

This is a big issue for me. Its hard to believe something so important hasn't been fixed after all of this time. 

Comment 25 by asp...@gmail.com, Jul 10 2012

The same issue with v 22.0.1201.0 dev-m. Please fix it!

Comment 26 by Deleted ...@, Jul 20 2012

Same issue with v 20.0.1132.57. Please fix. I can't wait to go back to developing in chrome once this is fixed!
Project Member

Comment 27 by bugdroid1@chromium.org, Aug 10 2012

Labels: -Pri-2 Pri-3 Action-NeedsReview
Status: IceBox
Due to the age of the issue, changing the priority to P3, however because it has at least 10 stars, marking it for review.

Comment 28 by laforge@google.com, Aug 10 2012

Status: Unconfirmed
Same issue on chromeframe/21.0.1180.75. on both IE7 and 8.

Another curious thing: if you've got resources hosted elsewhere, on a secondary domain or CDN, when you've hit the page once (that is; when the resources has been cached - HTTP 304) it takes a good two minutes for those "cached" resources to load -- is anyone else experiencing this?

Comment 30 by Deleted ...@, Sep 10 2012

This is super annoying. Working on CSS and chrome refuses to clear the cache. Makes dev such a pain. I don't want to vote for this because I don't want any email telling me that what should have never been an issue is no longer an issue. Just please fix this. This browser does most things extremely well and then some things that just make me scratch my bald head.  I want to rant so bad right now...

Comment 31 by Deleted ...@, Sep 19 2012

I've found someone complaining about this bug in a forum in Apr 2009. It was reported here in May 2010. It's now Sep 2012, and it's still not fixed!

I have a page with a "script" element that points to an external JavaScript file "shopping_test.js" through the src attribute of the script element. If I edit "shopping_test.js" in Adobe Dreamweaver and upload the modified version of the file, and then refresh the page in Google Chrome using Ctrl + F5, the page responds as if the modifications have not been made. I can verify that the modified version of the file is online by right-clicking on the page, selecting "View page source", and then clicking on the link to the JavaScript file in the source code. But once I have done that, the problem goes away, because Google Chrome loads the current version of the JavaScript file when I click through to it. This proves that Google Chrome has the ability to load the current version, ignoring the cache; it just doesn't bring this ability into play when I press Ctrl + F5.

My version of Google Chrome is: 21.0.1180.89 m

Comment 32 by sr...@simmgene.com, Sep 20 2012

Wow just found this bug report, and I can testify that it's still present.

Is google claiming this isn't an issue or what?

Comment 33 by gros...@gmail.com, Sep 21 2012

I'm running into this issue on a wiki page where I updated an image by uploading a new version but the inline image on the wiki page is just not showing the new contents, despite me verifying that the image was uploaded correctly.  FWIW, the wiki is MediaWiki-based.

Comment 34 by ad...@wescook.ca, Oct 5 2012

I find Chrome will sometimes not refresh the cache unless I hit ctrl+f5 twice.  You can tell the first load is instant and on the second load all the images/css is redownloading.  This issue has been in Chrome for a very long time.  I'm afraid I do not know what variables cause it to sometimes fail.

Comment 35 by Deleted ...@, Oct 9 2012

Definitely still an issue. Where is the fix? 
Agreed.  Still an issue two and a half years later.

As suggested above and other places online I've tried double Ctrl+F5 and double Shift+F5, and double alternating Shift+F5/Ctrl+F5.  It refuses to re-request the page.  I know this because I have a breakpoint set in my REST service and it only stops the first time through.

My workaround has been to open a Private Browsing mode window and resubmit the request.  Of course, that only works once too.

Comment 37 by Deleted ...@, Oct 16 2012

Ik like the fact that developers can use Chrome, but a "real" refresh is still an issue here!

Version 22.0.1229.94 m
Google Chrome is up to date.

Please fix!!!

Comment 38 Deleted

My resfreshes work fine until at some point they stop reloading the css and I need to open new tab to continue working.
This is a must have really, please fix this
Seeing this show up pretty often. I've verified on the wire that no request is being made. Really odd thing is that it will ask for CSS assets from the same server, but cache the same server JS.

Seeing that 57 people have starred this, it would be awesome is the priority went up a bit.

Version 25.0.1323.1
+1. Chrome cache is very persistent. "Reload without cache" is essential for dev and should apply to all files (less common files too: swf, svg, woff). Thanks!
Start having this issue since this week.
Dev Tools is set to avoid cache and tried ctrl+f5.
Nothing seems to work.
Was there unreported progress lately? Because for me now local content always bypasses the cache, completely disregarding ctrl-/shift-f5 or development options. Tested HTML changes and <script> with source.
I am fine with that, but is this expected behavior?

- Win, Version 25.0.1351.0 (171316)
Version 23.0.1271.97 m. Still problem exists.
That's frustrating that there are almost no response from Chrome developer team :(
Sadly FireFox + FireBug is still more friendly and useful for developers than Chrome.

In any other way I like Chrome. Especially for speed and "lightness".
I wanted to add that in my experience, Chrome seems to be improperly loading from cache in instances that seem to relate to usually-dynamic sites with a static page in their place.

I've had to switch to Safari for weeks at a time because Chrome continued to load the "down for maintenance" pages for rink.hockeyapp.net and developer.apple.com. As you'd expect from this thread, force refresh didn't resolve anything.
Cc: pfeldman@chromium.org stefanoc@chromium.org
Labels: -Area-Undefined -Pri-3 Area-Internals Pri-2 Mstone-27 Internals-Network-Cache
Owner: cbentzel@chromium.org
Status: Available
This has been a longstanding bug that we haven't been able to address officially. 
Can we look into this?

Meanwhile, can anyone post a reproducible testcase of this bug? (Perhaps where the server content is changing but "hard refreshes" of Chrome are not appropriately getting the new content?) Having something real we can all reproduce would help us to address this bug. Thanks

Comment 48 by ad...@wescook.ca, Jan 26 2013

It's not a bug I've ever been able to get in a reproducible setting, but I know I've seen it many times.  To the point that my muscle memory is now two hard refreshes after a change.

I would suggest a test case be built where a page refresh updates a database or similar, and we measure to see if Chrome displays the change on the next refresh.  Because the bug is pretty uncommon (maybe 1/100 for me?) it'd be hard to catch without running a lot of tests.

I'll watch for any common variables when I see it in the wild but after a couple years, it still seems entirely random.
Mergedinto: 94090
Status: Duplicate
Keep in mind the behavior of https://bugs.webkit.org/show_bug.cgi?id=30862
I'll provide testcase if I can make one, but I doubt this is possible. It's hard to catch why sometimes it's working like expected and sometimes not.
Maybe this is a case when in-page JavaScript adds CSS stylesheet tags in page header on page load? Have to check such approach because many frameworks do like this to dynamically "load" additional CSS and JavaScript resources (for add-ons, extensions, plugins) in page.

Comment 51 by Deleted ...@, Jan 31 2013

My site http://www.xiexianhui.com/firsthouse/ just can't get always refreshed on my chrome and  firefox browser by CTRL+F5 or SHIFT+F5, occassionally it does the trick but most time it does not. Really annoying!

In Chrome, I also tried disabled the cache from Dev tool, no use.

This is really wasting me lots of time. Can anyone please make some magic here?! Thanks.
Project Member

Comment 52 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-Internals -Mstone-27 -Internals-Network-Cache Cr-Internals M-27 Cr-Internals-Network-Cache

Comment 53 Deleted

Comment 54 by mike...@gmail.com, Mar 29 2013

I believe I have this same issue. I am making an AJAX based website that uses a lot of Javascript to talk to my server. If I make a change to a file javascript/blah.js and upload it to my server and then view javascript/blah.js through chrome i see the old version. if i append stuff to the file name (javascript/blah.js?2342343) then i see the new, correct, page.

failed solutions: f5, ctrl+f5, ctrl+shift+r, ctrl+r, disable cache through console, clearing cache in tools, and even forcing a reload through javascript (location.reload(true)).

NOTHING clears the cache. at least, not when i ask it too. strangely sometimes when i come back (days later) the problem no longer occurs. Can you guys just release a temporary version of chrome with NO CACHE AT ALL? I'd rather have that then have this bug persisting. MY BOSS DOESN"T BELIEVE THESE BUGS ARE CHROMES HES BLAMING ME! HELP ME! lol
Could you test with Chrome 27+ ?

Specifically, from the network panel of the developer tools, the resource that is failing to refresh must be loaded before the load event is dispatched. If that is not the case, the resource is not considered part of the page so it will NOT be "refreshed" with any combination of f5. This is by design.

If the resource is loaded before that notification, and it's still not refreshed, please provide details so that the bug can be tracked.

Comment 56 by mike...@gmail.com, Mar 29 2013

Thanks for the quick response, I'm a little confused by what "notification" you're talking about.

I would be happy to test with a newer version of chrome. Where can I find a download (google search results don't look legit)? Is this a new beta version (chrome says its up to date) ?
The network tab of the developer tools show a waterfall of all resources as they are loaded. There are two vertical lines at the right hand side... one of them is labeled "Load event fired" on hover. Anything loading after that point is not officially part of the page (a page can keep issuing requests for hours).

Newer versions can be installed from
http://www.chromium.org/getting-involved/dev-channel

Currently the Dev channel is at ver 27 and the Canary channel at ver 28.

Comment 58 by mike...@gmail.com, Mar 30 2013

Ok I see what you mean. All scripts are there before the load event. I will download the new version and try to reproduce the issue.

Comment 59 by avben...@gmail.com, Mar 30 2013

@rvargas, for any resource loaded after the "Load event fired" you wrote that such "is not considered part of the page so it will NOT be "refreshed" with any combination of f5. This is by design." 

Agreed.

Still for my understanding: such late-loaded resource would (or should) then not be cached at all, right?
> If that is not the case, the resource is not considered part of the page so it will NOT be "refreshed" with any combination of f5. This is by design.

Actually, I think this is wrong, and is the root of most of the complaints, even if it is "by design". Replacing a resource with an async loader for that same resource should not prevent it from being evicted from the cache, as this makes a large, unintuitive and growing subset of the web resistant to force-refreshes.

I think the right behavior is that if a page is force-refreshed with shift+f5, then any resources loaded in that tab for the first time should not be cached; that is, the tab can use cache, but it can't use any cache entry from before shift+f5 was pressed, ever. This should remain true at least until the Ready event fires, but preferably should remain true forever until it's closed.
@avbentem: Caching is determined by the HTTP headers of the response, not by the time the request was issued.

@jimrandomh: If there is no limit, we could be applying the same properties for hours (as in saying, this page is being force-refreshed for hours). The current limit is the Load notification. After that point the application logic is in charge of finding what is the right thing to do depending on the nature of the request.

The actual discussion about this behavior (and the place where a change could be made):
https://bugs.webkit.org/show_bug.cgi?id=30862
@rvargas, I finally get it. Right now I'm not 100% sure that is what I have been seeing in the past, but I'll start using Chromium during development again to see if it indeed only applies to dynamically loaded resources. I guess it does, and then your explanation surely makes sense. Thanks.

(Though I'd love the behavior to be different, I wouldn't know of a better fool-proof yet well-performing way to define what cache needs to be cleared. Also, I never knew WebKit was doing the caching; I always figured caching was one of the things the various browsers added on top of WebKit's rendering engine.)
WebCore (WebKit) does some caching, and browsers on top do extra caching. However, the logic that determines if a resources is part of a given page is part of WebCore.
@rvargas: Yes, and continuing to apply the force-refresh property indefinitely is the right thing to do in this case, so long as it's not applied to the same resource twice. It should be at least as strong as a cache-clear, for that particular tab. If shift-refresh isn't as strong as a cache clear, then it's simply broken.

(For one project I'm working on, I have "nuke the whole cache" as part of my edit-compile-test cycle. It is very annoying that this affects the cache of web sites that aren't part of my project. It is also annoying to deploy, find some users have gotten half the resources updated, and not be able able to tell them to shift+refresh.)

Comment 65 by mike...@gmail.com, Apr 2 2013

After using the dev version I can confirm that the bug still exists under the same conditions mentioned before.
Just to double check, the fix on M27 is actually displaying the line at the right point on the dev tools waterfall (it was being displayed too late before M27).

If you still see a problem, please provide repro steps on  bug 94090 .

Comment 67 by kris...@gmail.com, May 10 2013

This bug threatens to reduce chromes desirability as a development browser.  We have no choice but to use Firefox until this is fixed.
Please use "Disable cache" in settings instead. Scripts loaded post-onload will be anyways cached since it is not feasible to determine whether they are requested by the forced-refresh page or a regular page in all cases.
But why Chrome can't fix it for years ?!!
Also white flickering bug is not fixed for years...

apparently SHIFT+CTRL+R does the trick with Chrome Version 27.0.1453.110 m.

(tested on Windows XP SP3)
I cant believe that 3 years later, this bug still exists. People go on about how cool google is, but at least FireFox never gave me these issues! Im so close to just going back to FF.
Oh, just so some people dont say i didnt try:
CTRL+F5 = nothing
Shift+F5 = nothing
Sprog->Disable Cache = nothing
Right click refresh button->empty cache and hard reload = nothing

Running latest Chrome 27.0.1453.110 m

Comment 73 by avben...@gmail.com, Jun 18 2013

But, @michael, did you see rvargas' comments? (Comment #52 and further?)

I don't know if this is a bug or not, but validating the following might help:

> The network tab of the developer tools show a waterfall of all
> resources as they are loaded. There are two vertical lines at the
> right hand side... one of them is labeled "Load event fired" on
> hover. Anything loading after that point is not officially part
> of the page (a page can keep issuing requests for hours).
@avben - No, thats not it. The page is loading way before then, even before the DOMContent even fired point. Its inline javascript thats not getting updated.
Quite annoying.

Comment 75 by loupi...@gmail.com, Jun 18 2013

and also css is not reloaded by force-reload.

SHIFT+CTRL+R seems to force the reload of images, but not of js and css.
I want to be totally clear here: without reproduction details there is no actionable items.

So if you see an issue that you believe is broken, file a bug report with all the relevant info and steps to reproduce.

(quick note: there was a recent regression on Blink' handling of page refresh that caused wrong behavior under certain conditions... that was fixed yesterday, and as far as I know it didn't reach Stable or Beta)

Comment 77 by sygmo...@gmail.com, Jun 18 2013

I just ran into this issue myself, so guess I'll join in on the discussion!

I've always been using Firefox for web developing, but I'm getting a bit annoyed so am considering a move to Chrome now. But of course not being able to change a resource and see its result right away is rather an annoyance for web developing! 

So I'll mention as much details as I possibly can, hoping that it will help to be fixed then. 

The MAIN PAGE (hosted on DOMAIN) has an html ELEMENT. The ELEMENT is styled by a css file (also hosted on DOMAIN) to have an image background, the image being a PNG FILE (hosted on STATICDOMAIN). The ELEMENT is however not visible upon load (its parent has display:none), but it is present in the DOM and is dragged into view upon load with javascript. 

The PNG FILE has the following headers, according to Chrome's Network tab: 
Accept-Ranges: bytes
Content-Length: 920
Content-Type: image/png
Date: Wed, 22 May 2013 22:47:20 GMT
ETag: "3600b-398-4af5f7c1ef480"
Last-Modified: Sun, 16 Oct 2011 00:22:26 GMT
Server: Apache/2

Note the Date header being a month in the past, and the Last-Modified being ages ago (which is correct as far as the old version of the file goes). 

I updated the PNG FILE, and uploaded it to the STATICDOMAIN. Here are the new headers when viewed from Firefox: 
Accept-Ranges: bytes
Connection: Keep-Alive
Content-Length: 1344
Content-Type: image/png
Date: Tue, 18 Jun 2013 19:06:42 GMT
Etag: "3600b-540-4df720c17e140"
Keep-Alive: timeout=1, max=100
Last-Modified: Tue, 18 Jun 2013 18:40:29 GMT
Server: Apache/2

Whatever I do with the page in Chrome, it will never show this file: it keeps showing the same old file with the same old response headers. I tried shift-F5, control-F5, shift-control-F5, control-R, shift-control-R. None of these had any effect. The Network tab keeps proudly displaying that it managed to get the image 'from cache'. 

Interestingly however, inspecting the ELEMENT and right-clicking the background-file-url to open into a new tab and then reloading that tab, finally laded the new file. Hurray, I thought! The new file is now in the cache. 

Well, it's not. I was actually stunned, but my MAIN PAGE still shows the old PNG FILE. I have two tabs open here now, the MAIN PAGE in the first tab and the PNG FILE in the second tab. The PNG FILE in the second tab displays the new version, but the MAIN PAGE keeps using the old file. No matter what I do. Hovering over the image URL in the inspector on MAIN PAGE also still displays the old file. So it seems like each tab/process has its own cache (perhaps branched from the 'main' cache when the tab/process is created, or something similar). 

How did I finally get out of this situation? Going to a completely different website (on a different DOMAIN - it was BBC News, actually) and then going back to my MAIN PAGE. Tadzaam, it suddenly shows the updated PNG FILE!


Out of curiosity I updated the PNG FILE a second time to see whether I could reproduce it in exactly the same way. I could, except that I did not need to go to a different website. I did however need to reload the file in a separate tab and then reload the MAIN PAGE. 
I even did it a third time - and surprisingly, shift-control-R DID in fact correctly re-download the resource. So that last time, I didn't even need the separate-tab trick, and it worked as it should. 

I'm getting a feeling the Chrome tries to decide itself whether a resource should be redownloaded, regardless of cache preference. Since I was updating this file often lately (the past hours), Chrome seems to have decided to give it more attention and download it again when I refreshed, after that final update. Or am I getting paranoid?... 

Point being: it may be difficult to reproduce, unless you have an image available in cache that has not been updated in over a year. Nevertheless, I hope this helped!

Comment 78 by sygmo...@gmail.com, Jun 18 2013

By the way - I realise this behavior may be 'by design', as the PNG FILE (being the background of an invisible element at page load) may be only loaded after page load. But that is only an explanation of course, not a justification. Since, if this is 'by design', consider that there is an issue with the design :)

(finally, for the record, I was using version 27.0.1453.110 m)
Thanks for the details. I totally understand your frustration, but developers and users expect different things... so the best option for developing a site and having instant feedback of all changes is probably to disable the cache while the developer tools are running. To do that, open dev tools and go to the settings (gear icon at the far right on the bottom).

Now, regarding the headers of the PNG on comment 77, that resource is usable without revalidation (aka, considered "fresh" according to the HTTP spec) for about 1.9 months after download... so until mid July. This is of course for normal a navigation, not for forced reloads or a history navigation. However, if the image is not considered part of the page (see comment 57), it will be loaded as if a regular navigation is taking place.

Regarding right-click to load in a new tab, yes, there is an in-memory cache that is not shared between renderers so it is possible to update the main, shared cache, without updating the memory cache of a given tab. Close tab + ctrl-shift-t should do the trick.

Comment 80 Deleted

Comment 81 by loupi...@gmail.com, Jun 18 2013

> so the best option for developing a site and having instant feedback of all changes is probably to disable the cache while the developer tools are running.

yes, but opening the dev tools means that all breakpoints will be enabled, and most often you just want to fully reload the page (and all associated images, js and css loaded by the page) to test the page in a normal browser (NOT with the Chrome developer tools opened!).

Comment 82 by Deleted ...@, Jul 8 2013

Annoying having to hot refresh twice to reload the new version of the page! Someone fix this please!
STILL an issue in Chrome 32. Full refresh, clearing cache, DevTools "Disable cache": other content was properly refreshed, but not SWF. Even completely removing the SWF file from the server had no effect.

Had to add a cache-busting URL parameter, not a good solution. This is a bug and needs to be fixed.
The swf may be a different issue. If you can reproduce at will (as it sounds), please file a new report and provide a net log. See http://www.chromium.org/for-testers/providing-network-details for details.

In particular, I'd like to see logged the request that fetches the resource the first time, and a request that fails to request the file from the server.

Comment 85 by Deleted ...@, Mar 6 2014

just stop making excuses and make the cache check for new versions of files correctly EVERY time the file is loaded.

The excuse about user and developer expect different things is rubbish.

If a developer fixes a problem in their .js or other files, trying to get thousands of users to jump through hoops to get the new file loaded is NOT acceptable.


 

Comment 86 by Deleted ...@, Jun 18 2014

Eight years.  Obviously Google does not give a tinker's damn.

"Don't be evil...until you get critical mass and then ream everyone, all the time, every way!"

Comment 87 by Deleted ...@, Jun 18 2014

BTW, it's just wrong.  You you put an "expires" or "no-cache" meta tag on the page, using the cache is just wrong.

Obviously they understand that.  I'm betting my last thin dime that some idiot content provider, read ONE provider, relies on this not working right.  

Comment 88 by ad...@wescook.ca, Jun 18 2014

Please refrain from hyperbole.  Being "evil" has nothing to do with a software bug.  Thanks.
Rereading through this for the first time in years, in part because I ran into this bug this week ... even with disabled cache, asynchronously loaded elements (such as CSS files) use the cache! This is insane. 

I see that rvargas@chromium.org commented

>Specifically, from the network panel of the developer tools, the resource that is failing to refresh must be loaded before the load event is dispatched. If that is not the case, the resource is not considered part of the page so it will NOT be "refreshed" with any combination of f5. This is by design.

This seems to be , if anything, a strawman. Regular users are not going to be pressing shift or control along with F5 -- if a dev wants to reload all assets on the page, they should be, including ones loaded after the onload handler.
This s crazy guys! It's 7/2015 and Chomes passive interest in this issue has resulted in hundreds of millions of false page loads. How many developers are out there modifying webpages and all their regular subscribers are returning to see the OLD page instead. It's bad for business and bad for people, not just web developers. 

PLEASE, if you won't fix the issue, if you think it's due to "Bad programming" of the web page then TELL US WHAT THE PROPER WAY TO CREATE THESE AGE IS SO THAT ALL ASSETS ARE RELOADED ON REFRESH. If it's about development, then tell use the way you want this to be implemented. Every refresh should load every asset to keep clients, visitors, and customers up to date. 
I am using the most recent version of Google Chrome - Version 53.0.2785.89 m and this issue still exists. NOTHING works to force Chrome to reload. 

Comment 92 by lomar...@gmail.com, Sep 16 2016

Hello, as cmictrem...@gmail.com told in Google Chrome - Version 53.0.2785.101m this issue still occurs :( In our project css are loaded interminently but not all required, sometimes base.css and sometimes style.css It's a big problem!!!

Comment 93 by ewer...@gmail.com, Oct 14 2016

Happening here as well on the most current version. Extremely distracting during development, especially if you're doing "non-visible" stuff and you expect your changes to apply without an explicit "clue". Is it really that hard to ignore a cache???
The only thing you can do currently for development is open the inspect window CTRL-SHIFT-i and then in the network tab select "Disable cache", this only works when the dev window is open and puts a high load on your development server as nothing is cached.

I also think this is embarrassing that google can not get their browser to do a full page refresh using CTRL-F5. 
As many prior comments have made clear, this is not something that separates ordinary users from developers - the problem applies equally to both. 
Users looking at the web pages that I create and edit should simply be able to refresh their cache in a way that is standard across browsers in order to be sure they are seeing the latest content. It beggars belief that those from the Chrome team viewing this thread cannot see it that way - or just admit it's a terrible bug and ... they can't fix it. 

There is a useful test site (RefreshYourCache) that simply and clearly shows how your browser reacts to a refresh request (the various combinations of F5 on Windows for example). Firefox and MS Edge both refresh properly - Chrome doesn't. It's as simple as that.

Those involved in progressing Chrome should take note that this is as much a user issue as anything else and prove that they can prioritise fixes for their user base by offering a comment here that the issue is being actively attended to.

Sign in to add a comment