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
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.
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 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.
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.
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.
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 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.
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.)
> 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.
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.
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.
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.
“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.
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.
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.
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.
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.
> 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.
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.
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
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.
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.
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...
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.
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
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.
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.
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!
Almost unrelated, but.. I wonder ..if there was an APM intern[1] behind this, or maybe this was this project. Because, this, would have been an excellent one!
[1] I had the fortune to be one myself in June 2012 for the Chrome Team.
An interesting variant of a web phishing attack is to combine the back button hijacking with information that comes from the HTTP referer header. HTTP referer discloses from which website the user is coming from, when the user click the back button, the malicious site can take the user to the site that looks identical (except for the URL), but is attacker controlled.
Ironically the only place I encounter this is using google news, where news sites seem to detect you're in google news (I don't think these same sites do it when I'm just browing normally?), and try to upsell you their other stories before you go back to the main page.
While i agree, the current JS security model rally doesn't allow for distinguishing origin for JS code. Should that ever change, advertisers will just require that you compile their library into the first party js code, negating any benefit from such a security model.
> advertisers will just require that you compile their library into the first party js code, negating any benefit from such a security model.
It will become harder for advertisers to deny responsibility for ads that violate their stated policies if they have to submit the ads ahead of time. Also site operators will need a certain level of technical competence to do this.
More likely, advertisers will need you to insert a "bootloader" that fetches their code and passes it to eval().
Alternatively, they might require you to set up a subdomain with a cname alias pointing to them (or a common CDN), negating any security benefits of such a practice.
> More likely, advertisers will need you to insert a “bootloader” that fetches their code and passes it to eval().
Sounds like legal precedent waiting to be set. “Run our code so that it looks like your code, acts like your code, and has all the same access as your code” seems like it should be a slam dunk if said code ends up doing a Very Bad Thing to your visitors.
But of course that’s assuming common sense, and the law’s relationship with that isn’t always particularly apparent.
There is already plenty of precedent for real-time-served ads which are annoying, or malicious, or install malware; or outright exploit vulnerabilities in the browser.
The advantage would be that I know beforehand, and have the opportunity to test and, possibly, reject, what the advertiser want me to send to someone’s browser.
If it happened browsers started to warn their users about third party JS doing back button history stuff, I have a hunch, that many frontendies would just shrug and tell their visitors: "Oh but for our site it is OK! Just make an exception when your browser asks!" just like we get all kinds of other web BS shoved down our throats. And when the next hyped frontend framework does such some third party integration for "better history functionality" it will become common, leading to skeptics being ridiculed for not trusting sites to handle history.
The History API is pretty useful. It creates a lot of UX improvement opportunities when you're not polluting the stack with unnecessary state changes. It's also a great way to store state so that a user may bookmark or link something directly. It's straight up necessary for SPAs to behave how they should behave, where navigating back takes you back to the previous page.
Yeah but all of this is a symptom of a broader problem rather than reasons why the history API is useful.
SPAs, for example, require so many hacks to work correctly that I often wonder to myself if they’re not really just a colossal mistake that the industry is too blinded to accept.
As a user, I really don't care about the supposed purity or correctness of a website's tech stack. When I click "back" I want to go back to what I think the previous page was.
A building collapsing isn’t the only way people are affected by choices in construction. But if you want to talk about worst case scenarios then I can pick out some examples in IT too:
We constantly see people’s PII leaked on the internet, accounts hacked and money stolen, due to piss poor safeguards in the industry. And that’s without touching on the intentional malpractice of user tracking.
And yes, this is a different issue, but it’s another symptom of the same problem. Tech businesses don’t give a shit, and developers make excuses about how it’s not life or death. Except our bad choices do still negatively affect people’s lives even if we try to convince ourselves it doesn’t.
State management, URL fragment management, reimplementing basic controls...
One that I hate the most is that they first reimplement tabular display with a soup of divs, then because this is slow as a dog, they implement virtualized display, which means they now need to reimplement scrolling, and because this obviously breaks CTRL+F, they end up piling endless hacks to fix that - assuming they bother at all.
The result is a page that struggles to display 100 rows of data. Contrast that with regular HTML, where you can shove 10 000 rows into a table, fully styled, without noticeable performance drop. A "classical" webpage can show couple megabytes worth of data and still be faster and more responsive than typical SPA.
Sounds like you're referring to some specific examples of poorly implemented apps rather than the concept of SPAs as a whole.
For your example, the point of that div soup is that enables behaviours like row/column drag&drop reordering, inline data editing, realtime data syncing and streaming updates, etc. - there is no way to implement that kind of user experience with just html tables.
There's also huge benefit to being able to depend on clientside state. Especially if you want your apps to scale while keeping infra costs minimal.
I get the frustrations you're talking about, but almost all of them are side effects of solutions to very real UX problems that couldn't be solved in any other way.
And to be clear, I'm not saying that people building SPAs when all they needed was a page showing 10,000 rows of static data isn't a problem. It's just a people problem, not an SPA problem.
> all of them are side effects of solutions to very real UX problems that couldn't be solved in any other way.
Except they had been solved in other ways and the problem was people insisted on using web technologies to emulate those other technologies even when web technologies didn’t support the same primitives. And they chose that path because it was cheaper than using the correct technologies from the outset. And thus a thousand hacks were invented because it’s cheaper than doing things properly.
Then along comes Electron, React Native and so on and so forth. And our hacks continue to proliferate, memory usage be damned.
> And they chose that path because it was cheaper than using the correct technologies from the outset
No, otherwise they would not need all those hacks. Web stack makes it cheap (fast and easy) to build an MVP, but since the very primitives required to fully implement requirements are not even there, they end up implementing tons of ugly hacks held by duck tape. All because they thought they could iterate fast and cheap.
It's the same story with teams picking any highly dynamic language for an MVP and then implementing half-baked typing on top of it when the project gets out of MVP stage. Otherwise the bug reproduction rate outpaces fixing rate.
I’ve done both too. And I honestly don’t like the box model.
But I will admit I’ve focused more on desktop than mobile app development. And the thing about sizing stuff is it’s a much easier problem for desktop than mobile apps, which are full screen and you have a multitude of screen sizes and orientations.
>> I get the frustrations you're talking about, but almost all of them are side effects of solutions to very real UX problems that couldn't be solved in any other way.
Any other way? Just build a web app with emscripten. You can do anything.
For a while GTK had an HTML5 backend so you could build whole GUI apps for web, but I think it got dropped because nobody used it.
This is the whole concept of the SPA - make a page behave like multiple pages. The premise itself requires breaking absolutely everything assuming that content is static.
> There's also huge benefit to being able to depend on clientside state. Especially if you want your apps to scale while keeping infra costs minimal.
Um... I'm old enough to remember the initial release of node, where the value proposition was that since you cannot trust client data anyway and have to implement thorough checking both client and server side, why not implement that once.
> I get the frustrations you're talking about, but almost all of them are side effects of solutions to very real UX problems that couldn't be solved in any other way.
Let me introduce you to our lord and savior native app
If you don't manage the history properly in your SPA, pressing the back button could take the user out of the app entirely.
If you don't let web developers manage history/state like this, we'd be going back to the inefficient world of, "every forward/back movement loads a whole page." (With lots of unnecessary round trip messages between the client and server while the user waits for everything to load).
Basically, the ability to manage history is a user-centric feature. It makes the experience better for them.
> If you don't manage the history properly in your SPA, pressing the back button could take the user out of the app entirely.
Yes. And that should be the default behavior: browser buttons should take you through the browser's history. If you keep a in-app state and want the user to navigate through it, you should provide in-app buttons.
Nobody complains that the browser's close button quits the browser instead of the app it's showing, or that the computer's power button shuts down the whole OS and not only the program in the foreground.
Users must be educated. If they have learned that left means "back" and right means "forward", that a star (sometimes a heart) means "remember this for me", and that an underlined checkmark means "download", then understanding the concept of encapsulation shouldn't be too much for them.
> Yes. And that should be the default behavior: browser buttons should take you through the browser's history. If you keep a in-app state and want the user to navigate through it, you should provide in-app buttons.
The Back and Forward buttons on a web browser is the navigation for the web. If you click a link on a static html page it will create a new entry. If you click back, it'll take you back. If you press forward, You will navigate forward.
We should not be creating a secondary set of controls that does the same thing. This is bad UX, bad design, and bad for an accessible web.
> Nobody complains that the browser's close button quits the browser instead of the app it's showing, or that the computer's power button shuts down the whole OS and not only the program in the foreground.
It does close the app it's showing because we have tabs. If you close a tab, it'll close the app that it's showing. If you close the browser, which is made up of many tabs, it closes all of the tabs. Before tabs, if you closed a window, the web page you were on would close as well. It does what is reasonably expected.
If on your web application you have a 'link' to another 'page' where it shows a change in the view, then you'd expect you would be able to press back to go back to what you were just looking at. SPAs that DON'T do that are the ones that are doing a disservice to the user and reasonable navigation expectations.
> Users must be educated. If they have learned that left means "back" and right means "forward", that a star (sometimes a heart) means "remember this for me", and that an underlined checkmark means "download", then understanding the concept of encapsulation shouldn't be too much for them.
They should not have to be 'educated' here. The mental model of using the back and forward buttons to navigate within a webpage is totally fine.
Probably referring to using pushState (part of the History API) to update the URL to a bookmarkable fragment URL, or even to a regular path leading to a created document.
> The new history entry's URL. Note that the browser won't attempt to load this URL after a call to pushState(), but it may attempt to load the URL later, for instance, after the user restarts the browser.
Sure. I'm not speaking about preserving the full history stack in the URL, just storing state. Apologies in advance if my explanation for what I mean is something you already understand.
This can be as simple as having a single checkbox with a checked/unchecked state.
when you load the webpage, the javascript can pull in the url parameters with URLSearchParams (https://developer.mozilla.org/en-US/docs/Web/API/URLSearchPa...). If the url parameter you set is set to 'on' then the checkbox, which is by default unchecked, can be set to on.
You have your checkbox:
<input type="checkbox" id="check">
And then you have your javascript:
const check = document.getElementById('check');
// get state of checkbox from URL parameter
check.checked = new URLSearchParams(location.search).get('state') === 'on';
// add event listener to call history api to alter the URL state.
check.onchange = () => { history.replaceState(null, '', check.checked ? '?state=on' : '?state=off'); };
The history.replaceState() replaces the URL in your history with the one including the URL parameter, so if a user were to bookmark it, it would store that and reload it when they revisit the webpage.
If I used history.pushState(), each time I clicked on the checkbox, a new item would be added to the stack. for a checkbox this is almost certainly a bad idea because your browser history is going to be polluted pretty quickly if you happen to click it multiple times.
pushState can be useful when it matches the user expectations, though, like if it is an SPA and the user clicks on an internal link to another section of the site, they'd expect to be able to go back to the previous page, even though we're still on the same actual html page.
So you would not be preserving the entire history stack. You can sort of do this by encoding state changes into another url parameter, but the behavior isn't entirely consistent between browsers. It also does require, as far as I know, an explicit action from the user for it to actually affect their navigation. So a website couldn't just add 1000 entries to the user's history on load without some explicit interaction on the web page.
Once the user interacts, though, it does seem like it opens up a lot of opportunity to abuse it, intentionally or not. You can asynchronously push thousands of entries into the browser history without blocking interactivity of the site. you can even continue to push state to the URL from other inputs while doing so.
It should be opt-in per website, per feature, because IMO it can be quite useful in some cases. Like clicking back on a slide-show bringing you to the overview page, instead of only going back one slide
> clicking back on a slide-show bringing you to the overview page
That behavior is expected in exactly one case (assuming slides, not the whole presentation, are modeled as a page each): If I navigated to that specific slide from the overview.
In any other scenario, this behavior amounts to breaking my back button, and I'll probably never visit the site again if I have that choice.
Opt in features are a great way to increase user frustration and confusion. See the whole new geolocation API they had to make for browsers since people would perma-deny it reflexively and then complain that geolocation features weren't working.
That's a good point, though I'm not familiar with the (changes to the) geolocation API you mention. Do you have any recommendations for reading up on that development?
> I feel like anything loaded from a third party domain
Unfortunately this would break some libraries for SPA management that people sometimes load from CDNs (external, or under their control but not obviously & unambiguously 1st-party by hostname) instead of the main app/page location. You could argue that this is bad design IMO, and I'd agree, but it is common design so enforcing such a limit will cause enough uproar to not be worth any browser's hassle.
I do like that they follow up this warning with “We encourage site owners to thoroughly review …” - too many site/app owners moan that they don't have control over what their dependencies do as if loading someone else's code absolves them from responsibility for what it does. Making it clear from the outset that this is the site's problem, not the user's, or something that the UA is doing wrong, or the indexer is judging unfairly, is worth the extra wordage.
facebook.com does this as a first party site, shit sites trying to squeeze eyeball time from visitors should be put on Google's malware sites list, but apparently those are the best sites nowadays... :/
There are valid use cases however the issue is rooted in lacking browser APIs.
For instance,
- if you want to do statistics tracking (how many hits your site gets and user journeys)
- You have a widget/iframe system that needs to teardown when the SPA page is navigated away
- etc
The browser does not have a;
globalThis.history.addEventListener('navigate')
So you must monkey patch the history API. It's impractical from a distribution standpoint to embed this code in the page bundle as it's often managed externally and has its own release schedule.
> - if you want to do statistics tracking (how many hits your site gets and user journeys)
You can do all of that server-side and much more reliably at that. The only reason to do any of this tracking client-side is advertisers trusting fake number go up more than sales numbers.
If the navigation simulates what would happen if we follow links to SPA#pos1, SPA#pos2, etc so that if I do two clicks within the SPA, and then hit Back three times I'm back to whatever link I followed to get to the SPA, I guess it's OK and follows user expectations. But if it is used as an excuse to trap the user in the SPA unless they kill the tab, not OK.
> From the browsers perspective those are the same thing though.
If the browser only allows adding at most one history item per click, I should be able to go back to where I entered a given site with at most that many back button clicks.
At a first glance, this doesn't seem crazy hard to implement? I'm probably missing some edge cases, though.
Some browser APIs (such as playing video) are locked behind a user interaction. Do the same for the history API: make it so you can't add any items to history until the user clicks a link, and then you can only add one.
That's not perfect, and it could still be abused, but it might prevent the most common abuses.
>> So that in single-page applications, it can work intuitively instead of always taking you all the way out of the app.
Just implement an additional back button on the SPA. This is actually not confusing and is done in some places. Navigation buttons within an SPA are common enough.
I would like to mention that Google own SPA framework, angular, has redirect routes which effectively do back button hijacking if used, because they add the url you're redirecting from to the history.
CTRL+F hijacking is necessary in some cases when apps are not displaying the full text that the user would expect to search. E.g. when there's a 10K-line code file and the UI is not loading the whole thing into DOM, but the user would expect a "find" to search that whole code file.
Browsers can deal with very long documents. Ctrl+F works like a breeze on HTML that's 100K lines long.
Browsers only struggle to run heavy JS frameworks that wrap every line in a dozens of spans with dozens of handlers and mutate it all on every line scrolled.
This misses the point. Websites are allowed to replace default keyboard shortcuts for a reason. There are only a few exceptions to this, like Ctrl+W. In other words, you can design your website however you want, except to make it more difficult to leave. This is an implementation of the same philosophy.
> When a user clicks the "back" button in the browser, they have a clear expectation: they want to return to the previous page. Back button hijacking breaks this fundamental expectation.
It seems pretty stupid. Instead of expanding the SEO policy bureaucracy to address a situation where a spammer hijacks the back button, the browser should have been designed in the first place to never allow that hijacking to happen. Second best approach is modify it now. While they're at it, they should also make it impossible to hijack the mode one.... oh yes, Google itself does that.
Please explain the legitimate uses. Not once I have ever encountered a website that does something useful by modifying the behavior of my browsing history.
The spec kind of goes into it, but aside from the whole SPAs needing to behave like individual static documents, the big thing is that it's a place to store state. Some of this can be preserved through form actions and anchor tags but some cannot.
Let's say you are on an ecommerce website. It has a page for a shirt you're interested in. That shirt has different variations - color, size, sleeve length, etc.
If you use input elements and a form action, you can save the state that way, and the server redirects the user to the same page but with additional form attributes in the url. You now have a link to that specific variation for you to copy and send to your friend.
Would anyone really ever do that? probably not. More than likely there'd just be an add to cart button. This is serviceable but it's not necessarily great UX.
With the History API you can replace the url with one that will embed the state of the shirt so that when you link it to your friend it is exactly the one you want. Or if you bookmark it to come back to later you can. Or you can bookmark multiple variations without having to interact with the server at all.
Similarly on that web page, you have an image gallery for the shirt. Without History API, maybe You click on a thumbnail and it opens a preview which is a round trip to the server and a hard reload. Then you click next. same thing. new image. then again. and again. and each time you are adding a new item to the history stack. that might be fine or even preferred, but not always! If I want to get back to my shirt, I now have to navigate back several pages because each image has been added to the stack.
If you use the History API, you can add a new url to the stack when you open the image viewer. then as you navigate it, it updates it to point to the specific image, which gives the user the ability to link to that specific image in the gallery. when you're done. If you want to go back you only have to press back once because we weren't polluting the stack with history state with each image change.
Thanks for the detailed and thoughtful reply! I agree that in both of the scenarios you mentioned, this API does provide better usability.
I guess what feels wrong to me is the implicitness of this feature, I'm not sure whether clicking on something is going to add to history or not (until the back button breaks, then I really know).
Youtube doesn't implement a back function. A real back function would take you back to the same page you came from. If you click a video from the Youtube home page, then click the back button, Youtube will regenerate a different home page with different recommendations, losing the potentially interesting set of recommendations you saw before. You are forced to open every link in a new tab if you want true back functionality.
Well, if I wanted to return to the parent screen in a single page application, I'd click on the back button in the app itself. No need to prevent me from back tracking in the exact order of my browsing should I need it.
I especially hate YouTube's implementation, I can never know the true state on my older PC during whatever it's trying to accomplish, often playing audio from a previous video when I backspace out. I resort to opening every link in a new tab.
A browser feature I wasn't aware of for too long: long press the back button, to get a list of recent URLs, allowing you to skip anything trying to hijack the back button.
The most egregious cases of back button hijacking will leave you with a very long list of entries, which is why it's good to see Google taking this seriously. It's annoying and can be outright malicious in many cases on the part of the offending website.
Surely the browser could enforce a limit on a domain, and make sure that the real page you came from (typically the search engine) is prominently displayed.
I understand this is vague on purpose but wish there was more detail. E.g., if I am running a game in a webgl canvas and "back button" has meaning within the game UI which I implement via history states, is my page now going to be demoted? This article doesn't answer that at all.
If it automatically adds something to the history when you visit the page, then yes. If it only adds to the history when the user clicks something, then I would assume it would be fine. Hopefully.
What about map applications which manipulate the history to store the position of the map as users drag and release to make back and forward work to the users expectation in a single page app? It’s not malicious, but will Google flag it?
Took long enough. Maybe I missed it, but I didn’t see them say how invested they are in tackling this. Promoting a rule is one thing, but everything SEO related becomes a cat and mouse game. I don’t have high confidence that this will work.
Seems invested enough to me. Adding this to the anti spam policy means they will list sites using this lower or not at all, when detected. And they use automated and manual detection for such things. Not much more they can do? And should be effective, who employs scam tactics like this is also interested in having visitors.
I use Chrome on my Android and Mac. For a while I've appreciated the seemingly built-in anti-hijacking measure that always does what I expect on the second Back press. (The first Back may pop up a subscription box for example, but the second will always return me to where I came from).
I actually felt that this was a solved problem, so I'm surprised to see so many people still suffer getting stuck in redirect loops.
Wait, how does one website (google.com) know what happens inside my browsing session on another website (bad-blog.com) after I click over? Hmmmmm
This sort of announcement just emphasizes the extent to which Google observes ALL your web browsing behavior, thanks primarily to their eyes inside Chrome browser.
You know those warnings when you install a browser extension, about all the things that extension will be able to see and do? Well so can Chrome itself…
A web crawler reads page content, extracts content and URLs, places them into an index, and then follows links in that index to further build the index and content corpus. Google and others have special crawlers that execute JavaScript to crawl content delivered dynamically.
Crawlers do not use the browser back button or browser history. So the only way Google could observe such problems is by observing live human browsing behavior.
Also, we know from exhibits in the U.S. DOJ trial that Google does use Chrome browsing behavior as a signal in search ranking. It’s not a hypothetical.
Number of times I've looked for something on my phone, gone through to a product page on Amazon but then have had to back out multiple times to get back to the search listing. Sometimes it's previously viewed products, sometimes it's "just" the Amazon home page. It should be one-and-done.
There should be some browser-level enforcement of this. For example, it would seem possible to detect a user frustratingly mashing the back button, and offer a remediation dialog to disable any hackery that's hijacking the back buttons.
It used to be a de facto standard in many programs. Since almost no mouse had a scroll wheel, you'd use the space bar or the cursor keys. Spacebar was usually faster, I guess some people still do.
Still doing that, also in Thunderbird, to scroll through E-Mails and go to the next one when reaching the end (or pressing "n" or "p" for previous). I even use shift + space to go up again. I thought it was very common. Another alternative, maybe a bit more intuitive is using page up and down buttons.
i love it. my mac doesn't have the home row (don't know if that's how that row of buttons is called) so I use spacebar and shift+spacebar as pgdown and pgup when I am reading
They're called the navigation keys. Fn + Up/Down (arrow keys) is PgUp/PgDn, and Fn + Left/Right is Home/End. But of course, those keys are on completely opposite sides of the keyboard, so Space is more convenient.
This is my biggest gripe with modern browsers. Stop fucking with my keyboard. I want my keyboard to control my agent, not some script. No key seems to be safe. The quick-search key (/) is often overriden by "clever" web devs, but not even in a consistent way. Ctrl-K to go to the browser search box is gone. I use emacs keybindings in text boxes, but those can be randomly overriden by scripts (e.g. Ctrl-B might by overridden to make stuff "bold" etc.).
I want to be able to say "Don't let any script have access to these keyboard keys". But apparently that can't be done even with extensions. I've strongly considered forking Firefox to do this, but I know how much effort that would be to maintain.
How hard would it be to write scripts that expose an interface that the user can bind to keys themselves, if they wish to?
It really comes down to JavaScript. The web was fine when sites were static HTML, images, and forms with server-side rendering (allowing for forums and blogs).
Did you use the web back in 1995? It was fun, but it also sucked compared to what we have now. Nothing is ever perfect, but I wouldn’t want to go back.
Geminispace is a very chill place. It’s definitely not a replacement for the web, but if you can handle the compromises, it feels like both the past and the future.
I read epubs, and html pages derived from texinfo and mandoc. When I see websites that just break down when you disable JS (I do it with ublock), I always feel a pang of sadness. Unless you’re Figma, Google doc, or OpenStreetMap…, which rely heavily on local state, JS should only be required for small island of interaction.
I published my first website in 1995 (and while it wasn’t even a little popular, eventually a spammy gay porn site popped up with the exact same joke name, leading to a pretty odd early “what if you search for your own site” experience).
If you put 2026 media players (with modern bandwidth), on the manually curated small-editorial web of ‘95 it’d be amazing.
We used to have desktop apps, these SPA JS monstrosities are the result of MS missing the web then MS missing mobile. Instead of a desktop monopoly where ActiveX could pop up (providing better app experiences in many cases than one would think), we have cross-platform electron monstrosities and fat react apps that suck, are slow, and omfgbbq do they break. And suck. And eat up resources. Copy and paste breaks, scrolling breaks, nav gets hijacked, dark mode overridden.
Netflix, Spotify, MS have apps I see breaking on the regular on prime mainstream hardware. My modern gaming windows laptop, extra juicy GPU for all the LLM and local kubernetes admin, chokes on windows rendering. Windows isn’t just regressing, their entire stack is actively rotting, and all behind fancy web buttons.
Old man yelling at cloud, but: geeeez boys, I want to go back.
There are still BBS you can access via telnet (and actual dial up if you really want), after the fifth one asks you for your full name, street address and phone Humber it gets a little old.
You're not wrong but we've never really tried the combination of modern CSS with no JS. It could produce elegant designs that load really fast... or ad-filled slop but declarative.
Yes to the modern CSS. To go as far back as suggested would mean using frames again and table based layouts with 1x1 invisible gifs to use for spacing layouts. Never again!
JavaScript didn’t kill Flash a Java. The web becoming cross platform did.
People started browsing on a plethora of devices from the Dreamcast to PDAs. And then Steve Jobs came a long and doubled down on the shift in accessibility. His stance on Flash was probably the only thing I agreed with him on too.
Oh, the social media was much, much better. People much more open, tracking didn't exist. All the idiots still thought computers were only a thing for nerds and kids.
If you wanted to accomplish anything more substantial than reading static content (like an email client that beeps when you get an important email, or a chat app that shows you new messages as they come in), you needed to install a desktop app. That required you to be on the same OS that the app developer supported (goodbye Linux on the desktop), as well as to trust the dev a lot more.
We seem to have collectively forgotten the trauma of freeware. Operating an installer in the mid 2000s was much like walking through a minefield; one wrong move, and your computer was infected with crapware that kept changing your home page and search engine. It wasn't just shady apps, mainstream software (I definitely remember uTorrent and Skype doing this) was also guilty. Even updates weren't safe.
I use a desktop mail client. I have always used desktop applications. I have never had any desire to use web mail clients. Likewise for office suite applications. A true desktop spreadsheet, word processor, and slide deck are always superior.
The web as an application platform has always been a half-baked, second class, inferior experience for the user. It has always been about developer convenience at the expense of the user. No thank you!
Somehow we have cross platform software today that isn't Electron slop. And shoehorning absolutely everything into what used to be a document oriented application, creating this grotesque mutant abomination we have today, has just moved the minefield. How many RCE's has Chromium had?
Also, up until Windows Vista, Microsoft thought that making every account on their OS root by default was an amazing idea, further exacerbating the problem you describe, which I don't deny existed. Software distribution on Windows is still a shit-show today, but I guess there's too much momentum to move to a Linux-style repository. The Microsoft Store is a piss poor attempt.
This is the price we pay for openness and decentralization.
On one side, we have Apple giving us great APIs but telling us how to use them. On the other, we have W3C being extremely conservative with what they expose, exactly because of things like this.
This is the price we pay for stuffing browsers with tons of imperative APIs that the browser has no choice but to implement to the letter, since analysing how they are actually used runs afoul of Rice's theorem.
I feel like we need a complete black box layer or something, where a website can send requests to the browser to do something, but never gets any kind of reply, as to whether anything actually happened. But that would limit usefulness of it quickly, I guess.
I've been toying with an idea of creating a JS runtime that tries to run all code two times, one which runs all identifying information inside a runtime that has any network API's stubbed, and another that replaces the identifying info with garbage.
Most likely needs manual quirk code overlays for sites, but it's totally a solvable problem.
Google should probably talk to Microsoft about this because for me they are the biggest offenders with this back button hijacking in their support forums.
It's about time.
Google is doing so much to keep the web usable. They're the only ones with the teeth to back up standards for mobile web load time, max sender spam rates, leaving browser history alone, etc.
One of the worst is TikTok, even as a developer, when someone sends me a TikTok link and I have to visit it, I get stuck in the browser (same with the app but I uninstalled it), and it feels almost device-breaking the way they trap you in.
Is there any click-bait news site that DOESN'T do this? You hit back and land on a list of their click-bait articles and add links instead of the page you expect.
Click on any Youtube video from any web in android. If you press anything that is not the back button immediately, you will loose the option to go back.
So this coming from google... it's funny. Welcome, but funny.
Amazing change, fighting with the back button is my least favorite part of the ad web and a blindspot for ublock. I wonder how Google is going to track this and if SPA style react router sites would be downranked because of the custom back button behavior. I doubt it due to their popularity but I'm curious how they're going to determine what qualifies as spam
I've been kicking around an idea in my head of a modern browser implementing some kind of "hardening" against anti-features. Deviating from the standard, implementing certain architectural features like this WORM history graph, etc. I don't want to ditch javascript entirely as I don't think it's particularly unreasonable as a feature. That being said, I don't want my extensions to be available via a URL query (even if obfuscated like what Firefox does.) I have yet to find a single webpage utilizing scrolljacking where I would care if it was broken and completely unnavigable. I can count on one hand webpages where I felt like input reading was justified, and even then I wouldn't miss them if the facilities which enable input reading were just made completely undefined.
There certainly is a satisfaction that would come from a shit site like linkedin or youtube being reduced to a gibbering mess of exceptions. Scripting is a privilege, and it's a nice one, but abuse of it shouldn't be tolerated. I really don't see a usecase for boiling it down to a binary of allowing the whole gamut of complex programmability web browsers expose, or allowing none of it. I'd rather just draw a line and say "programs that use these features are acceptable, programs that use these ones aren't".
Why not fix this at the browser level? E.g. long or double click on back button = go to previous non-javascript-affected page (I mean by that: last page navigated to in the classical sense, ignoring dynamic histories altered by js and dynamic content)
That wouldn't work because this technique messes with your history. Long press on the button will just show you a list of the previous pages you visited, and all of them will have the same link to the one you're in, with just one at the bottom of the actual URL you came from. But that's so much friction UX-wise.
Double clicking is not a fix because it doubles latency, and more than doubles latency if you don't want to issue page loads that are immediately aborted. Long clicking is such a bizarre anti-feature that I never considered it might exist until I read about it in this HN discussion. Putting touchscreen-specific workarounds for lack of mouse buttons and modifier keys in a traditional GUI app is insanity.
Phew. for a moment there i thought they would start blocking alternate uses of the back button in apps (for like when it means "go back" and when it means "close everything")
I’ll believe that when YouTube gives me the ability to block certain channels versus “not interested” and “don’t recommend channel” buttons that do absolutely nothing close to what I want.
Or a thousand other things, but that one in particular has been top of mind recently.
Really wish this was applied to phone apps. In Android at least, app A linking to app B will FREQUENTLY break the "back" functionality, allowing app B to handle the "back" action instead of doing what every user would expect 100% of the time, which is to go back to app A.
Scroll on Reddit on mobile and click on a link. The comments open in a new tab. Close the tab and the previous tab is also at the link you’ve just closed.
Makes it impossible to browse around and long click to open on a new tab doesn’t solve the issue either.
It's not clear what constitutes a hijacking and how they are going to detect it. It may be OK to override the button as long as it's used in the intended way which is to go back. In a single-page application it may not trigger a navigation event.
In an "application" model rather than a "document" one, like MS Word online or draw.io or similar, there's no clear semantics for "back" but there is a risk of the user losing data if they can navigate away without saving.
This is a consequence of sites being allowed to hijack back in the first place. They can still fix it.
For your use case all you need is the page to get notified so it can save. Remember that on Android your onSaveInstanceState gets called and you have to save your state or lose it.
This would break so many websites. There are valid uses for the history API, I often do modals/popups as shareable URLs, and using the back button closes it.
i wonder if this includes sites that do auto-redirect: A -> B (auto-redirect) -> C
if i'm on page C and go back, page B will take me to page C again. i think this is more about techincal incompetence rather than malicious intent, but still annoying.
Great! So they'll fix the back button bugs on YouTube, and return me to the previous set of video recommendations when I use it on the homepage, right? Right? And let me return to the actual site when it detects that I lost the web connection for 0.01 seconds and hides all the content, and I then press the back button?
Because clicking on a navigation button in a web app is a good reason to window.history.pushState a state that will return the user to the place where they were when they clicked the button.
Clicking the dismiss button on the cookie banner is not a reason to push a state that will show the user a screen full of ads when they try to leave. (Mentioning the cookie banner because AFAIK Chrome requires a "user gesture" before pushState works normally, https://groups.google.com/a/chromium.org/g/blink-dev/c/T8d4_...)
No idea how they actually do it, but I wouldn't be surprised if manual reports and actions play a big role. The policy doesn't need to be enforced reliably as long as it is plausible for reasonably big actors to get caught sooner or later and the consequences of getting caught are business-ruining.
But detecting it on a technical level shouldn't be hard either. Visit the page, take a screenshot, have an AI identify the dismiss button on the cookie/newsletter popups, scroll a bit, click something that looks inactive, check if the URL changes, trigger the back action. Once a suspicious site is identified, put it in the queue for manual review.
The URL does not even need to change, you can pushState with just a JavaScript object, catch the pop and do something like display a modal. (I use this pattern to allow closing fullscreen filter overlays the user opened)
Still, requires user interaction, on any element, once.
So the crawler needs to identify and click most likely the consent/reject button. Which may not even trigger for Googlebot.
So they likely will rely on reports or maybe even Chrome field data.
Field data is a great point - it should be really obvious when people click "back", and many then click back again immediately after (or close the tab, or whatever people do to "escape").
It only made sense in the SPA way of working. Allowing the history to be updated would allow the browser's default navigation to work. Outside of SPA type of sites, it was only ever going to be abused.
How does this work? How can a site inject a totally different site into the history? I thought eg the History API only lets you add to the stack and pop, not modify history?
There's also a replace() method, and trying to limit that to only same origin or already visited URLs seems futile, as the pages hosted there can themselves detect that the user is navigating back and can just forward you in a number of ways.
It's getting very tiring seeing things that could be first-class user defined controls baked in the browser so that you have true agency over the behaviour being done like this
It's like the other thread from before where LinkedIn scans for your extensions, the fact they can do that without prompting for permission from the user is baffling
Cool, now maybe let's do something about all the shit I have to clear out out my face before I can read a simple web page. For example, on this very article I had to click "No thanks" for cookies and then "No thanks" for a survey or something. And then there was an ad at the top for some app that I also closed.
It's like walking into some room and having to swat away a bunch of cobwebs before doing whatever it is you want to do (read some text, basically).
Haha, we had a solution for that, called pop-up blockers. Then when they became very usable, everyone switched to overlays injected with javascript, so they became unblockable.
But thinking of this at this moment, this could be a good use for a locally ran LLM, to get rid of all this crap dynamically. I wonder why Firefox didn't use this as a usecase when they bolted AI on top of Firefox. Maybe it is time for me to check what api FF has for this
I'm waiting for someone to develop an augmented-reality system that detects branded ads or products, compares them against a corporate-ownership database, applies policies chosen by the user, and then adds warning-stripes or censor-bars over things the user has selected against.
It would finally put some teeth behind the myth of the informed consumer, and there would be gloriously absurd court-battles from corporations. ("This is our freedom of speech and commerce, it's essential, if people don't like what we're doing they can vote with their wallets... NOT LIKE THAT STOP USING SPEECH AND COMMERCE!")
It seems like a lot of the APIs that make a website act like an application need to be disabled by default; and some kind of friction needs to exist to enable them.
Edit: I'm not sure what kind of friction is needed, either an expensive review process (that most application developers would complain about but everyone else would roll their eyes) or a reputation system. Maybe someone else can think of a better approach than me?
Popups were dealt in a way that could be useful here, they're only permitted when the user directly generates the interaction that creates the popup (not scripted). The back button could use the same algorithm back in history, only go back to screens that the user directly navigated.
I never understood why browsers ever allowed this in the first place. It's obviously bad. Yeah, yeah there are "reasons" but it's still obviously a bad solution to whatever "problem" they were trying to solve.
> We believe that the user experience comes first.
If by "user" you mean advertisers, sure you do. Everyone else is an asset to extract as much value from as possible. You actively corrupt their experience.
The fact these companies control the web and its major platforms is one of the greatest tragedies of the modern era.
> Notably, some instances of back button hijacking may originate from the site's included libraries or advertising platform. We encourage site owners to thoroughly review their technical implementation...
Hah. In my time working with marketing teams this is highly unlikely to happen. They're allergic to code and they far outnumber everyone else in this space. Their best practices become the standard for everyone else that's uninitiated.
What they will probably do is change that vanity URL showing up on the SERP to point to a landing page that meets the requirements (only if the referer is google). This page will have the link the user wants. It will be dressed up to be as irresistible as possible. This will become the new best practice in the docs for all SEO-related tools. Hell, even google themselves might eventually put that in their docs.
In other words, the user must now click twice to find the page with the back button hijacking. Even sweeter is that the unfettered back button wouldn't have left their domain anyway.
This just sounds like another layer of yet more frustration. Contrary to popular belief, the user will put up with a lot of additional friction if they think they're going somewhere good. This is just an extra click. Most users probably won't even notice the change. If anything there will be propaganda aimed at aspiring web devs and power users telling them to get mad at google for "requiring" landing pages getting in the way of the content (like what happened to amp pages).
We tried a few times. We got as far as gating the ability to push into the "real history stack" [1] behind a user activation (e.g. click). But, it's easy to get the user to click somewhere: just throw up a cookie banner or an "expand to see full article" or similar.
We weren't really able to figure out any technical solution beyond this. It would rely on some sort of classification of clicks as leading to "real" same-document navigations or not.
This can be done reasonably well as long as you're in a cooperative relationship with the website. For example, if you're trying to classify whether a click should emit single-page navigation performance entries for web performance measurement. (See [2].) In such a case, if the browser can get to (say) 99% accuracy by default with good heuristics and provide site owners with guidance on how to annotate or tweak their code for the remaining 1%, you're in good shape.
But if you're in an adversarial relationship with the website, i.e. it's some malicious spammer trying to hijack the back button, then the malicious site will just always go down the 1% path that slips through the browser's heuristics. And you can try playing whack-a-mole with certain code patterns, but it just never ends, and isn't a great use of engineering resources, and is likely to start degrading the experience of well-behaved sites by accident.
So, policy-based solutions make sense to me here.
[1]: "real history stack": by this I mean the user-visible one that is traversed by the browser's back button UI. This is distinct from the programmer-visible one in `navigation.entries()`, traversed by `navigation.back()` or `history.back()`. The browser's back button is explicitly allowed to skip over programmer-visible entries. https://html.spec.whatwg.org/multipage/speculative-loading.h...
Classify history API, canvas etc etc as "webapp" APIs, and have them show a similar dialog to the webcam dialog.
Then I can just click no, and the scripts on the page can't mess around.
Yes Google Maps is great. No, my favorite news site doesn't need that level of access to my browser or machine, it just needs to show some images and text.
The back button itself feels overloaded. There's "go to previous state" and then there's "go to previous origin." In an ideal world when I doubleclick on the back button what I mean is: "get me off of this site, now."
I agree. It may also require some extra work to figure out what the correct previous origin was, but this will also help legitimate cases where sites send you through 10 different redirects before you get to an actual site (looking at you Microsoft login).
SPA legitimately insert pages into the history to hijack the back button to make it seem like the user was actually navigating through a site instead of it being a single page. If there is a bug somewhere that causes it to insert too many of these navigations or add navigations that user doesn't personally think should be navigations I could see it being considered as potentially violating this policy.
If this was about intentional abuse the article would not have had to ask all site operators in existence to audit their entire website for this. Even if some random library does this without your knowledge can violate this.
will google really punish sites for doing this? and if so how do i report a site? i guess i could email the site with the google link and suggest they fix it first
We need to go back to an independent and competent
research group designing standards. Right now Google
pwns and controls the whole stack (well, not really
ALL of it 1:1, but it has a huge influence on everything
via the de-facto chrome monopoly).
Remember how Google took out ublock origin. They also lied
about this aka "not safe standards" - in reality they don't
WANT people to block ads.
Power is taken but also given. It's a dynamic and I agree it's gotten way, way out of hand. It may eventually supress progress and become a real parasitic presence, but we've not reached that point yet (in net terms). Google has been relatively responsible with the power, but cracks have been starting to show. It will get a whole lot worse before it gets better. That is why I embrace vertical integration despite the tremendous cost. Call it the cockroach approach; it allows being partially decoupled from outside fluctuations.
Addition: People underestimate Google's influence. It's easy to forget they de-facto control Firefox, leaving only Apple and Google in control of the Web. Scary, but looking away won't help either. The Americans have been consistently competent with technology since the advent of the transistor right after WW2. They're reaping the benefits of that still to this day. I say that as a European.
But a paywall is a rather useless page, so it shouldn't be shown in search results. Normally, serving Google one page (e.g. a full article) and showing users something else (e.g. a paywall) would be grounds to ban that site forever, but Google built a special exemption for paywalls.
Showing search results that the user can't actually use is user hostile. It's essentially an ad disguised as a search result, with the problem that those ads displace other results that I might actually be able to read.
Of course, if the policy was to not index paywalled content, we might have avoided the paywallization of the Internet. Somehow, decades ago, when the Internet was smaller and there were fewer eyeballs, high quality content could successfully get monetized with non-tracking ads.
Now we have invasive ads that try to profile you, ads that are full of scams because quality control has gone out the window, and yet, somehow, everything needs to be behind a paywall...
Ideally, when I create valuable content I am paid and when I consume valuable content I don't pay. Advertising does this but I hate it so I don't want that. So ideally, there is no way to extract value from me but I am able to extract value from others. I think I would support someone who finds a way to enforce this.
But I am also willing to pay for valuable content an exorbitant amount if it is valuable enough. For instance, for absolutely critical information I might pay 0.79€ a month.
Yeah, no thanks. I want to use my browser’s standard keyboard shortcut to navigate back. And also forward again. And I want to be able to inspect the history listing before I go back or forward.
Let the browser do the browsery things. Don’t make SPAs suck even more than they already do.
There are desktop apps that do provide a navigation history (for example file managers, editors, chat apps), and they generally use the same keyboard and mouse operations as browsers for that. The point is that when an SPA does provide that within a browser, then the user shouldn’t suddenly have to use bespoke UI operations for it.
The idea of Google lecturing anybody about hijacking UI for dark patterns is absurd.
The company that hijacked an open source mobile OS and turned it into a closed source profit machine.
The company that hijacked the web so “accelerated mobile pages” could effect a walled garden.
The company that hijacked a browser and turned it into an anti-privacy tracking system.
It’s like R. Kelly giving a keynote on safeguarding minors.
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
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.
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.
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.
Just use Ctrl+G - it does almost the exact same thing as Ctrl+F
it's asking me for a line number
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.
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.
There should be a toggle control near the navigation buttons that toggles between document mode and app mode.
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
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.
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.
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.
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.
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.
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.
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.)
> 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.
67 67
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
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
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.
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.
This hasn't been our experience; can you please reach out to me with specific examples? My email is in my profile.
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)
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.
“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.
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.
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 wonder if Google will actually de rank them. Maybe a warning first for the big ones?
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.
AMP sites listed on Android Assistant routinely messed with back button behavior to trap you.
I usually find the back button just doesn't work on new Reddit at all.
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.
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.
> 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.
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.
This is the way. People think I am eccentric for the number of tabs I keep open.
>I've taken to opening anything in a new tab.
this is the way.
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.
> 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
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.
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.
LinkedIn won't bother - they don't rely on SEO
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.
Can we reach out directly to Reid Hoffman? Or is he too wrapped up doing damage control from being all over the Epstein Files?
and then if you click the back button again it just reloads the page, trapped in a vicious loop!
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
> 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.
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.
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
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.
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.
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.
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.
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.
> 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!
Finally! (For this feature to be shipped).
Almost unrelated, but.. I wonder ..if there was an APM intern[1] behind this, or maybe this was this project. Because, this, would have been an excellent one!
[1] I had the fortune to be one myself in June 2012 for the Chrome Team.
An interesting variant of a web phishing attack is to combine the back button hijacking with information that comes from the HTTP referer header. HTTP referer discloses from which website the user is coming from, when the user click the back button, the malicious site can take the user to the site that looks identical (except for the URL), but is attacker controlled.
Ironically the only place I encounter this is using google news, where news sites seem to detect you're in google news (I don't think these same sites do it when I'm just browing normally?), and try to upsell you their other stories before you go back to the main page.
> Notably, some instances of back button hijacking may originate from the site's ... advertising platform
I feel like anything loaded from a third party domain shouldn't be allowed to fiddle with the history stack.
While i agree, the current JS security model rally doesn't allow for distinguishing origin for JS code. Should that ever change, advertisers will just require that you compile their library into the first party js code, negating any benefit from such a security model.
> advertisers will just require that you compile their library into the first party js code, negating any benefit from such a security model.
It will become harder for advertisers to deny responsibility for ads that violate their stated policies if they have to submit the ads ahead of time. Also site operators will need a certain level of technical competence to do this.
More likely, advertisers will need you to insert a "bootloader" that fetches their code and passes it to eval().
Alternatively, they might require you to set up a subdomain with a cname alias pointing to them (or a common CDN), negating any security benefits of such a practice.
> More likely, advertisers will need you to insert a “bootloader” that fetches their code and passes it to eval().
Sounds like legal precedent waiting to be set. “Run our code so that it looks like your code, acts like your code, and has all the same access as your code” seems like it should be a slam dunk if said code ends up doing a Very Bad Thing to your visitors.
But of course that’s assuming common sense, and the law’s relationship with that isn’t always particularly apparent.
There is already plenty of precedent for real-time-served ads which are annoying, or malicious, or install malware; or outright exploit vulnerabilities in the browser.
The advantage would be that I know beforehand, and have the opportunity to test and, possibly, reject, what the advertiser want me to send to someone’s browser.
If it happened browsers started to warn their users about third party JS doing back button history stuff, I have a hunch, that many frontendies would just shrug and tell their visitors: "Oh but for our site it is OK! Just make an exception when your browser asks!" just like we get all kinds of other web BS shoved down our throats. And when the next hyped frontend framework does such some third party integration for "better history functionality" it will become common, leading to skeptics being ridiculed for not trusting sites to handle history.
Your parent commenter didn’t suggest asking for permission, they suggested not allowing it, period.
Nothing loaded from the web should be able to fiddle with any browser behavior, yet here we are.
The History API is pretty useful. It creates a lot of UX improvement opportunities when you're not polluting the stack with unnecessary state changes. It's also a great way to store state so that a user may bookmark or link something directly. It's straight up necessary for SPAs to behave how they should behave, where navigating back takes you back to the previous page.
This feels like a reasonable counter-measure.
Yeah but all of this is a symptom of a broader problem rather than reasons why the history API is useful.
SPAs, for example, require so many hacks to work correctly that I often wonder to myself if they’re not really just a colossal mistake that the industry is too blinded to accept.
As a user, I really don't care about the supposed purity or correctness of a website's tech stack. When I click "back" I want to go back to what I think the previous page was.
As a user, I don’t really care about the building materials used in construction. But that doesn’t mean builders should cut corners.
A building collapse and a poorly built website UI are completely different in terms of actual risk.
A building collapsing isn’t the only way people are affected by choices in construction. But if you want to talk about worst case scenarios then I can pick out some examples in IT too:
We constantly see people’s PII leaked on the internet, accounts hacked and money stolen, due to piss poor safeguards in the industry. And that’s without touching on the intentional malpractice of user tracking.
And yes, this is a different issue, but it’s another symptom of the same problem. Tech businesses don’t give a shit, and developers make excuses about how it’s not life or death. Except our bad choices do still negatively affect people’s lives even if we try to convince ourselves it doesn’t.
Could you provide some examples of the hacks you're referring to?
State management, URL fragment management, reimplementing basic controls...
One that I hate the most is that they first reimplement tabular display with a soup of divs, then because this is slow as a dog, they implement virtualized display, which means they now need to reimplement scrolling, and because this obviously breaks CTRL+F, they end up piling endless hacks to fix that - assuming they bother at all.
The result is a page that struggles to display 100 rows of data. Contrast that with regular HTML, where you can shove 10 000 rows into a table, fully styled, without noticeable performance drop. A "classical" webpage can show couple megabytes worth of data and still be faster and more responsive than typical SPA.
Sounds like you're referring to some specific examples of poorly implemented apps rather than the concept of SPAs as a whole.
For your example, the point of that div soup is that enables behaviours like row/column drag&drop reordering, inline data editing, realtime data syncing and streaming updates, etc. - there is no way to implement that kind of user experience with just html tables.
There's also huge benefit to being able to depend on clientside state. Especially if you want your apps to scale while keeping infra costs minimal.
I get the frustrations you're talking about, but almost all of them are side effects of solutions to very real UX problems that couldn't be solved in any other way.
And to be clear, I'm not saying that people building SPAs when all they needed was a page showing 10,000 rows of static data isn't a problem. It's just a people problem, not an SPA problem.
> all of them are side effects of solutions to very real UX problems that couldn't be solved in any other way.
Except they had been solved in other ways and the problem was people insisted on using web technologies to emulate those other technologies even when web technologies didn’t support the same primitives. And they chose that path because it was cheaper than using the correct technologies from the outset. And thus a thousand hacks were invented because it’s cheaper than doing things properly.
Then along comes Electron, React Native and so on and so forth. And our hacks continue to proliferate, memory usage be damned.
> And they chose that path because it was cheaper than using the correct technologies from the outset
No, otherwise they would not need all those hacks. Web stack makes it cheap (fast and easy) to build an MVP, but since the very primitives required to fully implement requirements are not even there, they end up implementing tons of ugly hacks held by duck tape. All because they thought they could iterate fast and cheap.
It's the same story with teams picking any highly dynamic language for an MVP and then implementing half-baked typing on top of it when the project gets out of MVP stage. Otherwise the bug reproduction rate outpaces fixing rate.
Having done native and web frontends, they are different.
I prefer the capabilities of native frameworks but I prefer the web box model.
Sizing stuff is native frameworks is nice until it isn’t.
I’ve done both too. And I honestly don’t like the box model.
But I will admit I’ve focused more on desktop than mobile app development. And the thing about sizing stuff is it’s a much easier problem for desktop than mobile apps, which are full screen and you have a multitude of screen sizes and orientations.
>> I get the frustrations you're talking about, but almost all of them are side effects of solutions to very real UX problems that couldn't be solved in any other way.
Any other way? Just build a web app with emscripten. You can do anything.
For a while GTK had an HTML5 backend so you could build whole GUI apps for web, but I think it got dropped because nobody used it.
> rather than the concept of SPAs as a whole.
This is the whole concept of the SPA - make a page behave like multiple pages. The premise itself requires breaking absolutely everything assuming that content is static.
> There's also huge benefit to being able to depend on clientside state. Especially if you want your apps to scale while keeping infra costs minimal.
Um... I'm old enough to remember the initial release of node, where the value proposition was that since you cannot trust client data anyway and have to implement thorough checking both client and server side, why not implement that once.
> I get the frustrations you're talking about, but almost all of them are side effects of solutions to very real UX problems that couldn't be solved in any other way.
Let me introduce you to our lord and savior native app
If you don't manage the history properly in your SPA, pressing the back button could take the user out of the app entirely.
If you don't let web developers manage history/state like this, we'd be going back to the inefficient world of, "every forward/back movement loads a whole page." (With lots of unnecessary round trip messages between the client and server while the user waits for everything to load).
Basically, the ability to manage history is a user-centric feature. It makes the experience better for them.
> If you don't manage the history properly in your SPA, pressing the back button could take the user out of the app entirely.
Yes. And that should be the default behavior: browser buttons should take you through the browser's history. If you keep a in-app state and want the user to navigate through it, you should provide in-app buttons.
Nobody complains that the browser's close button quits the browser instead of the app it's showing, or that the computer's power button shuts down the whole OS and not only the program in the foreground.
Users must be educated. If they have learned that left means "back" and right means "forward", that a star (sometimes a heart) means "remember this for me", and that an underlined checkmark means "download", then understanding the concept of encapsulation shouldn't be too much for them.
> Yes. And that should be the default behavior: browser buttons should take you through the browser's history. If you keep a in-app state and want the user to navigate through it, you should provide in-app buttons.
The Back and Forward buttons on a web browser is the navigation for the web. If you click a link on a static html page it will create a new entry. If you click back, it'll take you back. If you press forward, You will navigate forward.
We should not be creating a secondary set of controls that does the same thing. This is bad UX, bad design, and bad for an accessible web.
> Nobody complains that the browser's close button quits the browser instead of the app it's showing, or that the computer's power button shuts down the whole OS and not only the program in the foreground.
It does close the app it's showing because we have tabs. If you close a tab, it'll close the app that it's showing. If you close the browser, which is made up of many tabs, it closes all of the tabs. Before tabs, if you closed a window, the web page you were on would close as well. It does what is reasonably expected.
If on your web application you have a 'link' to another 'page' where it shows a change in the view, then you'd expect you would be able to press back to go back to what you were just looking at. SPAs that DON'T do that are the ones that are doing a disservice to the user and reasonable navigation expectations.
> Users must be educated. If they have learned that left means "back" and right means "forward", that a star (sometimes a heart) means "remember this for me", and that an underlined checkmark means "download", then understanding the concept of encapsulation shouldn't be too much for them.
They should not have to be 'educated' here. The mental model of using the back and forward buttons to navigate within a webpage is totally fine.
> It's also a great way to store state so that a user may bookmark or link something directly.
Can you unpack this please? AFAIK history stack is not preserved in the URL, therefore it cannot be preserved in a bookmark or a shared link.
Probably referring to using pushState (part of the History API) to update the URL to a bookmarkable fragment URL, or even to a regular path leading to a created document.
https://developer.mozilla.org/en-US/docs/Web/API/History/pus...
> The new history entry's URL. Note that the browser won't attempt to load this URL after a call to pushState(), but it may attempt to load the URL later, for instance, after the user restarts the browser.
Sure. I'm not speaking about preserving the full history stack in the URL, just storing state. Apologies in advance if my explanation for what I mean is something you already understand.
This can be as simple as having a single checkbox with a checked/unchecked state.
when you load the webpage, the javascript can pull in the url parameters with URLSearchParams (https://developer.mozilla.org/en-US/docs/Web/API/URLSearchPa...). If the url parameter you set is set to 'on' then the checkbox, which is by default unchecked, can be set to on.
You have your checkbox:
And then you have your javascript: The history.replaceState() replaces the URL in your history with the one including the URL parameter, so if a user were to bookmark it, it would store that and reload it when they revisit the webpage.If I used history.pushState(), each time I clicked on the checkbox, a new item would be added to the stack. for a checkbox this is almost certainly a bad idea because your browser history is going to be polluted pretty quickly if you happen to click it multiple times.
pushState can be useful when it matches the user expectations, though, like if it is an SPA and the user clicks on an internal link to another section of the site, they'd expect to be able to go back to the previous page, even though we're still on the same actual html page.
So you would not be preserving the entire history stack. You can sort of do this by encoding state changes into another url parameter, but the behavior isn't entirely consistent between browsers. It also does require, as far as I know, an explicit action from the user for it to actually affect their navigation. So a website couldn't just add 1000 entries to the user's history on load without some explicit interaction on the web page.
Once the user interacts, though, it does seem like it opens up a lot of opportunity to abuse it, intentionally or not. You can asynchronously push thousands of entries into the browser history without blocking interactivity of the site. you can even continue to push state to the URL from other inputs while doing so.
It should be opt-in per website, per feature, because IMO it can be quite useful in some cases. Like clicking back on a slide-show bringing you to the overview page, instead of only going back one slide
> clicking back on a slide-show bringing you to the overview page
That behavior is expected in exactly one case (assuming slides, not the whole presentation, are modeled as a page each): If I navigated to that specific slide from the overview.
In any other scenario, this behavior amounts to breaking my back button, and I'll probably never visit the site again if I have that choice.
Opt in features are a great way to increase user frustration and confusion. See the whole new geolocation API they had to make for browsers since people would perma-deny it reflexively and then complain that geolocation features weren't working.
That's a good point, though I'm not familiar with the (changes to the) geolocation API you mention. Do you have any recommendations for reading up on that development?
Sure, I should have said geolocation element, since the original API still exists and is used: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
> I feel like anything loaded from a third party domain
Unfortunately this would break some libraries for SPA management that people sometimes load from CDNs (external, or under their control but not obviously & unambiguously 1st-party by hostname) instead of the main app/page location. You could argue that this is bad design IMO, and I'd agree, but it is common design so enforcing such a limit will cause enough uproar to not be worth any browser's hassle.
I do like that they follow up this warning with “We encourage site owners to thoroughly review …” - too many site/app owners moan that they don't have control over what their dependencies do as if loading someone else's code absolves them from responsibility for what it does. Making it clear from the outset that this is the site's problem, not the user's, or something that the UA is doing wrong, or the indexer is judging unfairly, is worth the extra wordage.
The history stack shouldn't be controlled by any loaded sites. The browser needs to treat websites as hostile.
GOOGLE is an advertising platform.
anything loaded from a third party domain shouldn't be allowed to run scripts.
facebook.com does this as a first party site, shit sites trying to squeeze eyeball time from visitors should be put on Google's malware sites list, but apparently those are the best sites nowadays... :/
That restriction would both be trivial to circumvent by malicious advertisers and annoying for many legitimate web concepts.
Maybe it's not quite your meaning - but there are browser plugins which allow per-domain blocking of js. I use one, with the default set to deny js.
There are valid use cases however the issue is rooted in lacking browser APIs.
For instance,
- if you want to do statistics tracking (how many hits your site gets and user journeys)
- You have a widget/iframe system that needs to teardown when the SPA page is navigated away
- etc
The browser does not have a;
So you must monkey patch the history API. It's impractical from a distribution standpoint to embed this code in the page bundle as it's often managed externally and has its own release schedule.Browsers now have window.navigation.addEventListener("navigate") that allows just this.
https://developer.mozilla.org/en-US/docs/Web/API/Navigation/...
Huh! Well I'll be
> - if you want to do statistics tracking (how many hits your site gets and user journeys)
You can do all of that server-side and much more reliably at that. The only reason to do any of this tracking client-side is advertisers trusting fake number go up more than sales numbers.
But the question is: why are sites allowed to hijack the Back Button?!?
So that in single-page applications, it can work intuitively instead of always taking you all the way out of the app.
If the navigation simulates what would happen if we follow links to SPA#pos1, SPA#pos2, etc so that if I do two clicks within the SPA, and then hit Back three times I'm back to whatever link I followed to get to the SPA, I guess it's OK and follows user expectations. But if it is used as an excuse to trap the user in the SPA unless they kill the tab, not OK.
From the browsers perspective those are the same thing though. It’s a paradigm boundary.
The real answer is to have desktop applications that work like applications (buttons do what feels right), and websites that work like websites.
SPA, is a page application. Pages aren’t applications, applications aren’t pages. AutoCAD is an app, the Robotech Encyclopedia is content.
> From the browsers perspective those are the same thing though.
If the browser only allows adding at most one history item per click, I should be able to go back to where I entered a given site with at most that many back button clicks.
At a first glance, this doesn't seem crazy hard to implement? I'm probably missing some edge cases, though.
Of course, but programmatically, how do you enforce that?
Some browser APIs (such as playing video) are locked behind a user interaction. Do the same for the history API: make it so you can't add any items to history until the user clicks a link, and then you can only add one.
That's not perfect, and it could still be abused, but it might prevent the most common abuses.
EDIT: apparently Chrome tried that and it wasn't sufficient: https://news.ycombinator.com/item?id=47761349
>> So that in single-page applications, it can work intuitively instead of always taking you all the way out of the app.
Just implement an additional back button on the SPA. This is actually not confusing and is done in some places. Navigation buttons within an SPA are common enough.
Because it has a legitimate use. As anything, the tools will be abused by malicious actors
I would like to mention that Google own SPA framework, angular, has redirect routes which effectively do back button hijacking if used, because they add the url you're redirecting from to the history.
https://angular.dev/guide/routing/redirecting-routes
Porno sites do this thing where every click is a new tab and when you refocus the previous tab, it reloads to an ad.
Or so I have been told.
Great. Can we do ctrl-f search hijacking next.
So jarring when websites replace core functionality with their own broken crap because they think they’re special.
Some also seem to hijack right click menu now
Firefox allows you to bypass right click hijacking by holding shift before pressing right click.
There is also an option in about:config: "dom.event.contextmenu.enabled" set it to false
CTRL+F hijacking is necessary in some cases when apps are not displaying the full text that the user would expect to search. E.g. when there's a 10K-line code file and the UI is not loading the whole thing into DOM, but the user would expect a "find" to search that whole code file.
They can have a search button for that, not hijacking default browser functions. Often I want both kinds of search.
Browsers can deal with very long documents. Ctrl+F works like a breeze on HTML that's 100K lines long.
Browsers only struggle to run heavy JS frameworks that wrap every line in a dozens of spans with dozens of handlers and mutate it all on every line scrolled.
Don't get me started on scroll hijacking.
Github hijacks '/' and it's really annoying, it gets me all the time.
Some also hijack the shortcuts to open devtools (like F12), so you have to find the option in the browser menu itself
You can also click the address bar and then press you shortcut. Should be faster and works for all shortcuts AFAIK.
Thank you!
This misses the point. Websites are allowed to replace default keyboard shortcuts for a reason. There are only a few exceptions to this, like Ctrl+W. In other words, you can design your website however you want, except to make it more difficult to leave. This is an implementation of the same philosophy.
> you can design your website however you want, except to make it more difficult to leave.
Who decreed that page navigation is in scope and search navigation is outside?
Frustrating it took this long for something to be done about this, but glad its now got something being done.
> When a user clicks the "back" button in the browser, they have a clear expectation: they want to return to the previous page. Back button hijacking breaks this fundamental expectation.
It seems pretty stupid. Instead of expanding the SEO policy bureaucracy to address a situation where a spammer hijacks the back button, the browser should have been designed in the first place to never allow that hijacking to happen. Second best approach is modify it now. While they're at it, they should also make it impossible to hijack the mode one.... oh yes, Google itself does that.
What about all the very legitimate uses of programmatically adding history entries?
Please explain the legitimate uses. Not once I have ever encountered a website that does something useful by modifying the behavior of my browsing history.
https://html.spec.whatwg.org/multipage/nav-history-apis.html...
The spec kind of goes into it, but aside from the whole SPAs needing to behave like individual static documents, the big thing is that it's a place to store state. Some of this can be preserved through form actions and anchor tags but some cannot.
Let's say you are on an ecommerce website. It has a page for a shirt you're interested in. That shirt has different variations - color, size, sleeve length, etc.
If you use input elements and a form action, you can save the state that way, and the server redirects the user to the same page but with additional form attributes in the url. You now have a link to that specific variation for you to copy and send to your friend.
Would anyone really ever do that? probably not. More than likely there'd just be an add to cart button. This is serviceable but it's not necessarily great UX.
With the History API you can replace the url with one that will embed the state of the shirt so that when you link it to your friend it is exactly the one you want. Or if you bookmark it to come back to later you can. Or you can bookmark multiple variations without having to interact with the server at all.
Similarly on that web page, you have an image gallery for the shirt. Without History API, maybe You click on a thumbnail and it opens a preview which is a round trip to the server and a hard reload. Then you click next. same thing. new image. then again. and again. and each time you are adding a new item to the history stack. that might be fine or even preferred, but not always! If I want to get back to my shirt, I now have to navigate back several pages because each image has been added to the stack.
If you use the History API, you can add a new url to the stack when you open the image viewer. then as you navigate it, it updates it to point to the specific image, which gives the user the ability to link to that specific image in the gallery. when you're done. If you want to go back you only have to press back once because we weren't polluting the stack with history state with each image change.
Thanks for the detailed and thoughtful reply! I agree that in both of the scenarios you mentioned, this API does provide better usability.
I guess what feels wrong to me is the implicitness of this feature, I'm not sure whether clicking on something is going to add to history or not (until the back button breaks, then I really know).
Any single page application, such as YouTube, Gmail, or discord.
It lets persistent content (videos) or connections (chat) persist while emulating a pagenated browsing experience.
When it's done right you don't notice it at all.
Youtube doesn't implement a back function. A real back function would take you back to the same page you came from. If you click a video from the Youtube home page, then click the back button, Youtube will regenerate a different home page with different recommendations, losing the potentially interesting set of recommendations you saw before. You are forced to open every link in a new tab if you want true back functionality.
(rant warning)
Well, if I wanted to return to the parent screen in a single page application, I'd click on the back button in the app itself. No need to prevent me from back tracking in the exact order of my browsing should I need it.
I especially hate YouTube's implementation, I can never know the true state on my older PC during whatever it's trying to accomplish, often playing audio from a previous video when I backspace out. I resort to opening every link in a new tab.
Especially since, who cares about traditional SEO any more?
Do we include reddit.com here, or too big to influence?
A browser feature I wasn't aware of for too long: long press the back button, to get a list of recent URLs, allowing you to skip anything trying to hijack the back button.
The most egregious cases of back button hijacking will leave you with a very long list of entries, which is why it's good to see Google taking this seriously. It's annoying and can be outright malicious in many cases on the part of the offending website.
That’s surely bounded now much it can show, so an attacker can just fill it up till the api throws an error
Surely the browser could enforce a limit on a domain, and make sure that the real page you came from (typically the search engine) is prominently displayed.
Or right click
I understand this is vague on purpose but wish there was more detail. E.g., if I am running a game in a webgl canvas and "back button" has meaning within the game UI which I implement via history states, is my page now going to be demoted? This article doesn't answer that at all.
Your game probably has poor SEO to begin with, so the Google Search policy changes would not apply
If it automatically adds something to the history when you visit the page, then yes. If it only adds to the history when the user clicks something, then I would assume it would be fine. Hopefully.
Isn't this a heuristic implemented by browsers already these days?
what about back buttons reloading the page so to have any continuity you have to open everything in a separate tab? youtube for example
What about map applications which manipulate the history to store the position of the map as users drag and release to make back and forward work to the users expectation in a single page app? It’s not malicious, but will Google flag it?
Took long enough. Maybe I missed it, but I didn’t see them say how invested they are in tackling this. Promoting a rule is one thing, but everything SEO related becomes a cat and mouse game. I don’t have high confidence that this will work.
Seems invested enough to me. Adding this to the anti spam policy means they will list sites using this lower or not at all, when detected. And they use automated and manual detection for such things. Not much more they can do? And should be effective, who employs scam tactics like this is also interested in having visitors.
Since this is Google we’re talking about, I’m fully expecting them to penalize benign uses of the back button override.
Almost 30 years ago I wrote an article advocating for domain level back button with a quasi mode like ctrl to traverse domains.
Would have fixed this. Too late now
I use Chrome on my Android and Mac. For a while I've appreciated the seemingly built-in anti-hijacking measure that always does what I expect on the second Back press. (The first Back may pop up a subscription box for example, but the second will always return me to where I came from).
I actually felt that this was a solved problem, so I'm surprised to see so many people still suffer getting stuck in redirect loops.
Wait, how does one website (google.com) know what happens inside my browsing session on another website (bad-blog.com) after I click over? Hmmmmm
This sort of announcement just emphasizes the extent to which Google observes ALL your web browsing behavior, thanks primarily to their eyes inside Chrome browser.
You know those warnings when you install a browser extension, about all the things that extension will be able to see and do? Well so can Chrome itself…
They've been crawling the web since inception
A web crawler reads page content, extracts content and URLs, places them into an index, and then follows links in that index to further build the index and content corpus. Google and others have special crawlers that execute JavaScript to crawl content delivered dynamically.
Crawlers do not use the browser back button or browser history. So the only way Google could observe such problems is by observing live human browsing behavior.
Also, we know from exhibits in the U.S. DOJ trial that Google does use Chrome browsing behavior as a signal in search ranking. It’s not a hypothetical.
They likely scan the web pages themselves, but you shouldn't be using Chrome anyways, if you care about privacy from Google.
Now do the Amazon app.
Number of times I've looked for something on my phone, gone through to a product page on Amazon but then have had to back out multiple times to get back to the search listing. Sometimes it's previously viewed products, sometimes it's "just" the Amazon home page. It should be one-and-done.
eBay too. I'm sure there are others.
There should be some browser-level enforcement of this. For example, it would seem possible to detect a user frustratingly mashing the back button, and offer a remediation dialog to disable any hackery that's hijacking the back buttons.
Yes please! It's very annoying how clicking an FB or Insta result from a Google search result would disallow going back to the search result!
The iron law of web encrapification: every web feature will (if possible) be employed to abuse the user, usually to push advertising.
I cannot even reliably press [Space] any more to page down through sites that are meant to be all about content!
I've always found that behavior baffling so it's interesting to hear someone using it as intended instead of being frustrated by it.
It used to be a de facto standard in many programs. Since almost no mouse had a scroll wheel, you'd use the space bar or the cursor keys. Spacebar was usually faster, I guess some people still do.
I do this too. The pattern probably dates back to first Unix pagers, or perhaps to the paper era.
Still doing that, also in Thunderbird, to scroll through E-Mails and go to the next one when reaching the end (or pressing "n" or "p" for previous). I even use shift + space to go up again. I thought it was very common. Another alternative, maybe a bit more intuitive is using page up and down buttons.
i love it. my mac doesn't have the home row (don't know if that's how that row of buttons is called) so I use spacebar and shift+spacebar as pgdown and pgup when I am reading
>the home row (don't know if that's how that row of buttons is called)
the "home row" is where your fingers start out if you know how to type by touch, and it come from the days of typewriters instead of keyboards.
on a QWERTY keyboard, the home row is ASDFGHJKL; with your fingers resting on ASDF and JKL;
when they teach you to touch type, they say "put your fingers on the home row" and "home is where your fingers always return to."
[fn]+[up arrow] = pgup, [fn]+[down arrow] = pgdown, [fn]+[left arrow] = home, [fn]+[right arrow] = end
These are impossible to press with just one hand (or the bottom of my coffee cup in a pinch), though.
I use option + up arrow or option + down arrow sometimes, works the same as spacebar to page up / page down.
In which browser? Doesn't work in Firefox, unfortunately.
Unfortunately I'm using Chrome still.
"Home row" usually refers to the row where you initially put your fingers when touch typing, to not have to move them much while typing.
They're called the navigation keys. Fn + Up/Down (arrow keys) is PgUp/PgDn, and Fn + Left/Right is Home/End. But of course, those keys are on completely opposite sides of the keyboard, so Space is more convenient.
yeah, with spacebar i can use either of my hands while the arrow keys would require me to use both of my hands
I am often annoyed Mac does not have a right Ctrl or a right Fn.
This is my biggest gripe with modern browsers. Stop fucking with my keyboard. I want my keyboard to control my agent, not some script. No key seems to be safe. The quick-search key (/) is often overriden by "clever" web devs, but not even in a consistent way. Ctrl-K to go to the browser search box is gone. I use emacs keybindings in text boxes, but those can be randomly overriden by scripts (e.g. Ctrl-B might by overridden to make stuff "bold" etc.).
I want to be able to say "Don't let any script have access to these keyboard keys". But apparently that can't be done even with extensions. I've strongly considered forking Firefox to do this, but I know how much effort that would be to maintain.
How hard would it be to write scripts that expose an interface that the user can bind to keys themselves, if they wish to?
One more for the spacebar to advance the page. Have never encountered a broken site (so far). Fingers crossed.
It really comes down to JavaScript. The web was fine when sites were static HTML, images, and forms with server-side rendering (allowing for forums and blogs).
Did you use the web back in 1995? It was fun, but it also sucked compared to what we have now. Nothing is ever perfect, but I wouldn’t want to go back.
I’d go back in a heartbeat. Making the web a software SDK was the worst thing to happen to it.
Gemini websites are pretty much the old web: https://en.wikipedia.org/wiki/Gemini_(protocol)
Both in terms of comprehensiveness and in terms of functionality.
Geminispace is a very chill place. It’s definitely not a replacement for the web, but if you can handle the compromises, it feels like both the past and the future.
So, apparently you don't use google maps (or any other mapping website)
That could be a web app.
The data that google maps is caching in my browser is more than Google World needed disc space back then. So why not just use Google World for that?
I read epubs, and html pages derived from texinfo and mandoc. When I see websites that just break down when you disable JS (I do it with ublock), I always feel a pang of sadness. Unless you’re Figma, Google doc, or OpenStreetMap…, which rely heavily on local state, JS should only be required for small island of interaction.
You talk about 1995 but I wouldn't even go back to 1999. Dialup was so painful. It advertised 56 know but in practice I never even say 48...
That seems like a separate thing. You can send 199x-era HTML over a gigabit connection.
I wrote web pages in 1995. There was actually plenty you could do, but it was all server side driven.
And the ironic thing is you are chatting on a forum that could have easily been built in 1995.
I published my first website in 1995 (and while it wasn’t even a little popular, eventually a spammy gay porn site popped up with the exact same joke name, leading to a pretty odd early “what if you search for your own site” experience).
If you put 2026 media players (with modern bandwidth), on the manually curated small-editorial web of ‘95 it’d be amazing.
We used to have desktop apps, these SPA JS monstrosities are the result of MS missing the web then MS missing mobile. Instead of a desktop monopoly where ActiveX could pop up (providing better app experiences in many cases than one would think), we have cross-platform electron monstrosities and fat react apps that suck, are slow, and omfgbbq do they break. And suck. And eat up resources. Copy and paste breaks, scrolling breaks, nav gets hijacked, dark mode overridden.
Netflix, Spotify, MS have apps I see breaking on the regular on prime mainstream hardware. My modern gaming windows laptop, extra juicy GPU for all the LLM and local kubernetes admin, chokes on windows rendering. Windows isn’t just regressing, their entire stack is actively rotting, and all behind fancy web buttons.
Old man yelling at cloud, but: geeeez boys, I want to go back.
I’d go back. The BBS and dial up days look cosy
Now it’s owned by corporates and everyone is using bloated JS frameworks.
There are still BBS you can access via telnet (and actual dial up if you really want), after the fifth one asks you for your full name, street address and phone Humber it gets a little old.
I would also go back in a heartbeat
You're not wrong but we've never really tried the combination of modern CSS with no JS. It could produce elegant designs that load really fast... or ad-filled slop but declarative.
Yes to the modern CSS. To go as far back as suggested would mean using frames again and table based layouts with 1x1 invisible gifs to use for spacing layouts. Never again!
Ads don’t work nearly as well without JavaScript for adtech. They’re basically limited to static banners and text ads as well as sponsorships.
Sounds glorious
> Did you use the web back in 1995?
I'm still not over the loss of Gopher.
If JavaScript hadn't been a thing, Flash and JavaApplet would have been far more popular than they were and I really don't appreciate that timeline.
JavaScript didn’t kill Flash a Java. The web becoming cross platform did.
People started browsing on a plethora of devices from the Dreamcast to PDAs. And then Steve Jobs came a long and doubled down on the shift in accessibility. His stance on Flash was probably the only thing I agreed with him on too.
It wasnt "fine".
Oh, the social media was much, much better. People much more open, tracking didn't exist. All the idiots still thought computers were only a thing for nerds and kids.
The web was not fine.
If you wanted to accomplish anything more substantial than reading static content (like an email client that beeps when you get an important email, or a chat app that shows you new messages as they come in), you needed to install a desktop app. That required you to be on the same OS that the app developer supported (goodbye Linux on the desktop), as well as to trust the dev a lot more.
We seem to have collectively forgotten the trauma of freeware. Operating an installer in the mid 2000s was much like walking through a minefield; one wrong move, and your computer was infected with crapware that kept changing your home page and search engine. It wasn't just shady apps, mainstream software (I definitely remember uTorrent and Skype doing this) was also guilty. Even updates weren't safe.
I use a desktop mail client. I have always used desktop applications. I have never had any desire to use web mail clients. Likewise for office suite applications. A true desktop spreadsheet, word processor, and slide deck are always superior.
The web as an application platform has always been a half-baked, second class, inferior experience for the user. It has always been about developer convenience at the expense of the user. No thank you!
Somehow we have cross platform software today that isn't Electron slop. And shoehorning absolutely everything into what used to be a document oriented application, creating this grotesque mutant abomination we have today, has just moved the minefield. How many RCE's has Chromium had?
Also, up until Windows Vista, Microsoft thought that making every account on their OS root by default was an amazing idea, further exacerbating the problem you describe, which I don't deny existed. Software distribution on Windows is still a shit-show today, but I guess there's too much momentum to move to a Linux-style repository. The Microsoft Store is a piss poor attempt.
This is the price we pay for openness and decentralization.
On one side, we have Apple giving us great APIs but telling us how to use them. On the other, we have W3C being extremely conservative with what they expose, exactly because of things like this.
This is the price we pay for stuffing browsers with tons of imperative APIs that the browser has no choice but to implement to the letter, since analysing how they are actually used runs afoul of Rice's theorem.
This is the price we pay for bloat...
Those features that can't be used to show more ads will be used for fingerprinting.
I feel like we need a complete black box layer or something, where a website can send requests to the browser to do something, but never gets any kind of reply, as to whether anything actually happened. But that would limit usefulness of it quickly, I guess.
I've been toying with an idea of creating a JS runtime that tries to run all code two times, one which runs all identifying information inside a runtime that has any network API's stubbed, and another that replaces the identifying info with garbage.
Most likely needs manual quirk code overlays for sites, but it's totally a solvable problem.
> We believe that the user experience comes first.
Excuse me??
Google should probably talk to Microsoft about this because for me they are the biggest offenders with this back button hijacking in their support forums.
It's about time. Google is doing so much to keep the web usable. They're the only ones with the teeth to back up standards for mobile web load time, max sender spam rates, leaving browser history alone, etc.
They’re also the ones frequently making it worse with their monopoly.
Thank you!
One of the worst is TikTok, even as a developer, when someone sends me a TikTok link and I have to visit it, I get stuck in the browser (same with the app but I uninstalled it), and it feels almost device-breaking the way they trap you in.
TikTok is actually very adamant to boot me out of the browser
Is there any click-bait news site that DOESN'T do this? You hit back and land on a list of their click-bait articles and add links instead of the page you expect.
Click on any Youtube video from any web in android. If you press anything that is not the back button immediately, you will loose the option to go back.
So this coming from google... it's funny. Welcome, but funny.
I hope this applies to Android as well. Reddit is a particularly egregious offender.
Amazing change, fighting with the back button is my least favorite part of the ad web and a blindspot for ublock. I wonder how Google is going to track this and if SPA style react router sites would be downranked because of the custom back button behavior. I doubt it due to their popularity but I'm curious how they're going to determine what qualifies as spam
> Why are we taking action? We believe that the user experience comes first.
What's the real reason?
It broke Gemini and of course we can't have that...
I want my browser history to be immutable and operate like a tree and not like a stack.
I've been kicking around an idea in my head of a modern browser implementing some kind of "hardening" against anti-features. Deviating from the standard, implementing certain architectural features like this WORM history graph, etc. I don't want to ditch javascript entirely as I don't think it's particularly unreasonable as a feature. That being said, I don't want my extensions to be available via a URL query (even if obfuscated like what Firefox does.) I have yet to find a single webpage utilizing scrolljacking where I would care if it was broken and completely unnavigable. I can count on one hand webpages where I felt like input reading was justified, and even then I wouldn't miss them if the facilities which enable input reading were just made completely undefined.
There certainly is a satisfaction that would come from a shit site like linkedin or youtube being reduced to a gibbering mess of exceptions. Scripting is a privilege, and it's a nice one, but abuse of it shouldn't be tolerated. I really don't see a usecase for boiling it down to a binary of allowing the whole gamut of complex programmability web browsers expose, or allowing none of it. I'd rather just draw a line and say "programs that use these features are acceptable, programs that use these ones aren't".
Why not fix this at the browser level? E.g. long or double click on back button = go to previous non-javascript-affected page (I mean by that: last page navigated to in the classical sense, ignoring dynamic histories altered by js and dynamic content)
That wouldn't work because this technique messes with your history. Long press on the button will just show you a list of the previous pages you visited, and all of them will have the same link to the one you're in, with just one at the bottom of the actual URL you came from. But that's so much friction UX-wise.
Double clicking is not a fix because it doubles latency, and more than doubles latency if you don't want to issue page loads that are immediately aborted. Long clicking is such a bizarre anti-feature that I never considered it might exist until I read about it in this HN discussion. Putting touchscreen-specific workarounds for lack of mouse buttons and modifier keys in a traditional GUI app is insanity.
I remember when I worked at HuffPo and they started doing this. I called out the org and they all just shrugged.
Ironically, we have an infringing website right now on the front-page of HN (nypost).
Phew. for a moment there i thought they would start blocking alternate uses of the back button in apps (for like when it means "go back" and when it means "close everything")
That would have severely rustled my jimmies
>We believe that the user experience comes first
I’ll believe that when YouTube gives me the ability to block certain channels versus “not interested” and “don’t recommend channel” buttons that do absolutely nothing close to what I want.
Or a thousand other things, but that one in particular has been top of mind recently.
Let me permanently hide "shorts".
Or if they ever bring back the "ignore this domain" feature so we can ignore ai slop and copycat sites.
It's why I went to Kagi.
Really wish this was applied to phone apps. In Android at least, app A linking to app B will FREQUENTLY break the "back" functionality, allowing app B to handle the "back" action instead of doing what every user would expect 100% of the time, which is to go back to app A.
Reddit! I'm looking at you?
Scroll on Reddit on mobile and click on a link. The comments open in a new tab. Close the tab and the previous tab is also at the link you’ve just closed.
Makes it impossible to browse around and long click to open on a new tab doesn’t solve the issue either.
And if the tab was unloaded then you press back it changes the URL but not the actual contents of the page.
I feel like facebook is the worst culprit with this
Those are all weird WebKit issues, and reddit not testing MobileSafari.
It works perfectly on Chrome, if it was intentional they would have broken it on Chrome too.
As always you can count on Apple/Safari team to not give a shit, not try to fix it, not reach out to reddit to ask them to fix it, etc.
You think Reddit does not test in their #1 browser?
Does this also apply to sites like instagram that simply erase your entire back button history if you visit the site.
Maybe we can get facebook finally drop this dark pattern
So someone developed a malicious plugin to achieve this? Otherwise, I can't imagine how they could bypass the browser to do this.
I'm at a stage when I click back button extremely rarely and is amazed when it works as I expected.
Nice. This has been existed for too long.
This would have been great back when I used a search engine to visit web pages.
So why don't google just disable the possibility of hijacking the back button in Chrome, to give an example?
It's not clear what constitutes a hijacking and how they are going to detect it. It may be OK to override the button as long as it's used in the intended way which is to go back. In a single-page application it may not trigger a navigation event.
> In a single-page application it may not trigger a navigation event.
So isn't that also back hijacking?
In an "application" model rather than a "document" one, like MS Word online or draw.io or similar, there's no clear semantics for "back" but there is a risk of the user losing data if they can navigate away without saving.
This is a consequence of sites being allowed to hijack back in the first place. They can still fix it.
For your use case all you need is the page to get notified so it can save. Remember that on Android your onSaveInstanceState gets called and you have to save your state or lose it.
This would break so many websites. There are valid uses for the history API, I often do modals/popups as shareable URLs, and using the back button closes it.
i wonder if this includes sites that do auto-redirect: A -> B (auto-redirect) -> C
if i'm on page C and go back, page B will take me to page C again. i think this is more about techincal incompetence rather than malicious intent, but still annoying.
Ah the irony. Wouldn't let me go back without clicking the cookie thing.
Microsoft joke support forum stil does this?
Great! So they'll fix the back button bugs on YouTube, and return me to the previous set of video recommendations when I use it on the homepage, right? Right? And let me return to the actual site when it detects that I lost the web connection for 0.01 seconds and hides all the content, and I then press the back button?
Are they considering all uses of window.history.pushState to be hijacking? If so, why not remove that function from Chrome?
Because clicking on a navigation button in a web app is a good reason to window.history.pushState a state that will return the user to the place where they were when they clicked the button.
Clicking the dismiss button on the cookie banner is not a reason to push a state that will show the user a screen full of ads when they try to leave. (Mentioning the cookie banner because AFAIK Chrome requires a "user gesture" before pushState works normally, https://groups.google.com/a/chromium.org/g/blink-dev/c/T8d4_...)
It's a valid question how they detect it. As there are valid usages, just checking for the existence of the function call would not be correct.
These sites likely pushState on consent actions so it appears like any user interaction.
No idea how they actually do it, but I wouldn't be surprised if manual reports and actions play a big role. The policy doesn't need to be enforced reliably as long as it is plausible for reasonably big actors to get caught sooner or later and the consequences of getting caught are business-ruining.
But detecting it on a technical level shouldn't be hard either. Visit the page, take a screenshot, have an AI identify the dismiss button on the cookie/newsletter popups, scroll a bit, click something that looks inactive, check if the URL changes, trigger the back action. Once a suspicious site is identified, put it in the queue for manual review.
The URL does not even need to change, you can pushState with just a JavaScript object, catch the pop and do something like display a modal. (I use this pattern to allow closing fullscreen filter overlays the user opened)
Still, requires user interaction, on any element, once. So the crawler needs to identify and click most likely the consent/reject button. Which may not even trigger for Googlebot.
So they likely will rely on reports or maybe even Chrome field data.
Field data is a great point - it should be really obvious when people click "back", and many then click back again immediately after (or close the tab, or whatever people do to "escape").
No, only if your website abuses window.history.pushState to redirect the user to spam/ad content is it considered abuse.
Instagram comments page requires 2 quick back press or else it won't take to previous page
When I first heard of the APIs that allowed websites to modify browser history it sounded like a huge mistake. I still feel that way to this day.
It only made sense in the SPA way of working. Allowing the history to be updated would allow the browser's default navigation to work. Outside of SPA type of sites, it was only ever going to be abused.
This is great. Can Google also stop scroll hijacking?
is there a policy on "home button hijacking"?
I'm tired of apps that intercept home button to ask "are you sure?" - home button is home button, return me to the main phone screen
also, ads at the bottom of the screen, so that if you miss home button you open a website
How does this work? How can a site inject a totally different site into the history? I thought eg the History API only lets you add to the stack and pop, not modify history?
There's also a replace() method, and trying to limit that to only same origin or already visited URLs seems futile, as the pages hosted there can themselves detect that the user is navigating back and can just forward you in a number of ways.
Is there not a plugin that helps to fix this?
It's getting very tiring seeing things that could be first-class user defined controls baked in the browser so that you have true agency over the behaviour being done like this
It's like the other thread from before where LinkedIn scans for your extensions, the fact they can do that without prompting for permission from the user is baffling
Cool, now maybe let's do something about all the shit I have to clear out out my face before I can read a simple web page. For example, on this very article I had to click "No thanks" for cookies and then "No thanks" for a survey or something. And then there was an ad at the top for some app that I also closed.
It's like walking into some room and having to swat away a bunch of cobwebs before doing whatever it is you want to do (read some text, basically).
Haha, we had a solution for that, called pop-up blockers. Then when they became very usable, everyone switched to overlays injected with javascript, so they became unblockable.
But thinking of this at this moment, this could be a good use for a locally ran LLM, to get rid of all this crap dynamically. I wonder why Firefox didn't use this as a usecase when they bolted AI on top of Firefox. Maybe it is time for me to check what api FF has for this
I'm waiting for someone to develop an augmented-reality system that detects branded ads or products, compares them against a corporate-ownership database, applies policies chosen by the user, and then adds warning-stripes or censor-bars over things the user has selected against.
It would finally put some teeth behind the myth of the informed consumer, and there would be gloriously absurd court-battles from corporations. ("This is our freedom of speech and commerce, it's essential, if people don't like what we're doing they can vote with their wallets... NOT LIKE THAT STOP USING SPEECH AND COMMERCE!")
Don't forget the useless "Got it!" popups, especially when the site blurs the screen to guide you to it.
With uBlockOrigin set to default deny all the javascript on the page there are:
zero cookie banners
zero surveys popping up
zero ads to be closed
Just the text of the page with no other distractions in the way.
ublock origin with annoyance filters on solves 95% of this
Your problems have been solved for more than a decade. Set your browser to open pages in reader view by default and you don't have these issues.
It seems like a lot of the APIs that make a website act like an application need to be disabled by default; and some kind of friction needs to exist to enable them.
Edit: I'm not sure what kind of friction is needed, either an expensive review process (that most application developers would complain about but everyone else would roll their eyes) or a reputation system. Maybe someone else can think of a better approach than me?
Popups were dealt in a way that could be useful here, they're only permitted when the user directly generates the interaction that creates the popup (not scripted). The back button could use the same algorithm back in history, only go back to screens that the user directly navigated.
I never understood why browsers ever allowed this in the first place. It's obviously bad. Yeah, yeah there are "reasons" but it's still obviously a bad solution to whatever "problem" they were trying to solve.
too little, too late. The API for interacting with the back button in Javascript should never have existed in any capacity.
that's crazy things goin on
> We believe that the user experience comes first.
If by "user" you mean advertisers, sure you do. Everyone else is an asset to extract as much value from as possible. You actively corrupt their experience.
The fact these companies control the web and its major platforms is one of the greatest tragedies of the modern era.
> Notably, some instances of back button hijacking may originate from the site's included libraries or advertising platform. We encourage site owners to thoroughly review their technical implementation...
Hah. In my time working with marketing teams this is highly unlikely to happen. They're allergic to code and they far outnumber everyone else in this space. Their best practices become the standard for everyone else that's uninitiated.
What they will probably do is change that vanity URL showing up on the SERP to point to a landing page that meets the requirements (only if the referer is google). This page will have the link the user wants. It will be dressed up to be as irresistible as possible. This will become the new best practice in the docs for all SEO-related tools. Hell, even google themselves might eventually put that in their docs.
In other words, the user must now click twice to find the page with the back button hijacking. Even sweeter is that the unfettered back button wouldn't have left their domain anyway.
This just sounds like another layer of yet more frustration. Contrary to popular belief, the user will put up with a lot of additional friction if they think they're going somewhere good. This is just an extra click. Most users probably won't even notice the change. If anything there will be propaganda aimed at aspiring web devs and power users telling them to get mad at google for "requiring" landing pages getting in the way of the content (like what happened to amp pages).
Now if only they'd do this for Android apps that hijack the back button to pop up things, or say "are you sure you want to leave?"
Google should actually fix this from the browser side instead of trying to seriously punish potentially buggy sites.
We tried a few times. We got as far as gating the ability to push into the "real history stack" [1] behind a user activation (e.g. click). But, it's easy to get the user to click somewhere: just throw up a cookie banner or an "expand to see full article" or similar.
We weren't really able to figure out any technical solution beyond this. It would rely on some sort of classification of clicks as leading to "real" same-document navigations or not.
This can be done reasonably well as long as you're in a cooperative relationship with the website. For example, if you're trying to classify whether a click should emit single-page navigation performance entries for web performance measurement. (See [2].) In such a case, if the browser can get to (say) 99% accuracy by default with good heuristics and provide site owners with guidance on how to annotate or tweak their code for the remaining 1%, you're in good shape.
But if you're in an adversarial relationship with the website, i.e. it's some malicious spammer trying to hijack the back button, then the malicious site will just always go down the 1% path that slips through the browser's heuristics. And you can try playing whack-a-mole with certain code patterns, but it just never ends, and isn't a great use of engineering resources, and is likely to start degrading the experience of well-behaved sites by accident.
So, policy-based solutions make sense to me here.
[1]: "real history stack": by this I mean the user-visible one that is traversed by the browser's back button UI. This is distinct from the programmer-visible one in `navigation.entries()`, traversed by `navigation.back()` or `history.back()`. The browser's back button is explicitly allowed to skip over programmer-visible entries. https://html.spec.whatwg.org/multipage/speculative-loading.h...
[2]: https://developer.chrome.com/docs/web-platform/soft-navigati...
> We tried a few times
Classify history API, canvas etc etc as "webapp" APIs, and have them show a similar dialog to the webcam dialog.
Then I can just click no, and the scripts on the page can't mess around.
Yes Google Maps is great. No, my favorite news site doesn't need that level of access to my browser or machine, it just needs to show some images and text.
The back button itself feels overloaded. There's "go to previous state" and then there's "go to previous origin." In an ideal world when I doubleclick on the back button what I mean is: "get me off of this site, now."
I agree. It may also require some extra work to figure out what the correct previous origin was, but this will also help legitimate cases where sites send you through 10 different redirects before you get to an actual site (looking at you Microsoft login).
What does this have to do with sites being buggy? This change is about obvious intentional abuse.
SPA legitimately insert pages into the history to hijack the back button to make it seem like the user was actually navigating through a site instead of it being a single page. If there is a bug somewhere that causes it to insert too many of these navigations or add navigations that user doesn't personally think should be navigations I could see it being considered as potentially violating this policy.
If this was about intentional abuse the article would not have had to ask all site operators in existence to audit their entire website for this. Even if some random library does this without your knowledge can violate this.
Honestly if your site is buggy in a way that effectively breaks the browser, maybe you should be punished.
I recommend 14 days in jail for the site owner, and, if egregarious, the engineer as well.
Not life ruining but just enough to be annoying. Just like their website.
Now, if they only declared scroll hijacking as spam...
will google really punish sites for doing this? and if so how do i report a site? i guess i could email the site with the google link and suggest they fix it first
Now to prevent scroll bar hijacking.
Great. Now do Android phones...
I don't trust Google.
We need to go back to an independent and competent research group designing standards. Right now Google pwns and controls the whole stack (well, not really ALL of it 1:1, but it has a huge influence on everything via the de-facto chrome monopoly).
Remember how Google took out ublock origin. They also lied about this aka "not safe standards" - in reality they don't WANT people to block ads.
Power is taken but also given. It's a dynamic and I agree it's gotten way, way out of hand. It may eventually supress progress and become a real parasitic presence, but we've not reached that point yet (in net terms). Google has been relatively responsible with the power, but cracks have been starting to show. It will get a whole lot worse before it gets better. That is why I embrace vertical integration despite the tremendous cost. Call it the cockroach approach; it allows being partially decoupled from outside fluctuations.
Addition: People underestimate Google's influence. It's easy to forget they de-facto control Firefox, leaving only Apple and Google in control of the Web. Scary, but looking away won't help either. The Americans have been consistently competent with technology since the advent of the transistor right after WW2. They're reaping the benefits of that still to this day. I say that as a European.
Now do paywalls next.
How would you recommend that creators of valuable content get paid?
Paywalls are, of course, the author's choice.
But a paywall is a rather useless page, so it shouldn't be shown in search results. Normally, serving Google one page (e.g. a full article) and showing users something else (e.g. a paywall) would be grounds to ban that site forever, but Google built a special exemption for paywalls.
Showing search results that the user can't actually use is user hostile. It's essentially an ad disguised as a search result, with the problem that those ads displace other results that I might actually be able to read.
Of course, if the policy was to not index paywalled content, we might have avoided the paywallization of the Internet. Somehow, decades ago, when the Internet was smaller and there were fewer eyeballs, high quality content could successfully get monetized with non-tracking ads.
Now we have invasive ads that try to profile you, ads that are full of scams because quality control has gone out the window, and yet, somehow, everything needs to be behind a paywall...
Ideally, when I create valuable content I am paid and when I consume valuable content I don't pay. Advertising does this but I hate it so I don't want that. So ideally, there is no way to extract value from me but I am able to extract value from others. I think I would support someone who finds a way to enforce this.
But I am also willing to pay for valuable content an exorbitant amount if it is valuable enough. For instance, for absolutely critical information I might pay 0.79€ a month.
Easy fix:
JS doesn't let you change back button behaviour.
Q. But what about SPA?
A. Draw your own app-level back button top left of page.
Another solution: make it a permisson.
Yeah, no thanks. I want to use my browser’s standard keyboard shortcut to navigate back. And also forward again. And I want to be able to inspect the history listing before I go back or forward.
Let the browser do the browsery things. Don’t make SPAs suck even more than they already do.
So when you use a desktop app there is no back button but there is a switch to another app shortcut. Same idea.
There are desktop apps that do provide a navigation history (for example file managers, editors, chat apps), and they generally use the same keyboard and mouse operations as browsers for that. The point is that when an SPA does provide that within a browser, then the user shouldn’t suddenly have to use bespoke UI operations for it.
Can I preventDefault on mouse5? What about the physical back button on Android?
>Draw your own app-level back button top left of page.
This is the worst idea I’ve heard all day.
Why not just put up a fake captcha page? When the user clicks the link to continue, the back button is now hijacked.