Live data from Hacker News

A new spam policy for “back button hijacking”

developers.google.com

341–350 of 532 posts

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

#341

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…

Regarding Google and LinkedIn, I keep complaining to them about a stupid feature of Gmail. If I get an invitation from someone, Gmail puts "accept" as a button in the subject of the email - so if you aren't careful you can accept while you are scrolling through the subject lines. That is just the worst feature to put in their subject line.

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

#342
post #126

Earlier quoted context omitted.

I do not see this behaviour on the latest version of Firefox. I do use old.reddit, however.

Old Reddit doesn't do this, it's the "new" one that pretends to be an app, that does it and host of other stupid/user-hostile shit.

In any case, Reddit lets open links in a new tab in their settings, which resolved the issue for me.

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

#343
post #326

Earlier quoted context omitted.

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.

Even manually typing reddit.com/r/all (or r/All, which was a workaround for a while) in the address bar on iOS Safari redirects you to reddit.com/. Since I'm guessing you're not browsing reddit.com, what client are you using?

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

#344
post #329

Earlier quoted context omitted.

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

That's a good point. You'd want some (overridable) way to block navigating away until the sync completed, or do it in the background. Local storage is pretty easy, remote can get tricky.

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

#345

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?!"

> are you sure you want to leave

I would argue there is a place for this in web-apps. For example I have a SaaS app and I employ this on any form pages where the user has already started to enter information in.

I have considered form persistence so in the event a user goes back to a previous page, realizes it's a mistake and goes forward again, their form state from the previous state is persisted.

But I would like to ask, what would users prefer the behavior be on a form page like this?

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

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

i love it. my mac doesn't have the home row (don't know if that's how that row of buttons is called) so I use spacebar and shift+spacebar as pgdown and pgup when I am reading

>the home row (don't know if that's how that row of buttons is called)

the "home row" is where your fingers start out if you know how to type by touch, and it come from the days of typewriters instead of keyboards.

on a QWERTY keyboard, the home row is ASDFGHJKL; with your fingers resting on ASDF and JKL;

when they teach you to touch type, they say "put your fingers on the home row" and "home is where your fingers always return to."

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

#347
post #7

Earlier quoted context omitted.

It really comes down to JavaScript. The web was fine when sites were static HTML, images, and forms with server-side rendering (allowing for forums and blogs).

The web was not fine. If you wanted to accomplish anything more substantial than reading static content (like an email client that beeps when you get an important email, or a chat app that shows you new messages as they come in), you needed to install a desktop app. That required you to be on the same OS that the app developer supported (goodbye Linux on the desktop), as well as to trust the dev a lot more. We seem t…

Somehow we have cross platform software today that isn't Electron slop. And shoehorning absolutely everything into what used to be a document oriented application, creating this grotesque mutant abomination we have today, has just moved the minefield. How many RCE's has Chromium had?

Also, up until Windows Vista, Microsoft thought that making every account on their OS root by default was an amazing idea, further exacerbating the problem you describe, which I don't deny existed. Software distribution on Windows is still a shit-show today, but I guess there's too much momentum to move to a Linux-style repository. The Microsoft Store is a piss poor attempt.

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

#348

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?

If you don't manage the history properly in your SPA, pressing the back button could take the user out of the app entirely.

If you don't let web developers manage history/state like this, we'd be going back to the inefficient world of, "every forward/back movement loads a whole page." (With lots of unnecessary round trip messages between the client and server while the user waits for everything to load).

Basically, the ability to manage history is a user-centric feature. It makes the experience better for them.

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

#349

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?!"

Spawning a new tab is also hijacking the back-button, and should be disallowed completely. No exceptions. Opening a new tab, or god forbid a window, is messing with client software. Violations should carry a minimum 6 month jail sentence.

Pre-empting the web-mail comment: I know. I don't care.

Post reply on HN