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

A new spam policy for “back button hijacking”

developers.google.com

Post reply on HN
Print view View original

161–170 of 532 posts

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

#161

Post by neya »

zozbot234 wrote: post #129
firefoxd wrote: post #120

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.

The fix is to not to implement anti-user patterns. What you're describing is a loophole around it.

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

#162

Post by TeMPOraL »

boomskats wrote: post #153
hnlmorg wrote: post #122

Earlier quoted context omitted.

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.

Could you provide some examples of the hacks you're referring to?

State management, URL fragment management, reimplementing basic controls...

One that I hate the most is that they first reimplement tabular display with a soup of divs, then because this is slow as a dog, they implement virtualized display, which means they now need to reimplement scrolling, and because this obviously breaks CTRL+F, they end up piling endless hacks to fix that - assuming they bother at all.

The result is a page that struggles to display 100 rows of data. Contrast that with regular HTML, where you can shove 10 000 rows into a table, fully styled, without noticeable performance drop. A "classical" webpage can show couple megabytes worth of data and still be faster and more responsive than typical SPA.

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

#163

Post by zozbot234 »

neya wrote: post #161
zozbot234 wrote: post #129

Earlier quoted context omitted.

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.

The fix is to not to implement anti-user patterns. What you're describing is a loophole around it.

> The fix is to not to implement anti-user patterns.

That's not a fix the user can implement themselves. Holding down the back button is comparatively trivial.

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

#164

Post by concinds »

twism wrote: post #23

Reddit! I'm looking at you?

Those are all weird WebKit issues, and reddit not testing MobileSafari.

It works perfectly on Chrome, if it was intentional they would have broken it on Chrome too.

As always you can count on Apple/Safari team to not give a shit, not try to fix it, not reach out to reddit to ask them to fix it, etc.

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

#165

Post by roygbiv2 »

robotswantdata wrote: post #147
pottertheotter wrote: post #20

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. The BBS and dial up days look cosy Now it’s owned by corporates and everyone is using bloated JS frameworks.

There are still BBS you can access via telnet (and actual dial up if you really want), after the fifth one asks you for your full name, street address and phone Humber it gets a little old.

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

#166

Post by RobotToaster »

andreareina wrote: post #57

> 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”

#167

Post by TeMPOraL »

PhageGenerator wrote: post #60
lamasery wrote: post #11

Earlier quoted context omitted.

IIRC the Azure “portal” does this. Also likes to not record things as navigation events that really feel like they should be. Hitting back on that thing is like hitting the back button on Android, it’s the “I feel lucky” button. Anything could happen.

I think that is because some "pages" are really full screen modals. So the back button does take you back to the previous page, but it looks like you went back two pages (closes modal + goes back). I don't spend too much time in the Azure portal but this behavior is rampant in the Entra admin center.

> full screen modals

Thanks. I never imagined this is a thing, it's an useful addition to my mental model of software components, to explain why back button on web behaves in weird ways for some apps.

But it sure does sound like a dumb pattern on the web.

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

#168

Post by dominicrose »

nottorp wrote: post #159

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

It's not clear what constitutes a hijacking and how they are going to detect it. It may be OK to override the button as long as it's used in the intended way which is to go back. In a single-page application it may not trigger a navigation event.

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

#170

Post by worksonmine »

nottorp wrote: post #159

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

This would break so many websites. There are valid uses for the history API, I often do modals/popups as shareable URLs, and using the back button closes it.
Post reply on HN