Live data from Hacker News

A new spam policy for “back button hijacking”

developers.google.com

171–180 of 532 posts

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

#171
Great! So they'll fix the back button bugs on YouTube, and return me to the previous set of video recommendations when I use it on the homepage, right? Right? And let me return to the actual site when it detects that I lost the web connection for 0.01 seconds and hides all the content, and I then press the back button?

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

#172

So why don't google just disable the possibility of hijacking the back button in Chrome, to give an example?

In an "application" model rather than a "document" one, like MS Word online or draw.io or similar, there's no clear semantics for "back" but there is a risk of the user losing data if they can navigate away without saving.

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

#173

Earlier quoted context omitted.

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’d go back in a heartbeat. Making the web a software SDK was the worst thing to happen to it.

So, apparently you don't use google maps (or any other mapping website)

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

#174

Earlier quoted context omitted.

It's also not a very effective workaround, because some of the websites in question end up spamming multiple instances of their home page in the history stack.

You can usually address this by going back as far as possible, then holding the button again so more of the history shows up. And IME, it's only really broken sites that have this problem in the first place.

Yes, but that's super annoying and at that point graduates to being a shitty workaround.

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

#175

> Notably, some instances of back button hijacking may originate from the site's ... advertising platform I feel like anything loaded from a third party domain shouldn't be allowed to fiddle with the history stack.

anything loaded from a third party domain shouldn't be allowed to run scripts.

facebook.com does this as a first party site, shit sites trying to squeeze eyeball time from visitors should be put on Google's malware sites list, but apparently those are the best sites nowadays... :/

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

#178

Why not fix this at the browser level? E.g. long or double click on back button = go to previous non-javascript-affected page (I mean by that: last page navigated to in the classical sense, ignoring dynamic histories altered by js and dynamic content)

That wouldn't work because this technique messes with your history. Long press on the button will just show you a list of the previous pages you visited, and all of them will have the same link to the one you're in, with just one at the bottom of the actual URL you came from. But that's so much friction UX-wise.

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

#179
post #105
post #76

That's cool if they can make it work. I don't understand how Google's indexing work anymore. I've had some website very well indexed for years and years which suddenly disappeared from the index with no explanation, even on the Search Console ("visited, not indexed"). Simple blog entries, lightweight pages, no JavaScript, no ads, no bad practices, https enabled, informative content that is linked from elsewhere inclu…

This relates to Chrome, not to search. In regard to search, they have taken a new direction that I don't think is going to change any time soon. Some time in the last 2 years, they started removing any thing that doesn't get significant natural traffic (ie: have a 30 year old user manual for something odd that people only search for once in a while? -> removed). Last few months, I noticed that they will not index any…

> This relates to Chrome, not to search.

To me, it appears to relate to search

> Pages that are engaging in back button hijacking may be subject to manual spam actions or automated demotions, which can impact the site's performance in Google Search results.

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

#180

So why don't google just disable the possibility of hijacking the back button in Chrome, to give an example?

In an "application" model rather than a "document" one, like MS Word online or draw.io or similar, there's no clear semantics for "back" but there is a risk of the user losing data if they can navigate away without saving.

This is a consequence of sites being allowed to hijack back in the first place. They can still fix it.

For your use case all you need is the page to get notified so it can save. Remember that on Android your onSaveInstanceState gets called and you have to save your state or lose it.

Post reply on HN