A new spam policy for “back button hijacking”
171–180 of 532 posts
Re: A new spam policy for “back button hijacking”
#172So why don't google just disable the possibility of hijacking the back button in Chrome, to give an example?
Re: A new spam policy for “back button hijacking”
#173Earlier 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.
Re: A new spam policy for “back button hijacking”
#174Earlier 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.
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.
Re: A new spam policy for “back button hijacking”
#176Re: A new spam policy for “back button hijacking”
#177Re: A new spam policy for “back button hijacking”
#178Why 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)
Re: A new spam policy for “back button hijacking”
#179That'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…
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”
#180So 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.
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.