(No comment was entered for this change.)

(No comment was entered for this change.)

Double click reload button or hit F5 twice time very fastly and it will force the 
reload of the page.

Wouldn't it be nice to support 'Shift + Reload button' (and shift-CTRL-R) for 'force-
reload' as Firefox does? 

Shift-reload support has been a feature request for some time; talk to Darin if you 
want to know the gory details.

Thank you for the reference. I dug up my inbox and found the thread on the issue 
(between you and Darin). Here's what we do at the moment (copied from Peter's email 
with only the last sentence changed to reflect what Chrome does now):

There are two ways to know if content is valid (aside from just forcibly reloading 
it):
(1) At the time you got the content, the server tells you "this is valid until time 
X", and the current time is less than X.
(2) You send an if-modified-since request over the network to the server and it tells 
you that the content is still valid.

In Firefox, clicking a link or hitting <enter> in the address bar are like choice 
(1).  Hitting reload is like choice (2).  Hitting shift-reload forces us to reload 
all content.

In Chrome, clicking a link or hitting <enter> in the address bar are like choice (1). 
Both hitting reload and shift-reload triggers 'force-reload' (like 'shift-reload' of 
Firefox).

We don't have choice #2, but we do have 'force-reload'. 

Now, this bug is that 'force-reload' does not work in some cases.  

(No comment was entered for this change.)

According to http://www.google.com/support/chrome/bin/answer.py?hl=en&answer=95743 
there should be a significant difference between F5 and CTRL+F5. CTRL+F5 should 
ignore cached content.
From a previous comment by jshin I understand that both trigger 'force-reload'.
I have seen that both send a conditional request header (If-Modified-Since/If-None-
Match) along with "Cache-Control: max-age=0".
That means that an intermediate HTTP/1.0 cache (Such as Squid) may return 304 
responses to these requests, which will result in the browser getting cached content.
Other browsers (IE,FF,Safari) send CTRL+F5 requests with no conditional header field, 
which enables the browser to get non-cached content from the origin server.

 Issue 3265  has been merged into this issue.

 Issue 6970  has been merged into this issue.

 Issue 13843  has been merged into this issue.

 Issue 11400  has been merged into this issue.

I'm having the same problem.

I'm using Chrome to view results of a Solr query, which seems to be cached by the 
browser (I turned off Solr server side caching off). In Chrome, old results remain, no 
matter how I try to refresh, while in Firefox they refresh with Ctrl-F5.

Chrome is much faster than Firefox as it has no extensions loaded but at the moment I 
have to switch back to FF for debugging. Please fix this.

Firefox sends a Pragma: no-cache header (I believe the other major browsers do as 
well) when doing Shift-Refresh. I believe that Chromium should support this behavior 
as well.

For a web application I'm working on, we interpret the Pragma: no-cache header 
specially to skip going to memcache for a page if the header is present (and the IP 
is internal!). This is useful for debugging memcached related problems on the site. 
I've heard of other developers doing this too (and indeed, the idea is not my own), 
i.e. using this header to enable certain debugging features on their site. It's a 
really small detail, but it's pretty handy at times.

We can now easily implement this leveraging the code added by:
http://codereview.chromium.org/341043

Hi Darin!

Whay about this bug? I have 3.0.195.33 version of Google Chrome and after Ctrl+F5 it 
still sending 'If-Modified-Since' header. As result your page loads "like from cache". 
I think you should use Firefox way and send 'Pragma':'no-cache', 'Cache-Control':'no-
cache' without 'If-Modified-Since'.

Replacing labels:
   Area-BrowserBackend by Area-Internals

(No comment was entered for this change.)

Any news on this?

This bug has been lingering for over a year now and seems quite a basic thing to get 
wrong. Note that this primarily affects web-developers (who need to force-reload more 
often than regular people) - way to amuse your early adopters?

Fwiw, problem still present in 4.0.249.43 on mac.

I just discovered the same bug. Every browser on earth has a force refresh. It is mandatory for web devs. Please fix this.

