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 /
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
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.
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
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).
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/
> 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
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
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,
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
Technical Writer
she...@mozilla.com
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
> 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
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.
I thought we did ask the server about those as well, though I could be
wrong here...
<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.
-b
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
--
Mozilla Tips: http://www.ufaq.org/ , http://ilias.ca/
About Mozilla: http://www.mozilla.com/
Mozilla Themes: http://www.projectit.com/freestuff.html
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