Reload vs. reload from cache
beltzner
the reload button behaviour based on feedback that many users quite
reasonably don't understand the difference between reload and
shift+reload.
The first suggestion was to have the reload icon change when shift was
pressed, as a way of indicating that the reload action would be
different. After some quick chatter, we decided that this wasn't
really addressing the core problem, which is that users don't
understand *why* sometimes reload doesn't actually reload the page.
The second suggestion was to flip the default interaction such that
reload would always try to refetch the content, and shift-reload would
be used to reload from cache. That led to a "well, why is it the way
it is now?" discussion, and the only thing that came up as a possible
reason was that reload-from-cache is way faster, and there's no
reliably easy way to understand how to optimize that behaviour.
So before we started haphazardly filing bugs, we wanted to get some
other thoughts on the issue:
- why is the behaviour as currently designed?
- is there any way to know when reload-from-cache won't cut it? (etags?)
- what does the user expect when they click "reload"?
- should we allow pages the ability to control the refresh rate?
It seems reasonable to me that "reload" should do just that, and that
if there's a way to verify that the data is unchanged at the website
then we're quite safe to reload from cache for performance reasons,
but otherwise I'm not sure why we'd ever assume that a user would even
*click* reload just to see what they're already looking at.
I know that this forum will set our thinking straight. Have at us!
cheers,
mike
--
/ mike beltzner / phenomenologist / mozilla corporation /
Skree
I hope I'm not intruding on this discussion, I'm just one of the many
lowly users who cruise this newsgroup for insights on how FF is progressing.
I've been a user of various browsers since Netscape Ver 1, and that
crazy browser that came with Warp 3
I've always thought that reload actually went to the website and
reloaded the data.
My question is - What would be the point of reloading from a cache on my
machine when I want to see if page content has been updated.
Or am I just totally missing the point of this question?
I quite often hit the reload button to reload a page that comes up
blank. That happens from time to time for whatever reason. Other
times, I do it to reload the data from the page because it changes
often, such as a group blog site.
In these days of more and more hi-speed subscribers, how much of an
issue is the performance advantage of re-load from cache?
Is there some way for FF to know how fast the interconnection with the
web is a do a cache reload instead??
Kenn
ps I love what you've done with FF so far, to use my son's words - ff rox
--
from the bottom of the RockPile
Chris Hofmann
There is at least one long standing bug that causes the wrong behavior
for the page to be pulled from the cache v. updated content from the web
server.
A fix is on the trunk that should eliminate possibly frequent case where
folks have to hit shift reload, or even know about its existence.
More details in https://bugzilla.mozilla.org/show_bug.cgi?id=352848
chris h.
Chris Thomas
> I hope I'm not intruding on this discussion, I'm just one of the many
> lowly users who cruise this newsgroup for insights on how FF is
> progressing.
>
> I've been a user of various browsers since Netscape Ver 1, and that
> crazy browser that came with Warp 3
>
> I've always thought that reload actually went to the website and
> reloaded the data.
>
> My question is - What would be the point of reloading from a cache on my
> machine when I want to see if page content has been updated.
Normally reload asks the server, "has this document been modified?" and
if the server says no, it just uses the cache. Shift+reload bypasses
the cache no matter what. This is useful if the cached data is bogus
for some reason, or the server lies about document modification for
whatever reason (maybe with dynamically-generated content/bad
configuration?).
> In these days of more and more hi-speed subscribers, how much of an
> issue is the performance advantage of re-load from cache?
It would be significant when a server is not particularly fast or has
many objects on the page. Try surfing something like a web forum with
your cache disabled - having every icon get re-loaded often actually
takes quite a while even on broadband.
-Chris
Skree
Thank you for the quick response, now I understand how "reload" actually
works.
Being that reload tests for a changed page, isn't it a moot point as to
whether FF reloads from cache or the web.
If not a moot point, could it be coded for a double-click to force a
reload from web?
As for your suggestion to surf without cache on, I think I might pass on
that, based on your comments about icons reloading (Unless I have
insomnia some night).
Andrew Schultz
> It seems reasonable to me that "reload" should do just that, and that
> if there's a way to verify that the data is unchanged at the website
> then we're quite safe to reload from cache for performance reasons,
Actually, this is what happens (assuming "verify" means we ask the
server if the page has changed).
> but otherwise I'm not sure why we'd ever assume that a user would even
> *click* reload just to see what they're already looking at.
Shift reload reloads the page and all its elements off the network even
if everything is up to date and also resets the form controls. Some
people might not want the resetting forms (I, in particularly often want
to keep the form fields). There's a WONTFIXed bug with lots of users
complaining about reload not resetting the fields.
--
Andrew Schultz
ajsc...@verizon.net
http://www.sens.buffalo.edu/~ajs42/
Benjamin Smedberg
> The second suggestion was to flip the default interaction such that
> reload would always try to refetch the content, and shift-reload would
> be used to reload from cache. That led to a "well, why is it the way
> it is now?" discussion, and the only thing that came up as a possible
> reason was that reload-from-cache is way faster, and there's no
> reliably easy way to understand how to optimize that behaviour.
Please note that shift-reload has other consequences:
1) it reloads not only the main HTML page, but also any images and other
sub-content (which are typically cached much more often than pages themselves)
2) it resets form content, which in most cases is not what old-time browser
users expect. Not sure about new browser users, this might require some
usability testing.
3) I belive (darin or biesi should correct me if I'm wrong) that
shift-reload adds no-cache headers to the HTTP requests so that the requests
go back all the way to the origin server. This would for instance invalidate
proxy caches along the network. Think for example of a transparent proxy
(squid, or something equivalent) in front of developer.mozilla.org: if you
know an edit has been made but it's not showing up, shift-reload should
force the proxy to re-fetch the content from the original server.
--BDS
Steven Garrity
> 3) I belive (darin or biesi should correct me if I'm wrong) that
> shift-reload adds no-cache headers to the HTTP requests so that the
> requests go back all the way to the origin server. This would for
> instance invalidate proxy caches along the network. Think for example of
> a transparent proxy (squid, or something equivalent) in front of
> developer.mozilla.org: if you know an edit has been made but it's not
> showing up, shift-reload should force the proxy to re-fetch the content
> from the original server.
As a result, shift-refresh is a god-send for web developers - being able
to be sure you're pulling the latest images, javascript, and CSS is
key when debugging.
Steven Garrity
Eric Shepherd
should actually reload the page from the server. The cache issue
isn't nearly as big a deal now as it was when everyone was on dialup.
Eric Shepherd
Technical Writer
she...@mozilla.com
On Oct 3, 2006, at 1:00 AM, beltzner wrote:
> It seems reasonable to me that "reload" should do just that, and that
> if there's a way to verify that the data is unchanged at the website
> then we're quite safe to reload from cache for performance reasons,
Chris Hofmann
Its not dead. Have a look at this example.
https://bugzilla.mozilla.org/attachment.cgi?id=240918&action=view
On a reasonable fast dsl connection...
Its about 23 seconds for the page to have enough information to start
being useful and 30 seconds to fully load from the network.
3 seconds to load most of the data from the cache + plus the one or two
changes that might have occured because parallel booking has happened.
lets not disable the cache or make its use more obscure just yet....
chris h.
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
Eric Shepherd
reload button mean "reload" not "pull what you've already got and
show it to me again unless magic juju says otherwise." :)
Eric Shepherd
Technical Writer
she...@mozilla.com
Peter Kasting
> There is at least one long standing bug that causes the wrong behavior
> for the page to be pulled from the cache v. updated content from the web
> server.
>
> A fix is on the trunk that should eliminate possibly frequent case where
> folks have to hit shift reload, or even know about its existence.
>
> More details in https://bugzilla.mozilla.org/show_bug.cgi?id=352848
If this is fixed, and the current bustage with reloading form fields is
fixed (more below), then I think the current reload behavior is correct
and should NOT be changed.
By "bustage with reloading form fields", what I mean is that in an ideal
world, the browser would leave unchanged every field that the user has
modified, and set the other fields to their server defaults. This isn't
what actually happens with some kinds of fields. When some fields
change on the server, they remain at their old default on the user side,
because the browser doesn't realize that the user hadn't changed them
but the server had. This has repeatedly led to things like resetting
flags improperly in bugzilla. I discussed this on IRC with beltzner et.
al weeks ago, but I don't remember the relevant bug number.
Other than that, the behavior of reload seems correct to me. We fetch a
new page from the server if we're told to and not otherwise, and we
don't reset user-modified form entries. The current shift-reload
behavior, which does NOT do these, doesn't seem at all like what users
would actually want the majority of the time. The only thing that seems
bad to me is that we seemingly can't ask the server about the "last
modified" status of non-HTML resources like images; if we could, reload
would do "the right thing" not only for the page, but all the page's
resources as well.
PK
Myk Melez
> It seems reasonable to me that "reload" should do just that, and that
> if there's a way to verify that the data is unchanged at the website
> then we're quite safe to reload from cache for performance reasons,
> but otherwise I'm not sure why we'd ever assume that a user would even
> *click* reload just to see what they're already looking at.
Presumably the most common case is that the user is wondering, "has
anything changed on the page?" And currently, when the user does that,
and the site has already told us that the page won't have changed yet,
we assume the site is correct.
It's certainly reasonable to imagine that users have good reasons for
thinking something might have changed, and thus we should assume they
know better than the site itself and ignore the cache. But that's not
entirely clear: sites may well be right most of the time, their cache
mistakes might be workarounds for correctable browser bugs, and users
might have entirely different expectations of reload.
I wonder if users sometimes click reload in an attempt to "reset" a page
to its original state: animations, plugins, and scripts restarted; form
fields returned to their initial values; etc. If so, perhaps it would
make sense to expose some UI specifically for reseting a page rather
than overloading the meaning of "reload" and making users get "reload"
behavior when they're looking for not-quite-equivalent "reset" behavior.
-myk
Christian Biesinger
> Presumably the most common case is that the user is wondering, "has
> anything changed on the page?" And currently, when the user does that,
> and the site has already told us that the page won't have changed yet,
> we assume the site is correct.
When pressing reload, we always send a request to the server to ask it
whether the site has changed, no matter what Expires header the server
sent before.
Christian Biesinger
> The only thing that seems
> bad to me is that we seemingly can't ask the server about the "last
> modified" status of non-HTML resources like images; if we could, reload
> would do "the right thing" not only for the page, but all the page's
> resources as well.
I thought we did ask the server about those as well, though I could be
wrong here...
TheOneKEA
beltzner wrote:
> So before we started haphazardly filing bugs, we wanted to get some
> other thoughts on the issue:
>
> - why is the behaviour as currently designed?
> - is there any way to know when reload-from-cache won't cut it? (etags?)
> - what does the user expect when they click "reload"?
> - should we allow pages the ability to control the refresh rate?
<snip>
One idea would be to change the interfaces on the trunk to add a new
reload command that ONLY fetches new HTML pages with the no-cache
headers, and simply does a cache-check load of the remaining content,
including anything new in the non-cached HTML page.
Once this is available at the interface level, you could then change
Shift+Reload to use this new command, and create a new hotkey
(Ctrl+Shift+Reload, if it is unused) for a fully non-cached reload.
IMHO, this gives a good balance between wasting proxy
cache/bandwidth/time and satisfying the user's desire to check for page
changes.
Eldo Varghese
let the user know by making the refresh icon switch to something else
when they press the shift key?
- Eldo
Bradley
well should expect the whole thing to reload and, as a consequence,
loose any form field data. That's what "Reload" means to most people.
They want a /new/ version of what they're looking at. It you have
partial form data you /don't/ want to change, they you shouldn't be
hitting the "Reload" button. Common sense. I think you're reading too
deep into this. Reload means Reload. Simple, and everyone expects it.
-b
Robert Kaiser
> I think if a user hits "Reload" on a page with fields in it, they dang
> well should expect the whole thing to reload and, as a consequence,
> loose any form field data. That's what "Reload" means to most people.
> They want a /new/ version of what they're looking at. It you have
> partial form data you /don't/ want to change, they you shouldn't be
> hitting the "Reload" button. Common sense. I think you're reading too
> deep into this. Reload means Reload. Simple, and everyone expects it.
Wrong. E.g. when you hit a midair collision in Bugzilla, a common thing
to do is press "back", reload, check that everything's OK and submit
again. That would be badly broken by what you suggest.
Robert Kaiser
Sailfish
to reload from server UNLESS the reload page (including Back instances)
have form/textfield tags in it, in which case, it should simply reload
from cache. Again, this is assuming that the cost to implement that
logic isn't too pricey.
--
Mozilla Tips: http://www.ufaq.org/ , http://ilias.ca/
About Mozilla: http://www.mozilla.com/
Mozilla Themes: http://www.projectit.com/freestuff.html
Robert Kaiser
> This may fall in the realm of "bloat" but I'd prefer the default to be
> to reload from server UNLESS the reload page (including Back instances)
> have form/textfield tags in it, in which case, it should simply reload
> from cache. Again, this is assuming that the cost to implement that
> logic isn't too pricey.
No, I think we should just like now reload from the server and re-enter
all form fields the user has entered - something we already do now (ok,
we re-enter all form values, not only user-changed ones).
The useful thing in this scenario is that we actually do re-fetch from
the server, but preserve the form field values (this also has already
helped me a lot when developing websites that use forms). If you want
the form data cleared, go the the URL bar and press enter again or use
shift-reload.
Robert Kaiser