Hacker News

Rather than outright disabling it, I wish it was a permission the site would have to request.

That way trusted sites that used it responsibly could be given permission, but it could not be used by any random site.

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!

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.

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!

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.

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".

> 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.

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)

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.

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…

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

> 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?

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.

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.

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!

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.

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.

Nothing loaded from the web should be able to fiddle with any browser behavior, yet here we are.

> 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.

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 that in single-page applications, it can work intuitively instead of always taking you all the way out of the app.

Because it has a legitimate use. As anything, the tools will be abused by malicious actors

Firefox allows you to bypass right click hijacking by holding shift before pressing right click.

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.

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

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.

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

Or right click

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.

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.

They've been crawling the web since inception

They likely scan the web pages themselves, but you shouldn't be using Chrome anyways, if you care about privacy from Google.

I cannot even reliably press [Space] any more to page down through sites that are meant to be all about content!

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).

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.

Those features that can't be used to show more ads will be used for fingerprinting.

They’re also the ones frequently making it worse with their monopoly.

TikTok is actually very adamant to boot me out of the browser

It broke Gemini and of course we can't have that...

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".

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.

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.

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.

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.

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 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.

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, only if your website abuses window.history.pushState to redirect the user to spam/ad content is it considered abuse.

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.

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.

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

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.

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...

What does this have to do with sites being buggy? This change is about obvious intentional abuse.

Honestly if your site is buggy in a way that effectively breaks the browser, maybe you should be punished.

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.

How would you recommend that creators of valuable content get paid?

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.

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.