Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Browser History (2013)

madhatted.com

Post reply on HN
Print view View original

31–40 of 52 posts

Re: Browser History (2013)

#31

Post by kalleboo »

paavokoya wrote: post #24
wtbob wrote: post #9

Earlier quoted context omitted.

Honestly, they shouldn't re-prompt IMHO — they should only do that on a reload — rather, they should just display the page as it was, which is what I expect when I hit back.

I agree. This would greatly frustrate users on quick-feed news sites and social media who are hoping to find that article or post they were just reading to find it now gone because the sites algorithm marked it as 'read'.

I have this problem all the time on YouTube. I'll instinctively click through to subscriptions but when that is loading I'll notice a recommended video that looks interesting. But then hitting back it's gone because YouTube has reshuffled the recommendations

Re: Browser History (2013)

#32

Post by Dylan16807 »

mixonic wrote: post #28

Author here, happy this popped up and to see the HN community thinking through it. A few people have brushed off what I sketched as uninteresting and don't see any issues. I'll try to explain it another way (with three years reflection to help). Single page applications are now quite popular. Most single page apps use a different definition of "back" than browsers do , and there are times when the two treatments conf…

What you describe does not sound like bfcache behavior. Bfcache should make it like you never clicked the link, and create no requests. Did you test this? Is something broken?

Separately, do browsers currently return expired data to AJAX calls? Which ones?

Re: Browser History (2013)

#33

Post by blowski »

zhoujianfu wrote: post #7

The way I've always wished the back button worked is as though I had just opened a new tab (instead of clicking a link/submitting a form), and now I've just closed that tab and once again see the original tab I'd left. I assume this is actually a big reason people use (so many) tabs... the back button doesn't work right! Sigh!

When you open a new tab, the original tab continues to run in the background, but you can't do that for your history.

Imagine a page which shows a number that increments every second the page is loaded. When you open a new tab, it continues to increment. When you go back, should it continue from where you left it, or behave as if it was loaded the whole time? The answer will be different for different sites, and the browser's default behaviour will sometimes be wrong.

Re: Browser History (2013)

#34

Post by Manishearth »

mixonic wrote: post #28

Author here, happy this popped up and to see the HN community thinking through it. A few people have brushed off what I sketched as uninteresting and don't see any issues. I'll try to explain it another way (with three years reflection to help). Single page applications are now quite popular. Most single page apps use a different definition of "back" than browsers do , and there are times when the two treatments conf…

> So the stale API response, with the original names Mary, Robert, John is returned.

This seems like a bug -- if you click back, it should take you to the page you saw before, not an earlier version of it.

AIUI the bfcache doesn't "remember and replay" API requests; it just caches the entire DOM and JS state.

Do you have something that can demonstrate this behavior?

> Because single-page apps control "back" when in the SPA, they do what most developers want. They return to a semantically correct page, showing Mary, Rob (just edited), John. Tons of apps do this. This is not what the browser does.

This is not necessarily what users want (as evidenced by discussions on this post). Many people want the old page, especially if there's information there (form fields, or other state) that might have gotten lost by a misclick. As someone else noted here, the "back = reload page" behavior can be emulated in the bfcache world by back+reload, but if you don't have a bfcache you can't emulate the "don't lose state" behavior that the bfcache gets you.

It seems like a new meaning is being shoehorned into the "back" button, and then you're complaining it doesn't work.

Re: Browser History (2013)

#35

Post by aethertron »

jimjimjim wrote: post #17

I generally want a back button that rewinds time (server side be damned). usually I'll right-mouse-button click + open in new tab on any link instead of just clicking on it. Eventually, like garbage collection, I'll stop, go back to the start of the tabs and close a bunch of them, then go back to what i was looking at. And if I'm on a site that doesn't allow right clicking on a link? well the site had better be impor…

    > I generally want a back button that rewinds time
Me too. But not for the browser. For the OS.

Re: Browser History (2013)

#36

Post by lmm »

