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

151–160 of 532 posts

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

#151

Post by TeMPOraL »

least wrote: post #113
friendzis wrote: post #100

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.

> It's also a great way to store state so that a user may bookmark or link something directly.

Can you unpack this please? AFAIK history stack is not preserved in the URL, therefore it cannot be preserved in a bookmark or a shared link.

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

#152

Post by TeMPOraL »

consp wrote: post #146
kiddico wrote: post #47

Earlier quoted context omitted.

I've always found that behavior baffling so it's interesting to hear someone using it as intended instead of being frustrated by it.

It used to be a de facto standard in many programs. Since almost no mouse had a scroll wheel, you'd use the space bar or the cursor keys. Spacebar was usually faster, I guess some people still do.

I do this too. The pattern probably dates back to first Unix pagers, or perhaps to the paper era.

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

#153

Post by boomskats »

hnlmorg wrote: post #122
least wrote: post #113

Earlier quoted context omitted.

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.

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

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

#154

Post by jack1243star »

least wrote: post #128
jack1243star wrote: post #56

Earlier quoted context omitted.

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 di…

Thanks for the detailed and thoughtful reply! I agree that in both of the scenarios you mentioned, this API does provide better usability.

I guess what feels wrong to me is the implicitness of this feature, I'm not sure whether clicking on something is going to add to history or not (until the back button breaks, then I really know).

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

#155

Post by vitro »

zozbot234 wrote: post #141
Rygian wrote: post #130

Earlier quoted context omitted.

That's not a fix. It's a workaround.

It's a fix because it completely solves the issue on any site, without requiring changes from LinkedIn or any other actor.

My car leaks oil. So I refill it here and there. This fixes issue with any car maker and does not require action of any other actor.

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

#156

Post by zozbot234 »

TeMPOraL wrote: post #149
marak830 wrote: post #148

Earlier quoted context omitted.

It's a work around to them making changes to deliberately change the expected results of pressing "back"

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”

#157

Post by phoronixrly »

miki123211 wrote: post #134
musicale wrote: post #4

The iron law of web encrapification: every web feature will (if possible) be employed to abuse the user, usually to push advertising.

This is the price we pay for openness and decentralization. On one side, we have Apple giving us great APIs but telling us how to use them. On the other, we have W3C being extremely conservative with what they expose, exactly because of things like this.

This is the price we pay for bloat...

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

#158

Post by arcfour »

hnlmorg wrote: post #122
least wrote: post #113

Earlier quoted context omitted.

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.

As a user, I really don't care about the supposed purity or correctness of a website's tech stack. When I click "back" I want to go back to what I think the previous page was.

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

#160

Post by arcfour »

optionalsquid wrote: post #106
friendzis wrote: post #100

Earlier quoted context omitted.

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

It should be opt-in per website, per feature, because IMO it can be quite useful in some cases. Like clicking back on a slide-show bringing you to the overview page, instead of only going back one slide

Opt in features are a great way to increase user frustration and confusion. See the whole new geolocation API they had to make for browsers since people would perma-deny it reflexively and then complain that geolocation features weren't working.
Post reply on HN