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

321–330 of 532 posts

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

#321

Post by phkahler »

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…

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

Any other way? Just build a web app with emscripten. You can do anything.

For a while GTK had an HTML5 backend so you could build whole GUI apps for web, but I think it got dropped because nobody used it.

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

#323

Post by phkahler »

socalgal2 wrote: post #173
ryandrake wrote: post #25

Earlier quoted context omitted.

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)

That could be a web app.

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

#324

Post by dspillett »

sidewndr46 wrote: post #292
dspillett wrote: post #191

Earlier quoted context omitted.

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

given the level of hostility most businesses have towards their customers, we should probably be opening links in disposable virtual machines

Or just log all cookies and other localstorage against the domain of the top-level window.location which would achieve most of what a VM would with much lower overhead.

The only problem is that this would break some things like certain SSO systems, so you would have to implement a white-list to allow shared state, and the UX for that would be abused to nag users to whitelist everything. Most people would just click “OK” by default like they do with everything else, and those of us with more sense would have a new reason to be irritated by incessant nagging.

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

#325

Post by phkahler »

NoGravitas wrote: post #315
bityard wrote: post #277

As usual, it's a good first step but doesn't go far enough. I don't want my back-button hijacked by _anything_. My issue with back-button hijacking isn't even spam/ads (I use an ad-blocker so I don't see those), but sites that do a "are you sure you want to leave? You haven't even subscribed to our newsletter yet?!"

There's a place for it within SPAs - you want the browser back button to retrace your path through screens in the application, not exit it, unless you are already on the first page. The same would be true for multi-page apps using HTMX or Turbo or something - if you change pages without doing a full page load, you need to push your new URL. The guiding principle is that the browser back button should work as the user…

>> There's a place for it within SPAs - you want the browser back button to retrace your path through screens in the application, not exit it, unless you are already on the first page.

No, You SPA should have it's own back button within the app. My browser back button should get me out of there no matter what.

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

#326

Post by 100721 »

embedding-shape wrote: post #243
_cadp wrote: post #221

Earlier quoted context omitted.

A bug that just coincidentally affects the only reddit visitors that are worth any money?

Just like finally getting rid of r/all on mobile just happens to bury a bunch of political stuff reddit executives and their friends don't agree with

Huh? I exclusively view r/all and its loading fine for me across all devices.

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

#327

Post by 01284a7e »

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…

Can we reach out directly to Reid Hoffman? Or is he too wrapped up doing damage control from being all over the Epstein Files?

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

#328

Post by adithyassekhar »

integralid wrote: post #320
globular-toast wrote: post #211

Earlier quoted context omitted.

LinkedIn is malware and it's frankly embarrassing that we seem to be stuck with it. It's like a mechanic being stuck with a wrench that doesn't just punch you in the face while using it, it opens your toolbox just to come out and punch you randomly.

What do you mean "stuck with it"? I just don't use LinkedIn. Do you need it for job hunting for example?

> Do you need it for job hunting for example?

God I hope you are being funny. Why else would anyone install this crap?

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

#329

Post by Sayrus »

wat10000 wrote: post #289
Sayrus wrote: post #279

Earlier quoted context omitted.

On the other hand, "are you sure you want to exit without saving" is a good use-case. But I'd prefer that to be a setting I can allow for specific site.

Better yet, just save. Storage is cheap and fast these days. The “do you want to save?” idiom is a leftover from the days when a moderately sized document would take a noticeable amount of time to save and eat up a decent chunk of your floppy disk.

An unfinished upload or sync stored locally instead of on the remote can absolutely be an issue. You can look at all the posts about OneDrive and GDrive not actually syncing before confirming to users who then delete their files since they "have been uploaded". Or the user may never open that specific page again or the session will not exist anymore when he comes back.

Browser storage is cheap, but it is not guaranteed to be durable.

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

#330

Post by phkahler »

josephcsible wrote: post #33
mlmonkey wrote: post #29

But the question is: why are sites allowed to hijack the Back Button?!?

So that in single-page applications, it can work intuitively instead of always taking you all the way out of the app.

>> So that in single-page applications, it can work intuitively instead of always taking you all the way out of the app.

Just implement an additional back button on the SPA. This is actually not confusing and is done in some places. Navigation buttons within an SPA are common enough.

Post reply on HN