I don't understand how Google's indexing work anymore. I've had some website very well indexed for years and years which suddenly disappeared from the index with no explanation, even on the Search Console ("visited, not indexed"). Simple blog entries, lightweight pages, no JavaScript, no ads, no bad practices, https enabled, informative content that is linked from elsewhere including well indexed websites (some entries even performed well on Reddit).
At the same time, for the past few years I've found Google search to be a less and less reliable tool because the results are less often what I need.
Anyway, let's hope this new policy can improve things a little.
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 anything that seems broad (ie: if similar content exists, they won't index it regardless of your page authority).
Basically, they are turning search into Tiktok. If you try to make a search, you'll notice that now they give precedence to AI overview, Youtube, News stories, Maps, Products, etc. Anything but content.
> Pages that are engaging in back button hijacking may be subject to manual spam actions or automated demotions, which can impact the site's performance in Google Search results.
Good point. Chrome has a “feature” where if your website is google-flagged, it’ll display a danger alert when visiting it. For some reason I confused that with this.
If you're referring to Google Safe Browsing lists, all major browsers check agains the same list. I've managed to get mine listed there and immediately banned on all major browsers.
Not only that but I think Google listens to "cyber security" companies lists and feed from them. My website got in some of these lists (https://www.virustotal.com/gui/url/a4c9f166d2468f5bbb503ec79...) and I had to go through like 6-7 of them to whitelist my domain again. Something about code and input triggered something in some of these list's filters that my website is hacking related.
I'm actually surprised when I hear someone technical say they still use Google Search (the search product specifically - they still reign supreme with Maps, etc). I used to love it, but that was quite a long time ago.
I personally use Brave Search and perplexity for those very rare instances when brave search doesn't instantly find what I am looking for. Literally the only thing I (rarely) miss from google is super-deep support for boolean search operators, but then I just tag a !g (exactly like DDG's brilliant bangs) on the end and that works. (I also tried Kagi and did like it, but didn't find compelling differences over Brave Search, especially compared to brave search's excellent and free AI.)
As I read your comment, I was thinking "Really? Is it that surprising?" Then I remembered you said "someone technical", and no longer am surprised. Although I work with some technical people, I'm also surrounded by fools. Just the other day, I watched someone at work open a new tab to Google search, type "Google" and then click on Google search in the results, bringing them to the same page they had just left. With how quickly they did it, I can only imagine it is muscle memory and they haven't noticed yet that their new tab is Google search, or that this is better somehow.
People just keep pitching Kagi as revolutionary, especially software engineers and people on HN.
I respect a lot of them, people I respect a lot, and I saw people like Jon Gjengset use it. so I gave it a few months of daily use. I just eventually drifted back to Google. The results weren't better for anything I search for. It felt different, but not better in any measurable way. $10/mo for a different feel is a strange value prop.
DuckDuckGo sits in the same spot for me. I want to like it, and I don't think one company should own web search, but when I need to find something Google finds it first. I wish the answer were different, but that's just how things are.
Only in a very pedantic sense. Google definitely sells the service of doing things based on your data. It is, in fact, their biggest and oldest revenue stream.
Counterpoint, Kagi is profitable and it achieved that milestone solely via user subscriptions, so its incentives are aligned with users, and not advertisers.
And I've found it so good that I haven't used Google, except by accident, in the past 18 months.
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.
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
I think I've seen one page override ctrl-f for good reason -- it was a page that lazy loaded literally millions of lines of text that wouldn't have fit into RAM.
Every single other page that does it just wastes my time. It's always a super janky slow implementation that somehow additionally fails to actually search through all the text on the page.
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.
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.
> 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.
why did we even allow this to be overridden in the first place? if you genuinely need that much control, stop shipping a webapp! JS canvas is another thing that really shouldn't exist
The proper way is to have an actual link but to override the behavior to navigate within the SPA. So if you click it, the navigation will be within the SPA but if you ctrl+click it, the browser takes over and opens the underlying link in a new page.
Typical issue is when a developer forgets to make it an actual link, but only inclides the SPA navigation.
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.
I use vimium in Firefox and so my default key bindings are the plug-in ones. I push 't' to create a new tab, for instance. If I want to use the website key bindings I have to to into "insert mode" ('i'), or I opt into specific keys by site.
I do like when websites use ctrl-k -- it means nothing to my plug-in so websites always get it, plus it helps with key binding discovery.
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.
I recently vibe-coded a browser UserScript to ensure certain keys are always passed through to my browser (and any other scripts I'm running). There's also an 'aggressive mode' activated by an assignable hotkey for poorly behaved sites that refuse to pass through any keys.
// ==UserScript==
// @name Key Passthrough 2.0
// @description Ensure specific hotkeys reach userscripts on greedy sites. Ctrl+Shift+/ toggles aggressive mode for sites that swallow keys entirely.
// @run-at document-start
// @include *
// @exclude http://192.168.*
// Always-enabled key codes: 27=Esc, 116=F5 (Refresh), 166=Browser_Back, 167=Browser_Fwd, 191=/
// Other keycodes to consider: 8=BS, 9=Tab, 16/160/161=Shift, 17/162/163=Ctrl, 18=Alt, 37=LArrow, 39=RArrow, 46=Delete, 112=F1
// ==/UserScript==
(function () {
'use strict';
// Keys to passthrough in normal mode.
// Esc, Ctrl, / (191) and Browser nav (166/167) are the core cases.
// F1/F5 included if you have AHK remaps on those.
// Esc included to prevent sites trapping it in overlays.
const PASSTHROUGH_KEYS = new Set([27, 116, 166, 167, 191]);
// Aggressive mode toggle hotkey: Ctrl+Shift+/
const AGGRESSIVE_TOGGLE_CODE = 191;
const REFIRE_FLAG = '_kp_refire';
let aggressiveMode = sessionStorage.getItem('kp_aggressive') === '1';
const logPrefix = '[KeyPassthrough]';
const announce = (msg) => console.log(`${logPrefix} ${msg}`);
if (aggressiveMode) announce('Aggressive mode ON (persisted from earlier in session)');
// --- Normal mode ---
// We're first in the capture chain at document-start.
// For passthrough keys, do nothing — just let the event propagate naturally.
// The site's listeners follow ours in the chain, so we've already won the race.
// --- Aggressive mode ---
// For sites that still swallow keys via stopImmediatePropagation in an
// inline <script> that races document-start: block the site's listeners,
// then re-dispatch a clone after the current call stack clears so our
// userscripts get a clean second shot.
function refire(e) {
// Build a plain init object from the original event
const init = {
key: e.key,
code: e.code,
keyCode: e.keyCode,
which: e.which,
charCode: e.charCode,
ctrlKey: e.ctrlKey,
shiftKey: e.shiftKey,
altKey: e.altKey,
metaKey: e.metaKey,
repeat: e.repeat,
bubbles: true,
cancelable: true,
composed: true,
};
const clone = new KeyboardEvent(e.type, init);
clone[REFIRE_FLAG] = true;
// After current capture/bubble cycle fully completes
setTimeout(() => document.dispatchEvent(clone), 0);
}
function handleKey(e) {
// Ignore our own re-dispatched events
if (e[REFIRE_FLAG]) return;
// Aggressive mode toggle: Ctrl+Shift+/
if (e.ctrlKey && e.shiftKey && e.keyCode === AGGRESSIVE_TOGGLE_CODE) {
aggressiveMode = !aggressiveMode;
sessionStorage.setItem('kp_aggressive', aggressiveMode ? '1' : '0');
announce(`Aggressive mode ${aggressiveMode ? 'ON' : 'OFF'}`);
e.stopImmediatePropagation();
return;
}
if (!PASSTHROUGH_KEYS.has(e.keyCode)) return;
if (aggressiveMode) {
// Block the site from seeing this key, then re-dispatch for our scripts
e.stopImmediatePropagation();
refire(e);
}
// Normal mode: do nothing, let event propagate naturally
}
document.addEventListener('keydown', handleKey, true);
document.addEventListener('keyup', handleKey, true);
})();
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?
On qutebrowser I type 2H instead of H, and it doesn't go to the most recent history item at all. Mostly though, no, spammy websites still do this, and browser's haven't fixed it.
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) the back button in Chrome browser. This also hasn't been an issue in Firefox in recent memory (kind of shocked to learn it still was until now in Chrome). However, I did have a problem in recent years in Firefox with sites hijacking the Browser_Back keycode and/or hotkey (keycode 166 or Alt+Left Arrow) but I solved it with a small UserScript I posted elsewhere in this thread.
I rarely click the back arrow icon on the interface since I have a three-finger tap on my touchpad assigned to send the Browser_Back keycode when the active window is Firefox. Being a keycode, this can be intercepted by site JS. While sites intercepting Browser_Back (keycode 166) is rare, some video players use the arrow keys to skip forward/back and Alt+Arrow to skip more. Since Firefox uses Alt+Left Arrow as the back hotkey, this can be an issue. I fixed it with a UserScript that prevents sites from blocking certain keycodes. Note: you can also change all Firefox's hotkeys by going to "about:keyboard".
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).
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.
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 homepage first (location.replace(...) doesn't change the browser history). Then the browser history state is pushed to the original link. So it seems like you landed on the home page first then you clicked on a link. When you click the back button, you are taken back to the homepage where your feed entices you to stay longer on LinkedIn.
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.
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?
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.
I'm using an iphone 13, although I prefer to turn sideways and browse in landscape mode. What you consider borderline unusable is just how I prefer to browse reddit.
“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?
> Hacker News must be borderline unusable for you as well then, no?
On my phone? Yes, absolutely, impossible to hit the links correctly even if I zoom in. Both old reddit and HN is "Fully functional" on desktop, agree, but far cry from "fully functional" on my arguably tiny iPhone.
Is that a ios browser difference? I browse hn all the time on my android phone and I didn't think my screen was unusually big. Maybe they implement some different scaling?
I almost solely use HN on my iPhone browser. It works very well and the scaling is well implemented, although it is a little too easy to accidentally fat finger and vote/flag something without realizing it. I actually find the desktop site (on my laptop) to be a bit hard to use due to its narrowness and small font size, but I'm not sure how universal that is.
You and I are very different Reddit users. I don't think I've even seen r/all for at least a decade. I exclusively view Reddit via the old.reddit.com URL in desktop mode with the Reddit Enhancement Suite add-on + uBO + a custom CSS theme. I'm automatically redirected to my 'Subscribed' page showing only the dozen or so niche subreddits I care about, none of which have more than 100k subscribers (most are under 25k). It's glorious... like a time machine to before Reddit enshittified itself and spammers, astro-turfers, shills and influencers took over.
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.
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.
Yeah, and I think it's pretty much impossible to solve.
Look what happened with Netflix. They actually got it right, a reasonable price for a bunch of stuff which would end up appropriated based on demand (they needed to have the disk to rent.) And how you have a bunch of players trying to compete in the space, each with it's exclusive content to try to make you choose them.
And look what's happened with Google's "news". It's more and more and more clickbait. I used to think the answer was a small charge per article, run through some aggregator that tracked payment. But these days we see things designed to get you to open the page, not to actually provide value. Or look at the problems Amazon has had with it's Kindle Unlimited stuff--books designed to game the metrics, groups engaging in read each other's books behavior etc.
Sounds like maybe some prevention against this is already implemented in either particular Android browsers, or ad blockers, maybe even for specific sites?
Just speculating, I can't imagine a reason why they'd implement this especially for Safari.
Other than A/B-testing or trash code that coincidentally doesn't work in all mobile browsers.
Maybe they use the same AI that generates their fictious relationship stories to add these dark patterns to their code base :D
My understanding is that Apple keeps Safari fairly broken and doesn't care to implement the Googleverse and leaves a lot of things E_WONTFIX. I have read speculation that broken Safari encourages apps in the App Store.
hm yeah but the History API is not new or exclusive to Google, also my understanding was that the discussion is about the annoyance "working" on iOS Safari, but not on other platforms. Any way, too many variables here.
Even on old.reddit, it breaks the back button. When you navigate back, it usually reloads the entire page you were on and ignores all your collapse actions on conversations.
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.
Actually, it looks like they fixed this problem. I just checked all the messages with the LinkedIn label and I don't see it popping that "hotspot" anymore. The only thing that pops up in the subject line is now "Unsubscribe", so that is really good.
I don't think so. At least not from the inbox, where it happens. I'm not in the message - I'm just dragging on the subject lines to scroll, and these "hotspots" light up on the right portion of the subject.
> 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 a new tab also helps me apply a “do I really care enough to give this reading time?” filter as my browsers are set to not give new tabs focus - if I've not actually looked at that tab after a little time it gets closed without me giving it any attention at all.
Specifically regarding LinkedIn and their family of dark patterns, I possibly should log in and update my status after the recent buy-out. I've not been there since updating my profile after the last change of corporate overlords ~9 years ago. Or I might just log in and close my profile entirely…
When I intentionally want to read something that is what I do. However once in a while I'm scrolling, selecting a window, or some other activity; and I happen to click on a link: instead of whatever action I intended I end up on a new page I didn't want to read (maybe I will want to read it, but I haven't go far enough cognitively to realize that). That is when I want my back button to work - a get out of here back to where I was.
Exactly, it has the potential to make you lose something important, forcing you to dig through browser history to find it again. If it happens to be a long-lived tab, you might be searching for a while if you forgot the name or site you were on.
Or just log all cookies and other localstorage against the domain of the top-level window.location which would achieve most of what a VM would with much lower overhead.
The only problem is that this would break some things like certain SSO systems, so you would have to implement a white-list to allow shared state, and the UX for that would be abused to nag users to whitelist everything. Most people would just click “OK” by default like they do with everything else, and those of us with more sense would have a new reason to be irritated by incessant nagging.
In Safari if you open a new tab, don't navigate anywhere, and click back, the tab closes and takes you back to the originating page. I've gottent so used to it, I now miss it in any other browser
[2] install this one and turn OFF the default: https://greasyfork.org/scripts/4416-open-links-in-current-ta...; add any sites you want to stay in the same tab to the `include` section (e.g. see [0]). Depending on how you browse, this will be a small list.
You can couple this with a tab-memory addon: example-- set [1]-Tabs to 'sleep' after a certain time; that way they're not using resources but still available later.
AND if you decide you're not gonna read those tabs anyway, just manually close them with having to activate them.
This too. Particularly required for broken SPA-style sites that reset when you re-enter instead of properly maintaining their state, or infinite scroll based pages that don't remember where you scrolled to/through.
I am eccentric, née properly insane, which is part of why I have so many tabs left open over my various devices. Sometimes a browser crash that loses some or all that context is a benefit!
Bad design on their part, another reason not to revisit! If a site breaks my workflow I generally stop using the site, rather than changing my workflow.
Though I'm guessing it would work in the cases being discussed in this article & thread: when you are navigating into a site (such as linkedin) from another, rather than following internal links.
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.
Would this actually fall afoul of their new policy, though?
Assume the way that universal links work, is that the site main page is loaded, and some hash is supplied, indicating the page to navigate to from there. That's annoying, but perfectly valid, and may be necessary for sites that establish some kind of context baseline from their landing page.
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.
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.
The fix is to hold down the back button so the local history shows up, and pick the right page to go back to. Unfortunately, some versions of Chrome and/or Android seem to break this but that's a completely self-inflicted problem.
That's a different kind of dysfunction, though. You can address it by copying the link and pasting it in a new tab, or if that's not possible, copying the current page to a new tab and clicking on the link there.
It's also not a very effective workaround, because some of the websites in question end up spamming multiple instances of their home page in the history stack.
You can usually address this by going back as far as possible, then holding the button again so more of the history shows up. And IME, it's only really broken sites that have this problem in the first place.
Because I expect my browser to work for me instead of having memorize workarounds for the new web annoyance of the day.
Clicking "back", noticing that the site broke it, moving the mouse and long-pressing "back" (I normally navigate with a mouse thumb button or a trackpad gesture) is much more annoying than my browser just preventing this from happening in the first place.
The problem is, there are two conceptions of the back button, and the browser only implements one.
One conception is "take me back to the previous screen I was on", one is "take me one level up the hierarchy." They're often but not always the same.
Mac Finder is a perfect example of a program correctly implementing the two. If you're deep in some folder and then press cmd+win+l to go to ~/Downloads, cmd+up will get you to ~/, but cmd+[ will get you back to where you were before, even if this was deep in some network drive, nowhere near ~.
I feel like mobile OSes lean towards "one level up" as the default behavior, while traditional desktop OSes lean more towards tracking your exact path and letting you go back.
Desktop had this solved, on Windows there was and remains a distinction between "back" (history) and "up" (navigation).
Browsers actually used to have hierarchical navigation support, with buttons and all, back in the age of dinosaurs - all one had to do is to set up some meta tags in HTML head section to tell which URL is "prev"/"next"/"up". Alas, this has proven too difficult for web developers, who eventually even forgot web was meant for documents at all, and at some point browsers just hid/removed those buttons since no one was using them anyway.
The "Back" remains, and as 'Arainach wrote, it's only one concept and it's not, and never has been "up one level in the hierarchy".
EDIT:
The accepted/expected standard way for "take me up one level in hierarchy" on the web is for the page itself to display the hierarchy e.g. as breadcrumbs. The standard way to go to top level of the page is through a clickable logo of the page/brand. Neither of those need, or should, involve changing behavior of browser controls.
Those are third party extensions, not browser features, and they're not consistently applied.
Going from an image to a root domain is not a hierarchy and as a pathological data hoarder who has downloaded a lot of images from a lot of sites I don't understand why I'd ever want that feature. It's wild that that's their first example use case on the article.
Similarly, going from page N of results to page 1 isn't "up a level in heirarchy".
Isn't the problem already solved at the browser level? Most (all?) modern browsers support a press/click & hold of the back button to view the back history and quickly jump to any page in that tab's history.
*Edit - I left this in the wrong place, those extensions behave slightly differently.
> one is "take me one level up the hierarchy." They're often but not always the same.
Who expects this behavior? It doesn't make sense. You just want to go back where you were.
Most file browsers I've used wanting to implement going up a level in hierarchy, have an arrow pointing up.
If you reached point B from point A - and you tell someone "I would like to go back", then you are expecting to go back to A. Not some intermediate, arbitrarily chosen point C.
IIRC the Azure “portal” does this. Also likes to not record things as navigation events that really feel like they should be. Hitting back on that thing is like hitting the back button on Android, it’s the “I feel lucky” button. Anything could happen.
I think that is because some "pages" are really full screen modals. So the back button does take you back to the previous page, but it looks like you went back two pages (closes modal + goes back). I don't spend too much time in the Azure portal but this behavior is rampant in the Entra admin center.
Thanks. I never imagined this is a thing, it's an useful addition to my mental model of software components, to explain why back button on web behaves in weird ways for some apps.
But it sure does sound like a dumb pattern on the web.
While we’re making sure that modals are recorded in history so that you can close them with the back button on mobile (e.g. https://svelte.dev/docs/kit/shallow-routing), MSFT can’t be bothered. But when it comes to abusing the very same history API to grab the user’s attention for a bit longer...
This maybe true, but I don’t think a company as large as Microsoft can get a pass. There is no excuse for them not being able to handle a back button properly. They are worth trillions of dollars, run some of the biggest sites on the internet, and defined much of how the web worked for an entire computing era.
They should have their feet held to the fire on this.
I mention it not to excuse Microsoft's sins, but to the contrary to point out that malicious intent as a criteria isn't such a good idea after all, when there are such obvious cases of incompetence and malice being practically indistinguishable.
Microsoft Learn. I first noticed this a couple years ago not long after they changed the url from docs.microsoft.com to learn.microsoft.com. Each time you went from a google search to a learn page it would load, redirect to login.microsoftonline then go back to the learn page. Hitting back in the browser took you back to login.microsoftonline which forwarded you back to the learn page. Hitting back twice in quick succession took you back to the docs page then forwarded you to login.microsoftonline. Easier to close the tab and start again. Maybe it was something to do with the changes to the site to make it more like an online college, as that portion requires signin, but I’m just after first party doco! Dunno if this still happens today but at the time I was browsing docs every other day and it was super frustrating. Note: it only did this if you were already signed in elsewhere, something triggered Microsoft sso check. Similar to if you go to portal.office.com, it is a page that requires sign in and so does the login.microsoftonline redirect to check for active tokens.
I think most checkouts do that, to prevent duplicate payments. Dunno about epic, but I often encounter that mitigated by a dedicated ‘go back to store’ button post-checkout
Are they? This seems about deceptive or malicious content (i.e., redirecting to ads) rather than “something in my history triggers a JS redirect”. I’ve definitely experienced the latter with MS, but never the former.
It seems like Google's policy is unconcerned with the intent of the practice. If a website JS redirect ruins the user experience by breaking the back button, it will be demoted in search results. It doesn't matter whether or not the redirect was meant to be deceptive or malicious, websites shouldn't be ruining the user experience.
> It seems like Google's policy is unconcerned with the intent of the practice.
I'm reading the opposite: "If you're currently using any script or technique that inserts or replaces deceptive or manipulative pages into a user's browser history that [...]"
This is Google. Most likely they will deploy an automatic scanner bot that "supposed to" handle all the edge cases. When it don't work, you will be blamed for not writing your js in the way the bot can understand.
Happened to me yesterday through a link off here. I was already expecting it given the domain, but usually mashing back fast enough does the trick eventually. Not this time. Had to kill the tab.
Probably should have mentioned it, but I was on my phone browser where that option either doesn't exist or isn't surfaced well. A long press on the back button just does the same thing as tapping once, so I'm all out of ideas.
Bold coming from the company who gives me the most confusing “Open in app” prompts that are designed to confuse you and get you to use their app rather than the web
It's amazing how often highly-polished web infrastructure gets put into the trash in pursuit of narrow objectives like avoiding a full page load. Very few applications actually benefit from being a single page. You tend to lose a lot more than you gain in terms of UX.
TIL that this (or rather, the lack of this) is why some pages show that annoying "do you want to resubmit your post" notification, but not others, and the name for it. Thank you!
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?!"
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 expects - you should only mess with the browser history stack to fix any nonsense you did to it in the first place.
>> 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.
Then you lose the benefit of having the current URL actually linking to the resource you are currently viewing. If the app is not properly making use of URL modification and the history API, getting back to where you were requires navigating the whole maze each time.
I use a couple of web apps that have this. It's frustrating, because muscle memory has me clicking the browser back button instead of the back button in the app. So that probably takes me back to the front page of the app, or out of it entirely, which is not what I wanted at all.
On the other hand, "are you sure you want to exit without saving" is a good use-case. But I'd prefer that to be a setting I can allow for specific site.
That API has quite a few heuristics that protect the user:
(At least on the Chromium browsers that I've tested it with)
1: It fails silently if the user hasn't interacted with the page. (IE, the user needs to "do something" other than scroll, like click or type.) This generally stops most SPAM.
2: The browser detects loops / repeated prompting and has a checkbox to get out of the loop.
---
It was a little jarring the first time I used that API and tested my code with it; but I appreciate the protections. I've come across far too many "salesman putting their foot in the door" usage of it.
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.
But what if you are leaving the page because you changed your mind, and don't wish to save the changes after all? This, for me, is the common case, so i would not want the browser to suddenly commit an unfinished draft.
If you’re worried about losing the old version, it should keep a history. If you want to erase the new version, there should be an explicit action to do that.
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 guaranteed to be durable.
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.
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?
That's very different to sites like tomshardware that pops up a "hey why don't you check out this extra slop you didn't ask for" when you try to navigate away
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.
That's cool if they can make it work.
I don't understand how Google's indexing work anymore. I've had some website very well indexed for years and years which suddenly disappeared from the index with no explanation, even on the Search Console ("visited, not indexed"). Simple blog entries, lightweight pages, no JavaScript, no ads, no bad practices, https enabled, informative content that is linked from elsewhere including well indexed websites (some entries even performed well on Reddit). At the same time, for the past few years I've found Google search to be a less and less reliable tool because the results are less often what I need.
Anyway, let's hope this new policy can improve things a little.
> no ads
There's yer problem....
Google isn't interested in helping people find pages with no ads.
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 anything that seems broad (ie: if similar content exists, they won't index it regardless of your page authority).
Basically, they are turning search into Tiktok. If you try to make a search, you'll notice that now they give precedence to AI overview, Youtube, News stories, Maps, Products, etc. Anything but content.
tl;dr: content is dead in Google search.
> This relates to Chrome, not to search.
To me, it appears to relate to search
> Pages that are engaging in back button hijacking may be subject to manual spam actions or automated demotions, which can impact the site's performance in Google Search results.
Good point. Chrome has a “feature” where if your website is google-flagged, it’ll display a danger alert when visiting it. For some reason I confused that with this.
If you're referring to Google Safe Browsing lists, all major browsers check agains the same list. I've managed to get mine listed there and immediately banned on all major browsers.
Not only that but I think Google listens to "cyber security" companies lists and feed from them. My website got in some of these lists (https://www.virustotal.com/gui/url/a4c9f166d2468f5bbb503ec79...) and I had to go through like 6-7 of them to whitelist my domain again. Something about code and input triggered something in some of these list's filters that my website is hacking related.
[flagged]
What aggravates me is that somewhere at Google headquarters some asshole thinks he's a fucking genius for turning the web into nerfed walled garden
https://www.wheresyoured.at/the-men-who-killed-google/
We know perfectly well who they are.
KPI go up and pats on the back all around
I'm actually surprised when I hear someone technical say they still use Google Search (the search product specifically - they still reign supreme with Maps, etc). I used to love it, but that was quite a long time ago.
I personally use Brave Search and perplexity for those very rare instances when brave search doesn't instantly find what I am looking for. Literally the only thing I (rarely) miss from google is super-deep support for boolean search operators, but then I just tag a !g (exactly like DDG's brilliant bangs) on the end and that works. (I also tried Kagi and did like it, but didn't find compelling differences over Brave Search, especially compared to brave search's excellent and free AI.)
As I read your comment, I was thinking "Really? Is it that surprising?" Then I remembered you said "someone technical", and no longer am surprised. Although I work with some technical people, I'm also surrounded by fools. Just the other day, I watched someone at work open a new tab to Google search, type "Google" and then click on Google search in the results, bringing them to the same page they had just left. With how quickly they did it, I can only imagine it is muscle memory and they haven't noticed yet that their new tab is Google search, or that this is better somehow.
Try Marginalia Search but be warned it doesn't index the entire web
Obligatory Kagi mention
Kagi costs money and isn't that great to begin with
People just keep pitching Kagi as revolutionary, especially software engineers and people on HN.
I respect a lot of them, people I respect a lot, and I saw people like Jon Gjengset use it. so I gave it a few months of daily use. I just eventually drifted back to Google. The results weren't better for anything I search for. It felt different, but not better in any measurable way. $10/mo for a different feel is a strange value prop.
DuckDuckGo sits in the same spot for me. I want to like it, and I don't think one company should own web search, but when I need to find something Google finds it first. I wish the answer were different, but that's just how things are.
>$10/mo for a different feel is a strange value prop.
Thought Kagi would want the strange part to be, say:
"strange to let advertisers cover your monthly search bill, trading your privacy and using Google--we're only ten bucks a month!"
So, pay for peace of mind.
(do recognize $10 is an entire e.g. daily wage for some)
Google doesn't sell your data despite widespread misinformation/conspiracy theories, and I have more confidence in their opsec than Kagi
Only in a very pedantic sense. Google definitely sells the service of doing things based on your data. It is, in fact, their biggest and oldest revenue stream.
This hasn't been our experience; can you please reach out to me with specific examples? My email is in my profile.
Counterpoint, Kagi is profitable and it achieved that milestone solely via user subscriptions, so its incentives are aligned with users, and not advertisers.
And I've found it so good that I haven't used Google, except by accident, in the past 18 months.
Costs money is a good thing. You want to be the customer, not the product.
Kagi is just a front end for Google with extra anti-slop filters. These are useful, and when you pay you become the customer instead of the product.
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!
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
I think I've seen one page override ctrl-f for good reason -- it was a page that lazy loaded literally millions of lines of text that wouldn't have fit into RAM.
Every single other page that does it just wastes my time. It's always a super janky slow implementation that somehow additionally fails to actually search through all the text on the page.
then instead of lazy loading load chunks and paginate it like we used to
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....
[dead]
Half of the time those sites also lazy load anyway so whatever you're looking for isn't even in the DOM yet
And lazy unload, so you can't find it even if you've already scrolled through the whole thing.
I used to hear it called "virtual scroll", and I remember webpages ballooning in RAM when they didn't do it.
the text content of the site is not what is ballooning the RAM.
Yeah, super annoying when that happens. A workaround is to click the address bar (or press ctrl+l unless that's been hijacked too) and then do ctrl+f.
Just use Ctrl+G - it does almost the exact same thing as Ctrl+F
it's asking me for a line number
Ctrl-f for page search and ctrl-k for website search[1].
[1] https://fmhy.net
Agreed. I also like slash / to focus the primary input like on youtube
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.
> 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.
why did we even allow this to be overridden in the first place? if you genuinely need that much control, stop shipping a webapp! JS canvas is another thing that really shouldn't exist
I've installed one of those and it doesn't seem to help in the ecommerce case.
That’s because of React. The React Router is bad and people don’t spend extra time configuring it against its own bugs.
This usually happens in single page apps (SPA):
The proper way is to have an actual link but to override the behavior to navigate within the SPA. So if you click it, the navigation will be within the SPA but if you ctrl+click it, the browser takes over and opens the underlying link in a new page.
Typical issue is when a developer forgets to make it an actual link, but only inclides the SPA navigation.
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.
Rather than outright disabling it, I wish it was a permission the site would have to request.
That way trusted sites that used it responsibly could be given permission, but it could not be used by any random site.
This is the way.
Actually, you can do that with Firefox, either per site or as a global policy.
https://superuser.com/a/1317514
Big thanks for that!
damn!- was sitting in the Fx queue for TEN years: https://bugzilla.mozilla.org/show_bug.cgi?id=380637
I use vimium in Firefox and so my default key bindings are the plug-in ones. I push 't' to create a new tab, for instance. If I want to use the website key bindings I have to to into "insert mode" ('i'), or I opt into specific keys by site.
I do like when websites use ctrl-k -- it means nothing to my plug-in so websites always get it, plus it helps with key binding discovery.
Looking at you ctrl+r in web outlook...I want to reload the page not reply to the email!
Try ctrl shift r
There should be a toggle control near the navigation buttons that toggles between document mode and app mode.
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.
I recently vibe-coded a browser UserScript to ensure certain keys are always passed through to my browser (and any other scripts I'm running). There's also an 'aggressive mode' activated by an assignable hotkey for poorly behaved sites that refuse to pass through any keys.
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
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?
Firefox had it in 2010. I don't remember when IE ditched it.
I haven't had that problem in a while. Did browser vendors already do something about it?
On qutebrowser I type 2H instead of H, and it doesn't go to the most recent history item at all. Mostly though, no, spammy websites still do this, and browser's haven't fixed it.
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) the back button in Chrome browser. This also hasn't been an issue in Firefox in recent memory (kind of shocked to learn it still was until now in Chrome). However, I did have a problem in recent years in Firefox with sites hijacking the Browser_Back keycode and/or hotkey (keycode 166 or Alt+Left Arrow) but I solved it with a small UserScript I posted elsewhere in this thread.
I rarely click the back arrow icon on the interface since I have a three-finger tap on my touchpad assigned to send the Browser_Back keycode when the active window is Firefox. Being a keycode, this can be intercepted by site JS. While sites intercepting Browser_Back (keycode 166) is rare, some video players use the arrow keys to skip forward/back and Alt+Arrow to skip more. Since Firefox uses Alt+Left Arrow as the back hotkey, this can be an issue. I fixed it with a UserScript that prevents sites from blocking certain keycodes. Note: you can also change all Firefox's hotkeys by going to "about:keyboard".
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).
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.
That sounds like a design failure.
Well, yes, but that's why it's behind an about:config flag and users should not enable it without understanding its effects.
It's not, I don't know why you'd think that.
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 homepage first (location.replace(...) doesn't change the browser history). Then the browser history state is pushed to the original link. So it seems like you landed on the home page first then you clicked on a link. When you click the back button, you are taken back to the homepage where your feed entices you to stay longer on LinkedIn.
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.
A bug that just coincidentally affects the only reddit visitors that are worth any money?
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?
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.
I'm using an iphone 13, although I prefer to turn sideways and browse in landscape mode. What you consider borderline unusable is just how I prefer to browse reddit.
“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?
> Hacker News must be borderline unusable for you as well then, no?
On my phone? Yes, absolutely, impossible to hit the links correctly even if I zoom in. Both old reddit and HN is "Fully functional" on desktop, agree, but far cry from "fully functional" on my arguably tiny iPhone.
Is that a ios browser difference? I browse hn all the time on my android phone and I didn't think my screen was unusually big. Maybe they implement some different scaling?
I almost solely use HN on my iPhone browser. It works very well and the scaling is well implemented, although it is a little too easy to accidentally fat finger and vote/flag something without realizing it. I actually find the desktop site (on my laptop) to be a bit hard to use due to its narrowness and small font size, but I'm not sure how universal that is.
It's perfectly fine and usable for me. More so than the app or the 'new' Reddit design. I exclusively use the old design.
https://www.theverge.com/tech/906314/reddit-r-all-deprecatin...
it's dead, per official comment from reddit.
You probably use old.reddit and a legacy app, right?
> I exclusively view r/all...
You and I are very different Reddit users. I don't think I've even seen r/all for at least a decade. I exclusively view Reddit via the old.reddit.com URL in desktop mode with the Reddit Enhancement Suite add-on + uBO + a custom CSS theme. I'm automatically redirected to my 'Subscribed' page showing only the dozen or so niche subreddits I care about, none of which have more than 100k subscribers (most are under 25k). It's glorious... like a time machine to before Reddit enshittified itself and spammers, astro-turfers, shills and influencers took over.
Do you treat every iOS bug this way?
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.
"You're browsing it wrong." This and other bizarre behaviours are why you'll never catch me using the thing.
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.
Yeah, and I think it's pretty much impossible to solve.
Look what happened with Netflix. They actually got it right, a reasonable price for a bunch of stuff which would end up appropriated based on demand (they needed to have the disk to rent.) And how you have a bunch of players trying to compete in the space, each with it's exclusive content to try to make you choose them.
And look what's happened with Google's "news". It's more and more and more clickbait. I used to think the answer was a small charge per article, run through some aggregator that tracked payment. But these days we see things designed to get you to open the page, not to actually provide value. Or look at the problems Amazon has had with it's Kindle Unlimited stuff--books designed to game the metrics, groups engaging in read each other's books behavior etc.
AMP sites listed on Android Assistant routinely messed with back button behavior to trap you.
I wonder if Google will actually de rank them. Maybe a warning first for the big ones?
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.
I don't use old Reddit, and haven't noticed this behaviour either.
Sounds like maybe some prevention against this is already implemented in either particular Android browsers, or ad blockers, maybe even for specific sites?
Just speculating, I can't imagine a reason why they'd implement this especially for Safari.
Other than A/B-testing or trash code that coincidentally doesn't work in all mobile browsers.
Maybe they use the same AI that generates their fictious relationship stories to add these dark patterns to their code base :D
My understanding is that Apple keeps Safari fairly broken and doesn't care to implement the Googleverse and leaves a lot of things E_WONTFIX. I have read speculation that broken Safari encourages apps in the App Store.
hm yeah but the History API is not new or exclusive to Google, also my understanding was that the discussion is about the annoyance "working" on iOS Safari, but not on other platforms. Any way, too many variables here.
I usually find the back button just doesn't work on new Reddit at all.
Even on old.reddit, it breaks the back button. When you navigate back, it usually reloads the entire page you were on and ignores all your collapse actions on conversations.
IIRC Reddit is also doing the same thing on their mobile (Android) app.
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.
Does "accept" support "undo send"?
Actually, it looks like they fixed this problem. I just checked all the messages with the LinkedIn label and I don't see it popping that "hotspot" anymore. The only thing that pops up in the subject line is now "Unsubscribe", so that is really good.
Wow they’re fast! :)
I don't think so. At least not from the inbox, where it happens. I'm not in the message - I'm just dragging on the subject lines to scroll, and these "hotspots" light up on the right portion of the subject.
> 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 a new tab also helps me apply a “do I really care enough to give this reading time?” filter as my browsers are set to not give new tabs focus - if I've not actually looked at that tab after a little time it gets closed without me giving it any attention at all.
Specifically regarding LinkedIn and their family of dark patterns, I possibly should log in and update my status after the recent buy-out. I've not been there since updating my profile after the last change of corporate overlords ~9 years ago. Or I might just log in and close my profile entirely…
When I intentionally want to read something that is what I do. However once in a while I'm scrolling, selecting a window, or some other activity; and I happen to click on a link: instead of whatever action I intended I end up on a new page I didn't want to read (maybe I will want to read it, but I haven't go far enough cognitively to realize that). That is when I want my back button to work - a get out of here back to where I was.
Exactly, it has the potential to make you lose something important, forcing you to dig through browser history to find it again. If it happens to be a long-lived tab, you might be searching for a while if you forgot the name or site you were on.
given the level of hostility most businesses have towards their customers, we should probably be opening links in disposable virtual machines
Or just log all cookies and other localstorage against the domain of the top-level window.location which would achieve most of what a VM would with much lower overhead.
The only problem is that this would break some things like certain SSO systems, so you would have to implement a white-list to allow shared state, and the UX for that would be abused to nag users to whitelist everything. Most people would just click “OK” by default like they do with everything else, and those of us with more sense would have a new reason to be irritated by incessant nagging.
> Closing the tab is my new back button.
In Safari if you open a new tab, don't navigate anywhere, and click back, the tab closes and takes you back to the originating page. I've gottent so used to it, I now miss it in any other browser
>I've taken to opening anything in a new tab.
this is the way.
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.
Many years ago I was 'converted' to browse like that, one of the reasons was just that - to prevent back-button fatfinger.
Here's the setup I use:
[1] install this userscript, keep the default `include` i.e. 'every link": https://greasyfork.org/scripts/12367-open-links-in-new-tab; add to the `exclude` section the sites from [2].
[2] install this one and turn OFF the default: https://greasyfork.org/scripts/4416-open-links-in-current-ta...; add any sites you want to stay in the same tab to the `include` section (e.g. see [0]). Depending on how you browse, this will be a small list.
You can couple this with a tab-memory addon: example-- set [1]-Tabs to 'sleep' after a certain time; that way they're not using resources but still available later.
AND if you decide you're not gonna read those tabs anyway, just manually close them with having to activate them.
[0] https://news.ycombinator.com/item?id=47763404
This too. Particularly required for broken SPA-style sites that reset when you re-enter instead of properly maintaining their state, or infinite scroll based pages that don't remember where you scrolled to/through.
This is the way. People think I am eccentric for the number of tabs I keep open.
I am eccentric, née properly insane, which is part of why I have so many tabs left open over my various devices. Sometimes a browser crash that loses some or all that context is a benefit!
I do that everywhere, but it seems to fail for LinkedIn: they don’t redirect the link if it’s not in the same tab.
Bad design on their part, another reason not to revisit! If a site breaks my workflow I generally stop using the site, rather than changing my workflow.
Though I'm guessing it would work in the cases being discussed in this article & thread: when you are navigating into a site (such as linkedin) from another, rather than following internal links.
Facebook does this as well.
Thanks for explaining how they do it BTW! I didn't really think about it. I just knew it was shitty.
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...
What do you mean "stuck with it"? I just don't use LinkedIn. Do you need it for job hunting for example?
> Do you need it for job hunting for example?
God I hope you are being funny. Why else would anyone install this crap?
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.
What I do is put the link to the job listing in that field. haha, suck to be in HR if you think you're getting my profile info!
I've never seen any ATS that required Linkedin for login, but even having it as an option I've always thought of as weird.
Then again, I have see many an ATS that include Facebook and other slop sites, so welcome to another layer of jobhunting madness.
LinkedIn won't bother - they don't rely on SEO
Would this actually fall afoul of their new policy, though?
Assume the way that universal links work, is that the site main page is loaded, and some hash is supplied, indicating the page to navigate to from there. That's annoying, but perfectly valid, and may be necessary for sites that establish some kind of context baseline from their landing page.
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.
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.
and then if you click the back button again it just reloads the page, trapped in a vicious loop!
Can we reach out directly to Reid Hoffman? Or is he too wrapped up doing damage control from being all over the Epstein Files?
[dead]
The fix is to hold down the back button so the local history shows up, and pick the right page to go back to. Unfortunately, some versions of Chrome and/or Android seem to break this but that's a completely self-inflicted problem.
That's not a fix. It's a workaround.
It's a fix because it completely solves the issue on any site, without requiring changes from LinkedIn or any other actor.
My car leaks oil. So I refill it here and there. This fixes issue with any car maker and does not require action of any other actor.
Yes, it’s a workaround because it doesn’t require anyone to fix the issue.
>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.
That's a different kind of dysfunction, though. You can address it by copying the link and pasting it in a new tab, or if that's not possible, copying the current page to a new tab and clicking on the link there.
I've noticed that on Instagram, too. Absolutely infuriating.
It's a work around to them making changes to deliberately change the expected results of pressing "back"
It's also not a very effective workaround, because some of the websites in question end up spamming multiple instances of their home page in the history stack.
You can usually address this by going back as far as possible, then holding the button again so more of the history shows up. And IME, it's only really broken sites that have this problem in the first place.
Yes, but that's super annoying and at that point graduates to being a shitty workaround.
The fix is to not to implement anti-user patterns. What you're describing is a loophole around it.
> The fix is to not to implement anti-user patterns.
That's not a fix the user can implement themselves. Holding down the back button is comparatively trivial.
Why on Earth would the user be expected to implement a fix for a problem they didn't cause themselves in the first place?
Why the Earth should the user not want to implement a fix/workaround/whatever for a problem they didn't cause themselves but can trivially solve?
Because I expect my browser to work for me instead of having memorize workarounds for the new web annoyance of the day.
Clicking "back", noticing that the site broke it, moving the mouse and long-pressing "back" (I normally navigate with a mouse thumb button or a trackpad gesture) is much more annoying than my browser just preventing this from happening in the first place.
The problem is, there are two conceptions of the back button, and the browser only implements one.
One conception is "take me back to the previous screen I was on", one is "take me one level up the hierarchy." They're often but not always the same.
Mac Finder is a perfect example of a program correctly implementing the two. If you're deep in some folder and then press cmd+win+l to go to ~/Downloads, cmd+up will get you to ~/, but cmd+[ will get you back to where you were before, even if this was deep in some network drive, nowhere near ~.
I feel like mobile OSes lean towards "one level up" as the default behavior, while traditional desktop OSes lean more towards tracking your exact path and letting you go back.
Desktop had this solved, on Windows there was and remains a distinction between "back" (history) and "up" (navigation).
Browsers actually used to have hierarchical navigation support, with buttons and all, back in the age of dinosaurs - all one had to do is to set up some meta tags in HTML head section to tell which URL is "prev"/"next"/"up". Alas, this has proven too difficult for web developers, who eventually even forgot web was meant for documents at all, and at some point browsers just hid/removed those buttons since no one was using them anyway.
The "Back" remains, and as 'Arainach wrote, it's only one concept and it's not, and never has been "up one level in the hierarchy".
EDIT:
The accepted/expected standard way for "take me up one level in hierarchy" on the web is for the page itself to display the hierarchy e.g. as breadcrumbs. The standard way to go to top level of the page is through a clickable logo of the page/brand. Neither of those need, or should, involve changing behavior of browser controls.
> The problem is, there are two conceptions of the back button, and the browser only implements one.
In web browsers, there is only one concept.
There is no concept of "up one level in the heirarchy". If you want that make your own button in your website.
> There is no concept of "up one level in the heirarchy". If you want that make your own button in your website.
https://lifehacker.com/how-to-move-up-one-url-level-in-chrom... *shrug*
> Chrome/Firefox: Ever been reading a site and wish not to go back to the last page you visited, but the last page in that web site's hierarchy?
This statement makes no sense to non-tech people. Most people don't think of sites hierarchically, at least not from a url path perspective.
Those are third party extensions, not browser features, and they're not consistently applied.
Going from an image to a root domain is not a hierarchy and as a pathological data hoarder who has downloaded a lot of images from a lot of sites I don't understand why I'd ever want that feature. It's wild that that's their first example use case on the article.
Similarly, going from page N of results to page 1 isn't "up a level in heirarchy".
Isn't the problem already solved at the browser level? Most (all?) modern browsers support a press/click & hold of the back button to view the back history and quickly jump to any page in that tab's history.
*Edit - I left this in the wrong place, those extensions behave slightly differently.
amazing, took me 5 clicks of the back button to finally get back from that link
Agreed. I remember addons from the XUL Firefox era that did this.
I miss that feature. And that era.
> one is "take me one level up the hierarchy." They're often but not always the same.
Who expects this behavior? It doesn't make sense. You just want to go back where you were. Most file browsers I've used wanting to implement going up a level in hierarchy, have an arrow pointing up.
GNU Info and many Web 1.0 navigation schemes involved a hierarchy which did involve "Next", "Previous", "Up", and "Home" type dimensions.
For example, the Bacula documentation is still online, as a prime example of this: https://www.bacula.org/9.6.x-manuals/en/main/Getting_Started...
Nobody
If you reached point B from point A - and you tell someone "I would like to go back", then you are expecting to go back to A. Not some intermediate, arbitrarily chosen point C.
You're describing 2 different concepts, back and up, not 2 backs
Exactly. It is crazy that they described MacOS finder as doing this correctly when finder has no concept of up, it only has a back.
Command–Up Arrow: Open the folder that contains the current folder. (https://support.apple.com/en-us/102650)
Some Microsoft sites have been very guilty of this. They are the ones that stick in my head in recent memory.
IIRC the Azure “portal” does this. Also likes to not record things as navigation events that really feel like they should be. Hitting back on that thing is like hitting the back button on Android, it’s the “I feel lucky” button. Anything could happen.
I think that is because some "pages" are really full screen modals. So the back button does take you back to the previous page, but it looks like you went back two pages (closes modal + goes back). I don't spend too much time in the Azure portal but this behavior is rampant in the Entra admin center.
> full screen modals
Thanks. I never imagined this is a thing, it's an useful addition to my mental model of software components, to explain why back button on web behaves in weird ways for some apps.
But it sure does sound like a dumb pattern on the web.
While we’re making sure that modals are recorded in history so that you can close them with the back button on mobile (e.g. https://svelte.dev/docs/kit/shallow-routing), MSFT can’t be bothered. But when it comes to abusing the very same history API to grab the user’s attention for a bit longer...
Having used Azure I believe that this is the result of pure, distilled incompetence rather than malicious intent.
This maybe true, but I don’t think a company as large as Microsoft can get a pass. There is no excuse for them not being able to handle a back button properly. They are worth trillions of dollars, run some of the biggest sites on the internet, and defined much of how the web worked for an entire computing era.
They should have their feet held to the fire on this.
Hear, hear.
I mention it not to excuse Microsoft's sins, but to the contrary to point out that malicious intent as a criteria isn't such a good idea after all, when there are such obvious cases of incompetence and malice being practically indistinguishable.
Microsoft Learn. I first noticed this a couple years ago not long after they changed the url from docs.microsoft.com to learn.microsoft.com. Each time you went from a google search to a learn page it would load, redirect to login.microsoftonline then go back to the learn page. Hitting back in the browser took you back to login.microsoftonline which forwarded you back to the learn page. Hitting back twice in quick succession took you back to the docs page then forwarded you to login.microsoftonline. Easier to close the tab and start again. Maybe it was something to do with the changes to the site to make it more like an online college, as that portion requires signin, but I’m just after first party doco! Dunno if this still happens today but at the time I was browsing docs every other day and it was super frustrating. Note: it only did this if you were already signed in elsewhere, something triggered Microsoft sso check. Similar to if you go to portal.office.com, it is a page that requires sign in and so does the login.microsoftonline redirect to check for active tokens.
Epic store makes it impossible to navigate backwards from the checkout on mobile at least. Not sure if it's design or just poor design.
I think most checkouts do that, to prevent duplicate payments. Dunno about epic, but I often encounter that mitigated by a dedicated ‘go back to store’ button post-checkout
Are they? This seems about deceptive or malicious content (i.e., redirecting to ads) rather than “something in my history triggers a JS redirect”. I’ve definitely experienced the latter with MS, but never the former.
It seems like Google's policy is unconcerned with the intent of the practice. If a website JS redirect ruins the user experience by breaking the back button, it will be demoted in search results. It doesn't matter whether or not the redirect was meant to be deceptive or malicious, websites shouldn't be ruining the user experience.
> It seems like Google's policy is unconcerned with the intent of the practice.
I'm reading the opposite: "If you're currently using any script or technique that inserts or replaces deceptive or manipulative pages into a user's browser history that [...]"
This is Google. Most likely they will deploy an automatic scanner bot that "supposed to" handle all the edge cases. When it don't work, you will be blamed for not writing your js in the way the bot can understand.
Happened to me yesterday through a link off here. I was already expecting it given the domain, but usually mashing back fast enough does the trick eventually. Not this time. Had to kill the tab.
In most browsers you can hold the back button for a second and it will let you skip back more than one step.
Probably should have mentioned it, but I was on my phone browser where that option either doesn't exist or isn't surfaced well. A long press on the back button just does the same thing as tapping once, so I'm all out of ideas.
Probably should also mention which phone browser on which phone OS.
Why on earth would I go out of my way to publicise that information in a public forum?
You can right-click on the back button in Firefox to see a list of previous sites to go back to.
Yeah, it’s the same feature, just two different gestures. (And long tap works with Firefox on Android, btw.)
And some websites consume the entire history that a browser displays in that menu
Has definitely happened to me. Especially if I try the "click back a couple times quickly" method first.
> We believe that the user experience comes first
Bold coming from the company who gives me the most confusing “Open in app” prompts that are designed to confuse you and get you to use their app rather than the web
https://mjtsai.com/blog/2024/03/29/those-obnoxious-sign-in-w...
This seems like a good time to advertise the post/redirect/get pattern.
https://en.wikipedia.org/wiki/Post/Redirect/Get
Not strictly about hijacking back navigation but it can make experience less bumpy if you've got form submissions in the middle of the path.
I'm a huge fan of this pattern (and as a greybeard). I honestly wonder if people think about such things this day and age where everything is react.
It's amazing how often highly-polished web infrastructure gets put into the trash in pursuit of narrow objectives like avoiding a full page load. Very few applications actually benefit from being a single page. You tend to lose a lot more than you gain in terms of UX.
There are frameworks that navigate like this. Laravel is the first that comes to mind. I think Django and Spring do this as well.
TIL that this (or rather, the lack of this) is why some pages show that annoying "do you want to resubmit your post" notification, but not others, and the name for it. Thank you!
I initially thought this is for Android.
Which has a long overdue problem of "Tap Back again to exit" type hijacks.
Or feed-based apps (hi Reddit, TikTok, Instagram) refreshing your timeline in hopes you reconsider exiting and keep doomscrolling.
One can only hope…
Same for me! It took me a while staring at the article and wondering why "browser" was mentioned so many times, to realize it was not Android
Was honestly thinking "yeah nice Google, now do it for Android" since the worst offenders are apps (looking at you, Tiktok)
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?!"
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 expects - you should only mess with the browser history stack to fix any nonsense you did to it in the first place.
>> 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.
Then you lose the benefit of having the current URL actually linking to the resource you are currently viewing. If the app is not properly making use of URL modification and the history API, getting back to where you were requires navigating the whole maze each time.
You can regain that benefit by building an actual website instead of a shitty single-page "application"
How could the user expect consistent behavior from the back button if web apps can no longer leverage it like web sites?
I use a couple of web apps that have this. It's frustrating, because muscle memory has me clicking the browser back button instead of the back button in the app. So that probably takes me back to the front page of the app, or out of it entirely, which is not what I wanted at all.
On the other hand, "are you sure you want to exit without saving" is a good use-case. But I'd prefer that to be a setting I can allow for specific site.
That API has quite a few heuristics that protect the user:
(At least on the Chromium browsers that I've tested it with)
1: It fails silently if the user hasn't interacted with the page. (IE, the user needs to "do something" other than scroll, like click or type.) This generally stops most SPAM.
2: The browser detects loops / repeated prompting and has a checkbox to get out of the loop.
---
It was a little jarring the first time I used that API and tested my code with it; but I appreciate the protections. I've come across far too many "salesman putting their foot in the door" usage of it.
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.
But what if you are leaving the page because you changed your mind, and don't wish to save the changes after all? This, for me, is the common case, so i would not want the browser to suddenly commit an unfinished draft.
If you’re worried about losing the old version, it should keep a history. If you want to erase the new version, there should be an explicit action to do that.
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 guaranteed to be durable.
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.
> 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?
That's fine, there's already an API for this: https://developer.mozilla.org/en-US/docs/Web/API/Window/befo...
That's very different to sites like tomshardware that pops up a "hey why don't you check out this extra slop you didn't ask for" when you try to navigate away
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.