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

231–240 of 532 posts

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

#231

Post by troupo »

dspillett wrote: post #191
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…

> You get a link from LinkedIn [or such]. 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, […] I've taken to opening anything in a new tab. Closing the tab is my new back button. In an idea world I shouldn't have to, of course, but we live in a world full of disks implementing dark patterns so not an ideal one. Opening in…

> Closing the tab is my new back button.

In Safari if you open a new tab, don't navigate anywhere, and click back, the tab closes and takes you back to the originating page. I've gottent so used to it, I now miss it in any other browser

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

#232

Post by optionalsquid »

arcfour wrote: post #160
optionalsquid wrote: post #106

Earlier quoted context omitted.

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.

That's a good point, though I'm not familiar with the (changes to the) geolocation API you mention. Do you have any recommendations for reading up on that development?

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

#233

Post by shevy-java »

I don't trust Google.

We need to go back to an independent and competent research group designing standards. Right now Google pwns and controls the whole stack (well, not really ALL of it 1:1, but it has a huge influence on everything via the de-facto chrome monopoly).

Remember how Google took out ublock origin. They also lied about this aka "not safe standards" - in reality they don't WANT people to block ads.

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

#234

Post by znort_ »

dspillett wrote: post #191
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…

> You get a link from LinkedIn [or such]. 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, […] I've taken to opening anything in a new tab. Closing the tab is my new back button. In an idea world I shouldn't have to, of course, but we live in a world full of disks implementing dark patterns so not an ideal one. Opening in…

>I've taken to opening anything in a new tab.

this is the way.

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

#235

Post by arielcostas »

Havoc wrote: post #220

Great. Can we do ctrl-f search hijacking next. So jarring when websites replace core functionality with their own broken crap because they think they’re special. Some also seem to hijack right click menu now

Some also hijack the shortcuts to open devtools (like F12), so you have to find the option in the browser menu itself

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

#236

Post by jarek83 »

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…

LinkedIn won't bother - they don't rely on SEO

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

#237

Post by yoz-y »

hnlmorg wrote: post #210
boomskats wrote: post #184

Earlier quoted context omitted.

Sounds like you're referring to some specific examples of poorly implemented apps rather than the concept of SPAs as a whole. For your example, the point of that div soup is that enables behaviours like row/column drag&drop reordering, inline data editing, realtime data syncing and streaming updates, etc. - there is no way to implement that kind of user experience with just html tables. There's also huge benefit to b…

> all of them are side effects of solutions to very real UX problems that couldn't be solved in any other way. Except they had been solved in other ways and the problem was people insisted on using web technologies to emulate those other technologies even when web technologies didn’t support the same primitives. And they chose that path because it was cheaper than using the correct technologies from the outset. And t…

Having done native and web frontends, they are different.

I prefer the capabilities of native frameworks but I prefer the web box model.

Sizing stuff is native frameworks is nice until it isn’t.

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

#238

Post by SCdF »

Ironically the only place I encounter this is using google news, where news sites seem to detect you're in google news (I don't think these same sites do it when I'm just browing normally?), and try to upsell you their other stories before you go back to the main page.

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

#239

Post by friendzis »

boomskats wrote: post #184
TeMPOraL wrote: post #162

Earlier quoted context omitted.

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

Sounds like you're referring to some specific examples of poorly implemented apps rather than the concept of SPAs as a whole. For your example, the point of that div soup is that enables behaviours like row/column drag&drop reordering, inline data editing, realtime data syncing and streaming updates, etc. - there is no way to implement that kind of user experience with just html tables. There's also huge benefit to b…

> rather than the concept of SPAs as a whole.

This is the whole concept of the SPA - make a page behave like multiple pages. The premise itself requires breaking absolutely everything assuming that content is static.

> There's also huge benefit to being able to depend on clientside state. Especially if you want your apps to scale while keeping infra costs minimal.

Um... I'm old enough to remember the initial release of node, where the value proposition was that since you cannot trust client data anyway and have to implement thorough checking both client and server side, why not implement that once.

> I get the frustrations you're talking about, but almost all of them are side effects of solutions to very real UX problems that couldn't be solved in any other way.

Let me introduce you to our lord and savior native app

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

#240

Post by friendzis »

hnlmorg wrote: post #210
boomskats wrote: post #184

Earlier quoted context omitted.

Sounds like you're referring to some specific examples of poorly implemented apps rather than the concept of SPAs as a whole. For your example, the point of that div soup is that enables behaviours like row/column drag&drop reordering, inline data editing, realtime data syncing and streaming updates, etc. - there is no way to implement that kind of user experience with just html tables. There's also huge benefit to b…

> all of them are side effects of solutions to very real UX problems that couldn't be solved in any other way. Except they had been solved in other ways and the problem was people insisted on using web technologies to emulate those other technologies even when web technologies didn’t support the same primitives. And they chose that path because it was cheaper than using the correct technologies from the outset. And t…

> And they chose that path because it was cheaper than using the correct technologies from the outset

No, otherwise they would not need all those hacks. Web stack makes it cheap (fast and easy) to build an MVP, but since the very primitives required to fully implement requirements are not even there, they end up implementing tons of ugly hacks held by duck tape. All because they thought they could iterate fast and cheap.

It's the same story with teams picking any highly dynamic language for an MVP and then implementing half-baked typing on top of it when the project gets out of MVP stage. Otherwise the bug reproduction rate outpaces fixing rate.

Post reply on HN