@NoelHibbard There is a force refresh, simply not with a Ctrl+Mouse click, but with 
Ctrl+F5 or Shift+F5 or something like that.

When i click refresh, the content should be reloaded, like in firefox.

 Issue 31310  has been merged into this issue.

 Issue 31389  has been merged into this issue.

(No comment was entered for this change.)

This table summarizes the headers sent by different browsers for the different types 
of reload: http://stackoverflow.com/questions/385367/whats-the-difference-
between-hit-f5-and-ctrl-f5-in-browser/385491#385491

Chrome is the only browser that doesn't have a force-reload. So it's still not possible 
to get Chrome to flush upstream caches by sending Pragma: No-cache or Cache-
Control: no-cache 

Re-tested on Mac Chrome/4.0.302.2 and WinXP 4.0.249.78

I'm a Web Developer and IT guy for a small company. This is the only bug preventing
me from switching from FF to Chrome as my main browser. It also keeps me from
suggesting chrome to others in my organization.

Ctrl+F5 (shift+F5 || ctrl + click-refresh) should not only hard-refresh the page but
also all content (images, css, js, etc) on the page.

This bug seems to be an important reason why web developers aren't switching to 
Chrome, yet it seems to be dormant. 

Tell your web developer friends to star this issue, hopefully we can draw some 
attention to it and get it fixed.

Here's a live graph of stars:
http://webnumbr.com/number-of-people-who-starred-chrome-shift-reload-bug

While it is an esoteric feature, it's one that has been in web browsers since Netscape (circa 1995) and is a defacto 
expected feature to easily force a non-cached reload of a webpage.

Pretty please, let's fix this, it's *the* single reason why I can't switch to using Chrome as 
my main browser.

Just realized that this is happening. Can't test my pages this way.

Although I rely on far future expires and URL modification anyway so it's not so 
pressing for me as it is for others.

Just curious fact about Chrome - I didn't expect this.

Adding my voice to this thread... I am now having to either proxy http requests to
chrome or version my Javascript files after every edit just in order to debug a
Chrome-only bug in my site. This is tedious - I am looking forward to a fix.

I find myself using the same workarounds as #32 for debugging in Chrome. This issue
is not esoteric as some may think. It's actually in the project's interest that
developers won't have to jump through hoops to debug their code in Chrome. Otherwise,
less developers would bother to do so, and more Chrome-specific bugs won't be aired.

A good workaround :

You can clear the cache in linux by hitting CRTL-SHIFT-DEL -> SHIFT-TAB -> ENTER
THe first time you do it, check that only 'Empty the cache' is checked, then any time 
you want, just repeat the hotkey sequence - if you do it enough, you can do it pretty 
fast ;)

Cam

A year and half. How hard can it be to send a couple of additional headers? Or do you 
just prefer to annoy web-developers?

I don't think anybody is trying to consciously annoy web developers -- chromium is 
open source and I don't have any patches to offer.

All the same, I wish the priority of this low-hanging-fruit of a bug got raised. Web 
developers everywhere will appreciate it. It doesn't put me off using chrome as my 
primary browser nowadays, but it is an annoying thorn in my side, and I think about 
it every time I have to launch safari/ff (read: often).

(No comment was entered for this change.)

Retitling bug based on jshin's comments in comment #4.

BTW, I took a look at this; it turns out to be pretty trivial.

Diff is:

-    m_frame->loader()->reload();
+
+    // Our reloads should always be "full" reloads; Chrome doesn't support non-full
+    // reloads, so always pass true to reload.
+    m_frame->loader()->reload(true);

Passing true there makes the following arg true:
    void FrameLoader::reload(bool endToEndReload)

which then gets converted in this test:
    loadWithDocumentLoader(loader.get(), endToEndReload ? 
FrameLoadTypeReloadFromOrigin : FrameLoadTypeReload, 0);

and then FrameLoadTypeReloadFromOrigin is later tested in the subresource policy 
check to decide whether to skip the cache on subresources.

I verified this works by clicking "reload" on the astronomy picture of the day.  
Without the patch, subsequent loads are quick; with the patch, it always reloads the 
image.