rudedogg wrote: post #23
wtbob wrote: post #9

Earlier quoted context omitted.

Honestly, they shouldn't re-prompt IMHO — they should only do that on a reload — rather, they should just display the page as it was, which is what I expect when I hit back.

It would be interesting to see the analytics for this. I've seen the dialog many times, but can't think of a time I resubmitted the form.

I resubmit the form approximately always, FWIW.

Re: Browser History (2013)

#37

Post by Noseshine »

wtbob wrote: post #3

I don't get what he doesn't understand: when the user goes back, the browser is supposed to show the document he saw when he left, as it was when he left it (so long as that view hasn't expired out of the browser's cache completely). This is intuitively what a user expects, right? > Note: if history list mechanisms unnecessarily prevent users from viewing stale resources, this will tend to force service authors to av…

As I read and see this, it is not about normal HTML pages. The issue probably is more important for SPAs.

For example, you post something that increases your total message counter, and the URL is changed (single page app: the page is not reloaded, only modified by Javascript), for example showing the new message (think "forum" as an example). If the user clicks "Back" they may get the page-state with the previous counter value, confusing the user. Ideally you would want the counter to be updated.

One can construct similar scenarios for regular web apps/pages where a new page is loaded, but I think the caching behavior is more out of line for SPAs. It comes down to the web serving as app platform and not just as "HTML pages for reading". You don't expect - in an application (compare behavior of a regular non-web application) - that when you go back the GUI may not reflect current state, in an app it always does, even if you go back to a previous form.

I think there will always be misunderstandings because of people who always think of the original web, a bunch of linked pages, and others who see it as (also) an application platform. The requirements needed for either often are fundamentally or sometimes subtly different. Is it ideal that we have a platform that is supposed to do such extremely different things all in one? Maybe not, but I think we actually managed surprisingly well to reconcile two very different concepts and requirements in the "web platform" thus far.

I think it would be valuable for discussion when authors a) state if they are talking about one or the other kind of web platform use b) consider that the other one that they are not talking about also exists and has equal value.

Re: Browser History (2013)

#38

Post by aethertron »

fredleblanc wrote: post #4
rosstex wrote: post #2

On the desktop, I like having the option to see what a page just looked like, without reloading any data. If I hit the back button, it's usually because something on the previous page caught my attention and I want to find it again. If I want to reload a page, I'll refresh or click on the site logo (in the case of getting to the root of the site).

I hate when I go back and things change. I went back for a reason! But I'm also of the school that wants View Source to view the source that was just downloaded, not re-download a new copy of the source.

Agreed.

I'm even irked when I go back and the ads change.

Re: Browser History (2013)

#40

Post by mixonic »

Manishearth wrote: post #34
mixonic wrote: post #28

Author here, happy this popped up and to see the HN community thinking through it. A few people have brushed off what I sketched as uninteresting and don't see any issues. I'll try to explain it another way (with three years reflection to help). Single page applications are now quite popular. Most single page apps use a different definition of "back" than browsers do , and there are times when the two treatments conf…

> So the stale API response, with the original names Mary, Robert, John is returned. This seems like a bug -- if you click back, it should take you to the page you saw before, not an earlier version of it. AIUI the bfcache doesn't "remember and replay" API requests; it just caches the entire DOM and JS state. Do you have something that can demonstrate this behavior? > Because single-page apps control "back" when in t…

Sorry :-( You are correct. What I described is not be behavior of the bfcache, it is the network behavior described under the heading "In practice". And there is a link there to a server that can help you play with the behavior.

Apologies for using the wrong term and causing confusion.

> This is not necessarily what users want (as evidenced by discussions on this post).

HN not being representative of an average user aside, I don't disagree. My point is that there are two different expectations of what should happen and they can conflict and cause errors.

> you're complaining it doesn't work

I'm really sad you got that impression. I'm fascinated and think this an architectural problem of the web. My post is an attempt to describe the issue and raise awareness.

Post reply on HN