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

381–390 of 532 posts

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

#381

Post by teo_zero »

riskable wrote: post #348
boomskats wrote: post #153

Earlier quoted context omitted.

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, 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 app it's showing, or that the computer's power button shuts down the whole OS and not only the program in the foreground.

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.

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

#382

Post by flexagoon »

direwolf20 wrote: post #195
csomar wrote: post #105

Earlier quoted context omitted.

This relates to Chrome, not to search. In regard to search, they have taken a new direction that I don't think is going to change any time soon. Some time in the last 2 years, they started removing any thing that doesn't get significant natural traffic (ie: have a 30 year old user manual for something odd that people only search for once in a while? -> removed). Last few months, I noticed that they will not index any…

Try Marginalia Search but be warned it doesn't index the entire web

Obligatory Kagi mention

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

#383

Post by rat_on_the_run »

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.

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

#384

Post by input_sh »

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?

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.

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

#385

Post by bevr1337 »

phkahler wrote: post #325
NoGravitas wrote: post #315

Earlier quoted context omitted.

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.

How could the user expect consistent behavior from the back button if web apps can no longer leverage it like web sites?

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

#386

Post by blfr »

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.

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

#387

Post by ChrisMarshallNY »

bastawhiz wrote: post #379
ChrisMarshallNY wrote: post #313

Earlier quoted context omitted.

Well, a lot of content, these days, is really data presented in a “window.” You don’t have the old HTML address, anymore. It’s like reading an eBook in a reader. You always use the reader to interpret, format, and present the data. It kind of sticks a spike into the old “each page is a document” model.

The experience you're describing still doesn't need to break the back button. Going back means going back, not closing a window I never opened. If that's an awkward experience, don't build one that works that way.

Fair ‘nuff, and I agree, but would they be able to argue that they never explicitly “broke” the back button?

I remember when JavaScript became a big Web site driver. The arguments against using it to fetch and build content usually included broken back button functionality.

I don’t think a lot of folks really paid much attention to it, though.

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

#388

Post by alienbaby »

embedding-shape wrote: post #361
CDRdude wrote: post #356

Earlier quoted context omitted.

This is available for me on iOS https://old.reddit.com/r/all/

I'm not sure what exact device you're using, but on iPhone 12 Mini, old.reddit.com is borderline unusable, very different experience compared to if you could access r/all like before via the actually usable web+mobile version, a comparison: https://imgur.com/a/AVGjjCN Anyways, the end result has been I don't use reddit at all on the phone, so kind of ended up being good for me anyways.

It's perfectly fine and usable for me. More so than the app or the 'new' Reddit design. I exclusively use the old design.

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

#389

Post by dylan604 »

chongli wrote: post #273
wmf wrote: post #41

Earlier quoted context omitted.

You're not wrong but we've never really tried the combination of modern CSS with no JS. It could produce elegant designs that load really fast... or ad-filled slop but declarative.

Ads don’t work nearly as well without JavaScript for adtech. They’re basically limited to static banners and text ads as well as sponsorships.

Sounds glorious

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

#390

Post by dylan604 »

wmf wrote: post #41
pottertheotter wrote: post #20

Earlier quoted context omitted.

Did you use the web back in 1995? It was fun, but it also sucked compared to what we have now. Nothing is ever perfect, but I wouldn’t want to go back.

You're not wrong but we've never really tried the combination of modern CSS with no JS. It could produce elegant designs that load really fast... or ad-filled slop but declarative.

Yes to the modern CSS. To go as far back as suggested would mean using frames again and table based layouts with 1x1 invisible gifs to use for spacing layouts. Never again!
Post reply on HN