The new title ("Reload button should do a full ('force') reload") isn't accurate; I
think some clarification should be made. The real issue is that SHIFT+reloadButton
should do a (full) force-reload. As should Ctrl+F5 and Shift+Ctrl+R. See this issue:
http://code.google.com/p/chromium/issues/detail?id=31389Se for a description of the
problem most web-developers are facing.
A (full) force-reload should cause ALL media (javascript, css, flash, images, etc) on
a web page to be re-fetched without the If-Modified-Since header (or any other cache
related headers).

This is how I think reload commands should be handled:
"Reload" button, F5, and Ctrl+R: Reload the entry in the address bar only (respect
Last-modified and other cache headers).
Ctrl+"Reload" button, Ctrl+F5, and Ctrl+Shift+R: Refresh ALL content/media required
by the loaded page/media.


Does anyone disagree?

(No comment was entered for this change.)

Have a working patch that does it the normal-browser way.

I really like musicisair's behavoir. That would be great.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=39430 

------------------------------------------------------------------------
r39430 | evan@chromium.org | 2010-02-19 02:51:16 -0800 (Fri, 19 Feb 2010) | 18 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/app/chrome_dll_resource.h?r1=39430&r2=39429
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/browser.cc?r1=39430&r2=39429
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/browser.h?r1=39430&r2=39429
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/gtk/accelerators_gtk.cc?r1=39430&r2=39429
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/gtk/browser_toolbar_gtk.cc?r1=39430&r2=39429
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tab_contents/navigation_controller.cc?r1=39430&r2=39429
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tab_contents/navigation_controller.h?r1=39430&r2=39429
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tab_contents/tab_contents.cc?r1=39430&r2=39429
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tab_contents/tab_contents.h?r1=39430&r2=39429

linux: plumb shift-reload down into new shift-reload API

Currently Linux-only, but the Mac/Win bits should now be trivial.

While I was add it, I tweaked a NavigationController function
that took a bare boolean into an enum to make the call sites more
explicit about what they're doing.

(In most places I added new functions that call into a shared
backing function; this is so I don't need to change every single
caller of e.g. Reload() to pass through an extra flag that will
be the same for almost every caller.)

BUG=1906
TEST=visit astronomy picture of the day; hit reload, picture pops
up quickly; hit shift-reload, picture loads slowly

Review URL: http://codereview.chromium.org/594063
------------------------------------------------------------------------

Since this is now implemented on Linux, I split the remaining work into platform-
specific bugs (should be trivial).

http://code.google.com/p/chromium/issues/detail?id=36244
http://code.google.com/p/chromium/issues/detail?id=36245

Ta-da!

Great! 22.02.2010 - 08.09.2008 = ~2 years to fix it! Awesome! 
Evan, where you was before? :)

@xaka2004 A year and a five months are hardly "~2 years". Chromium does not even exist 
for two years.

 Issue 36568  has been merged into this issue.

Omg nice. A linux first? That's awesome ;D

So force flush cache is finally supported by Chrome. Congrats to the dev.

 Issue 32993  has been merged into this issue.

So force flush cache is finally supported by Chrome. Not for Mac users. Please fix it

@53
it is, see  issue 36245 

6.0.472.0 dev on Windows and Ctrl+F5 did not worked. I had to flush the cache from the menu in order to fully refresh the page.

This regressed on July 15.

I reverted Webkit patch 63528 on my branch and it works again.

I meant to set this tentatively at M6.

(No comment was entered for this change.)

 Issue 48445  has been merged into this issue.

This issue is marked as M6. Are you sure it is? Dear owner, please update the milestone accordingly.

Yes, please, Mstone-6. I'd like a fix for 472 as soon as I can get my hands on it.

Landed upstream: http://trac.webkit.org/changeset/66549

Caveat: there's no test associated with the patch because the WebKit test infrastructure can't do the equivalent of a shift-reload currently.  I verified it manually with a Chrome ToT build.

Also made it to M6

Could we add a browser_test on the chrome side?