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

481–490 of 532 posts

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

#481

Post by lemoncucumber »

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.

This one drives me nuts. I get it if it’s a single page app, but in many cases right-clicking the same link and choosing “open in new tab” works fine so that’s not the issue.

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

#482

Post by Barbing »

venusenvy47 wrote: post #341
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…

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.

I like Gmail asking me for no reason to stay on the page when I try to leave.

New spam policy for navigate-away blocking, hope that's Google's next article.

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

#483

Post by MrDOS »

xur17 wrote: post #459
raydev wrote: post #453

Earlier quoted context omitted.

If the page is lazy loading content then the local ctrl+f is not going to work, obviously. If you’re hinting at an argument about whether lazy loading content should exist, that’s a separate discussion. In my experience, pages that override ctrl+f do it for a good reason

Even in those cases I'd prefer to just be able to natively search the content that has been lazy loaded. I've run into more than one website where the search functionality they bound to control-f is horrible.

On Firefox, the “Prevent Shortcut Takeover” can be used to prevent websites from binding to Ctrl+F/Cmd+F: https://addons.mozilla.org/en-US/firefox/addon/prevent-short....

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

#484

Post by HappMacDonald »

fluoridation wrote: post #445
pfg_ wrote: post #401

Earlier quoted context omitted.

Usually when I see this from non-spam sites, it's not even pushstate, it's just some page that redirects as soon as it loads. So you press back twice and it goes back -> forwards -> back -> forwards. Disabling pushstate doesn't fix that, it just makes pushstate equivalent to a redirect.

That's relatively easy to work around. Right-clicking on the back button lets you go back several steps at once. I don't know about Chrome, but it does work on Firefox.

AFAICT just holding left-click for half a second has the same effect. That's been my go to since the little triangle dropdown vanished from the back button (checks watch).. uh, some time in the nineties mebe?

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

#485

Post by HappMacDonald »

SquareWheel wrote: post #434
merelysounds wrote: post #393

Looks like there is also a client side solution for that, at least in Firefox; it's possible to prevent a page from modifying browser history: > Open the about:config page in Firefox > Search for "pushstate" > Double-click "browser.history.allowPushState" source: https://superuser.com/a/1688290

Single Page Applications use the History API to create a working back/forward history within the SPA. This will cause you to navigate away on use, and potentially lose data.

Why don't they just use # hash urls for their in-SPA page urls instead? That's what Elm and Elixir LiveView both do.

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

#486

Post by kevincox »

fragmede wrote: post #419
myself248 wrote: post #414

Earlier quoted context omitted.

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.

It's possible but this seems to be quite rare. In my experience it is always just that they think a div with an onclick handler is the same thing as a link.

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

#487

Post by varenc »

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.

I keep a bookmarklet handy that blocks all keypress listeners to disable this stuff. Agreed it's quite annoying! Can share if desired, though pretty straightforward.

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

#488

Post by mrandish »

ohnoesjmr wrote: post #467
mrandish wrote: post #448

Earlier quoted context omitted.

Browser.history.allowPushState was deprecated in Firefox V47 (2016) once they'd restricted the ability of sites to muck with history state via JS. This used to be a pretty big issue but as a daily Firefox user for 20 years, sites changing history state hasn't been a problem in recent memory, so whatever they did works pretty well. But the TFA is about a related issue with a similar symptom, hijacking (or disabling) t…

What about SPAs tho? Some of the state is in the URL, and as the user fills the form, you might push state to undo last step of the form. Does this mean that in this context the user gets thrown to about:blank? That would break tons of websites.

I use all kinds of web apps and forms and have no issues with undo or other features. And the changes Firefox made to prevent malicious JS changing browser history were done in 2016. I don't think it has anything to do with undo within a page and I wouldn't expect the browser back button to replicate undo (ctrl + z).

As for my small UserScript, it has nothing to do with browser history state. It simply forces web site JS to share certain key strokes with my browser, add-ons and scripts instead of swallowing them (and it's easy to include/exclude any site or page).

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

#490

Post by socalgal2 »

krater23 wrote: post #197
socalgal2 wrote: post #173

Earlier quoted context omitted.

So, apparently you don't use google maps (or any other mapping website)

The data that google maps is caching in my browser is more than Google World needed disc space back then. So why not just use Google World for that?

Put your money where your mouth is. Turn off JavaScript. If you ever turn it back on you lose.
Post reply on HN