Poningru, CTho and others were discussing potential opimizations of 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 /
> Poningru, CTho and others were discussing potential opimizations of > 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
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
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.
beltzner wrote: > Poningru, CTho and others were discussing potential opimizations of > 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!
Skree wrote: > 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.
> Skree wrote: >> 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
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).
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,
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.
beltzner wrote: > 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.
Benjamin Smedberg wrote: > 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.
This has always confused me as well. Clicking reload, it seems, 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.
> 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.
Eric Shepherd wrote: > This has always confused me as well. Clicking reload, it seems, > 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, >> 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.
Well, no, it's not dead. I just think that most people clicking the reload button mean "reload" not "pull what you've already got and show it to me again unless magic juju says otherwise." :)
> 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.
> Eric Shepherd wrote: >> This has always confused me as well. Clicking reload, it seems, >> 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, >>> 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.
Chris Hofmann wrote: > 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.
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.
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, > 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 Melez wrote: > 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.
Peter Kasting wrote: > 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...
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.
So I guess switching the behaviour is out of the question, can we still let the user know by making the refresh icon switch to something else when they press the shift key? - Eldo
beltzner wrote: > Poningru, CTho and others were discussing potential opimizations of > 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!
Peter Kasting wrote: > Chris Hofmann wrote: >> 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.
> 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
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.
> 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 wrote: > Bradley schrieb: >> 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.
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.
> 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.
