When I first heard of the APIs that allowed websites to modify browser history it sounded like a huge mistake. I still feel that way to this day.
A new spam policy for “back button hijacking”
371–380 of 532 posts
Re: A new spam policy for “back button hijacking”
#372Earlier 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.
“Borderline unusable” is such a hyperbolic way to describe a fully functional design that doesn’t happen to be responsive. Hacker News must be borderline unusable for you as well then, no?
Re: A new spam policy for “back button hijacking”
#373Ok, 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…
> 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…
I have always done this, although mostly so I don’t have to reload the page I am coming from when I hit the back button.
Re: A new spam policy for “back button hijacking”
#374Earlier quoted context omitted.
Also www.reddit.com is/was doing the same back button hijacking. From google.com visiting a post, then clicking back and you would find yourself on Reddit general feed instead of back to Google.
I'm pretty sure what you're describing is this long-standing bug[1] I've experienced only when using Mobile Safari on Reddit - affecting both old.reddit.com and the (horrible) modern Reddit. It just doesn't happen in other browsers/engines except on iOS. It's especially annoying on an iPad when I tend to use back/forward instead of open-in-new-tab-then-close on iPhone. [1] At least, I hope it's a bug.
For mobile Safari on iOS/iPad, the back button imo is just completely broken. It’s either a bug, or Apple might say I’m ‘holding it wrong’.
One version it just stopped doing its one job correctly and it’s messing with my mental model of how I arrived at each tab. Currently:
Safari iOS: Be on a page, tap hold a link, click Open in new tab, go to new tab. The Back button should be grayed out and isn’t, and clicking it closes the tab. (???)
Chrome iOS: Be on a page, tap hold a link, click Open in new tab, go to new tab. Back button correctly grayed out as the tab has nowhere to go back to.
Re: A new spam policy for “back button hijacking”
#375Great. Can we do ctrl-f search hijacking next. So jarring when websites replace core functionality with their own broken crap because they think they’re special. Some also seem to hijack right click menu now
CTRL+F hijacking is necessary in some cases when apps are not displaying the full text that the user would expect to search. E.g. when there's a 10K-line code file and the UI is not loading the whole thing into DOM, but the user would expect a "find" to search that whole code file.
Browsers can deal with very long documents. Ctrl+F works like a breeze on HTML that's 100K lines long.
Browsers only struggle to run heavy JS frameworks that wrap every line in a dozens of spans with dozens of handlers and mutate it all on every line scrolled.
Re: A new spam policy for “back button hijacking”
#376When I first heard of the APIs that allowed websites to modify browser history it sounded like a huge mistake. I still feel that way to this day.
It only made sense in the SPA way of working. Allowing the history to be updated would allow the browser's default navigation to work. Outside of SPA type of sites, it was only ever going to be abused.
Re: A new spam policy for “back button hijacking”
#377Great. Can we do ctrl-f search hijacking next. So jarring when websites replace core functionality with their own broken crap because they think they’re special. Some also seem to hijack right click menu now
Firefox allows you to bypass right click hijacking by holding shift before pressing right click.
There is also an option in about:config: "dom.event.contextmenu.enabled" set it to false
Re: A new spam policy for “back button hijacking”
#378Great. Can we do ctrl-f search hijacking next. So jarring when websites replace core functionality with their own broken crap because they think they’re special. Some also seem to hijack right click menu now
CTRL+F hijacking is necessary in some cases when apps are not displaying the full text that the user would expect to search. E.g. when there's a 10K-line code file and the UI is not loading the whole thing into DOM, but the user would expect a "find" to search that whole code file.
They can have a search button for that, not hijacking default browser functions. Often I want both kinds of search.
Re: A new spam policy for “back button hijacking”
#379Earlier quoted context omitted.
It's not valid. You went to a page. They said "no, you're actually on the feed," and then immediately navigate you to the page you'd actually intended to visit. This is that they're doing today, and it's terrible. If I go to a URL, I'm NOT going to your homepage feed. I never wanted to go there.
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.
Re: A new spam policy for “back button hijacking”
#380Earlier quoted context omitted.
It's a fix because it completely solves the issue on any site, without requiring changes from LinkedIn or any other actor.
>it completely solves the issue on any site It doesn't solve the problem with Instagram links, which in my experience do the following: 1) Open a new browser tab, with no history. 2) Close the original tab, so I can't easily get back to where I was.
I've noticed that on Instagram, too. Absolutely infuriating.