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

411–420 of 532 posts

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

#411

Post by least »

teo_zero wrote: post #381
riskable wrote: post #348

Earlier quoted context omitted.

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

> If you don't manage the history properly in your SPA, pressing the back button could take the user out of the app entirely. Yes. And that should be the default behavior: browser buttons should take you through the browser's history. If you keep a in-app state and want the user to navigate through it, you should provide in-app buttons. Nobody complains that the browser's close button quits the browser instead of the…

> Yes. And that should be the default behavior: browser buttons should take you through the browser's history. If you keep a in-app state and want the user to navigate through it, you should provide in-app buttons.

The Back and Forward buttons on a web browser is the navigation for the web. If you click a link on a static html page it will create a new entry. If you click back, it'll take you back. If you press forward, You will navigate forward.

We should not be creating a secondary set of controls that does the same thing. This is bad UX, bad design, and bad for an accessible web.

> Nobody complains that the browser's close button quits the browser instead of the app it's showing, or that the computer's power button shuts down the whole OS and not only the program in the foreground.

It does close the app it's showing because we have tabs. If you close a tab, it'll close the app that it's showing. If you close the browser, which is made up of many tabs, it closes all of the tabs. Before tabs, if you closed a window, the web page you were on would close as well. It does what is reasonably expected.

If on your web application you have a 'link' to another 'page' where it shows a change in the view, then you'd expect you would be able to press back to go back to what you were just looking at. SPAs that DON'T do that are the ones that are doing a disservice to the user and reasonable navigation expectations.

> Users must be educated. If they have learned that left means "back" and right means "forward", that a star (sometimes a heart) means "remember this for me", and that an underlined checkmark means "download", then understanding the concept of encapsulation shouldn't be too much for them.

They should not have to be 'educated' here. The mental model of using the back and forward buttons to navigate within a webpage is totally fine.

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

#412

Post by SunshineTheCat »

globular-toast wrote: post #211
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 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.

You know what's funny, just the other day I tried to do an "export" of my data from my account.

The option I chose was "profile data" because I wanted to get my whole work history/projects/etc. for a new resume.

The export took several hours.

When I finally downloaded it, it included my name, Email, short description, and my Email address...

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

#413

Post by NetMageSCW »

input_sh wrote: post #384
integralid wrote: post #320

Earlier quoted context omitted.

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

The amount of times I saw a "LinkedIn profile URL" as a required field on job applications outside of LinkedIn is concerning, to say the least.

I think it’s kind of companies to tell you they don’t want applicants.

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

#414

Post by myself248 »

blfr wrote: post #386
rat_on_the_run wrote: post #383

I wish the browsers had a function of disabling all keyboard shortcuts of a website. I binded Ctrl+E to opening a new tab just beside the current tab (built-in hotkey in Brave). It's frustrating to see it changed to something like opening the emoji menu on Discord.

Another one is hijcking ctrl+click (open in the new tab) into mere click (open here). I am shocked how many ecommerce sites do this.

And many of them don't even have a real click action, that I can find. I can't even right-click and manually pick "open in new tab", because the browser doesn't recognize what I'm clicking on as a link.

I agree, ecommerce sites are the place that I most often want to open several items in tabs and decide between them, and the place this function is most often blocked! I wish I could scream at the jerk who implemented this, but that jerk is not among the options of screamable people.

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

#415

Post by [deleted] »

least wrote: post #411
teo_zero wrote: post #381

Earlier quoted context omitted.

> If you don't manage the history properly in your SPA, pressing the back button could take the user out of the app entirely. Yes. And that should be the default behavior: browser buttons should take you through the browser's history. If you keep a in-app state and want the user to navigate through it, you should provide in-app buttons. Nobody complains that the browser's close button quits the browser instead of the…

> Yes. And that should be the default behavior: browser buttons should take you through the browser's history. If you keep a in-app state and want the user to navigate through it, you should provide in-app buttons. The Back and Forward buttons on a web browser is the navigation for the web. If you click a link on a static html page it will create a new entry. If you click back, it'll take you back. If you press forwa…

[deleted]

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

#416

Post by kube-system »

declan_roberts wrote: post #392
rat_on_the_run wrote: post #383

I wish the browsers had a function of disabling all keyboard shortcuts of a website. I binded Ctrl+E to opening a new tab just beside the current tab (built-in hotkey in Brave). It's frustrating to see it changed to something like opening the emoji menu on Discord.

Ctrl+f is a bad offender. No I don't want to use your contextual search. I want to search for this word on this page!

Half of the time those sites also lazy load anyway so whatever you're looking for isn't even in the DOM yet

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

#418

Post by kube-system »

jeffbee wrote: post #314
Bombthecat wrote: post #207

Earlier quoted context omitted.

News sites are doing it too. Displaying a full display ad when you try to leave

I would just like to point out that this was one of the things that the AMP straightjacket prevented. The whole online news industry has conclusively demonstrated that it can't be trusted with javascript and must be hospitalized, but they refuse to acknowledge their own illness.

Is it news sites fault or is it the fault of web standards/browser developers for failing to build any viable mechanisms for monetizing content?

The issue is hardly isolated to news outlets. It's endemic to the web.

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

#419

Post by fragmede »

myself248 wrote: post #414
blfr wrote: post #386

Earlier quoted context omitted.

Another one is hijcking ctrl+click (open in the new tab) into mere click (open here). I am shocked how many ecommerce sites do this.

And many of them don't even have a real click action, that I can find. I can't even right-click and manually pick "open in new tab", because the browser doesn't recognize what I'm clicking on as a link. I agree, ecommerce sites are the place that I most often want to open several items in tabs and decide between them, and the place this function is most often blocked! I wish I could scream at the jerk who implemented…

> the browser doesn't recognize what I'm clicking on as a link.

It's entirely possible the browser itself does, but that the site's JavaScript is (also) overriding the right click handler. There's browser extensions to override their override but having to do that is stupid.

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

#420

Post by layer8 »

dnnddidiej wrote: post #212
layer8 wrote: post #118

Earlier quoted context omitted.

Yeah, no thanks. I want to use my browser’s standard keyboard shortcut to navigate back. And also forward again. And I want to be able to inspect the history listing before I go back or forward. Let the browser do the browsery things. Don’t make SPAs suck even more than they already do.

So when you use a desktop app there is no back button but there is a switch to another app shortcut. Same idea.

There are desktop apps that do provide a navigation history (for example file managers, editors, chat apps), and they generally use the same keyboard and mouse operations as browsers for that. The point is that when an SPA does provide that within a browser, then the user shouldn’t suddenly have to use bespoke UI operations for it.
Post reply on HN