Live data from Hacker News

A new spam policy for “back button hijacking”

developers.google.com

121–130 of 532 posts

Re: A new spam policy for “back button hijacking”

#121

Ok, you can start with LinkedIn, I'll wait... If you are wondering how it works. You get a link from LinkedIn, it's from an email or just a post someone shared. You click on it, the URL loads, and you read the post. When you click the back button, you aren't taken back to wherever you came from. Instead, your LinkedIn feed loads. How did it happen? When you landed on the first link, the URL is replaced with the homep…

Also www.reddit.com is/was doing the same back button hijacking. From google.com visiting a post, then clicking back and you would find yourself on Reddit general feed instead of back to Google.

Re: A new spam policy for “back button hijacking”

#122
post #113

Earlier quoted context omitted.

Nothing loaded from the web should be able to fiddle with any browser behavior, yet here we are.

The History API is pretty useful. It creates a lot of UX improvement opportunities when you're not polluting the stack with unnecessary state changes. It's also a great way to store state so that a user may bookmark or link something directly. It's straight up necessary for SPAs to behave how they should behave, where navigating back takes you back to the previous page. This feels like a reasonable counter-measure.

Yeah but all of this is a symptom of a broader problem rather than reasons why the history API is useful.

SPAs, for example, require so many hacks to work correctly that I often wonder to myself if they’re not really just a colossal mistake that the industry is too blinded to accept.

Re: A new spam policy for “back button hijacking”

#125
post #7

Earlier quoted context omitted.

It really comes down to JavaScript. The web was fine when sites were static HTML, images, and forms with server-side rendering (allowing for forums and blogs).

Did you use the web back in 1995? It was fun, but it also sucked compared to what we have now. Nothing is ever perfect, but I wouldn’t want to go back.

I wrote web pages in 1995. There was actually plenty you could do, but it was all server side driven.

And the ironic thing is you are chatting on a forum that could have easily been built in 1995.

Re: A new spam policy for “back button hijacking”

#126

Ok, you can start with LinkedIn, I'll wait... If you are wondering how it works. You get a link from LinkedIn, it's from an email or just a post someone shared. You click on it, the URL loads, and you read the post. When you click the back button, you aren't taken back to wherever you came from. Instead, your LinkedIn feed loads. How did it happen? When you landed on the first link, the URL is replaced with the homep…

Also www.reddit.com is/was doing the same back button hijacking. From google.com visiting a post, then clicking back and you would find yourself on Reddit general feed instead of back to Google.

I do not see this behaviour on the latest version of Firefox. I do use old.reddit, however.

Re: A new spam policy for “back button hijacking”

#127
post #7

Earlier quoted context omitted.

It really comes down to JavaScript. The web was fine when sites were static HTML, images, and forms with server-side rendering (allowing for forums and blogs).

If JavaScript hadn't been a thing, Flash and JavaApplet would have been far more popular than they were and I really don't appreciate that timeline.

JavaScript didn’t kill Flash a Java. The web becoming cross platform did.

People started browsing on a plethora of devices from the Dreamcast to PDAs. And then Steve Jobs came a long and doubled down on the shift in accessibility. His stance on Flash was probably the only thing I agreed with him on too.

Re: A new spam policy for “back button hijacking”

#128

Earlier quoted context omitted.

What about all the very legitimate uses of programmatically adding history entries?

Please explain the legitimate uses. Not once I have ever encountered a website that does something useful by modifying the behavior of my browsing history.

https://html.spec.whatwg.org/multipage/nav-history-apis.html...

The spec kind of goes into it, but aside from the whole SPAs needing to behave like individual static documents, the big thing is that it's a place to store state. Some of this can be preserved through form actions and anchor tags but some cannot.

Let's say you are on an ecommerce website. It has a page for a shirt you're interested in. That shirt has different variations - color, size, sleeve length, etc.

If you use input elements and a form action, you can save the state that way, and the server redirects the user to the same page but with additional form attributes in the url. You now have a link to that specific variation for you to copy and send to your friend.

Would anyone really ever do that? probably not. More than likely there'd just be an add to cart button. This is serviceable but it's not necessarily great UX.

With the History API you can replace the url with one that will embed the state of the shirt so that when you link it to your friend it is exactly the one you want. Or if you bookmark it to come back to later you can. Or you can bookmark multiple variations without having to interact with the server at all.

Similarly on that web page, you have an image gallery for the shirt. Without History API, maybe You click on a thumbnail and it opens a preview which is a round trip to the server and a hard reload. Then you click next. same thing. new image. then again. and again. and each time you are adding a new item to the history stack. that might be fine or even preferred, but not always! If I want to get back to my shirt, I now have to navigate back several pages because each image has been added to the stack.

If you use the History API, you can add a new url to the stack when you open the image viewer. then as you navigate it, it updates it to point to the specific image, which gives the user the ability to link to that specific image in the gallery. when you're done. If you want to go back you only have to press back once because we weren't polluting the stack with history state with each image change.

Re: A new spam policy for “back button hijacking”

#129

Ok, you can start with LinkedIn, I'll wait... If you are wondering how it works. You get a link from LinkedIn, it's from an email or just a post someone shared. You click on it, the URL loads, and you read the post. When you click the back button, you aren't taken back to wherever you came from. Instead, your LinkedIn feed loads. How did it happen? When you landed on the first link, the URL is replaced with the homep…

The fix is to hold down the back button so the local history shows up, and pick the right page to go back to. Unfortunately, some versions of Chrome and/or Android seem to break this but that's a completely self-inflicted problem.

Re: A new spam policy for “back button hijacking”

#130

Ok, you can start with LinkedIn, I'll wait... If you are wondering how it works. You get a link from LinkedIn, it's from an email or just a post someone shared. You click on it, the URL loads, and you read the post. When you click the back button, you aren't taken back to wherever you came from. Instead, your LinkedIn feed loads. How did it happen? When you landed on the first link, the URL is replaced with the homep…

The fix is to hold down the back button so the local history shows up, and pick the right page to go back to. Unfortunately, some versions of Chrome and/or Android seem to break this but that's a completely self-inflicted problem.

That's not a fix. It's a workaround.
Post reply on HN