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.

  // ==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);
  })();

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

Pre-empting the web-mail comment: I know. I don't care.

If you’re hinting at an argument about whether lazy loading content should exist, that’s a separate discussion. In my experience, pages that override ctrl+f do it for a good reason

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

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'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…

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?

Thanks for explaining how they do it BTW! I didn't really think about it. I just knew it was shitty.

There's yer problem....

Google isn't interested in helping people find pages with no ads.

Makes it impossible to browse around and long click to open on a new tab doesn’t solve the issue either.

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

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.

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.

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?

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 is the way.

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

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

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.

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.

This feels like a reasonable counter-measure.

https://developer.mozilla.org/en-US/docs/Web/API/Navigation/...

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.

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.

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.

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.

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

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.

Who decreed that page navigation is in scope and search navigation is outside?

And the ironic thing is you are chatting on a forum that could have easily been built in 1995.

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'm still not over the loss of Gopher.

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.

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.

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.

Browser storage is cheap, but it is not guaranteed to be durable.

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.

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.

Now it’s owned by corporates and everyone is using bloated JS frameworks.

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.

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.

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.

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!

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.

Most likely needs manual quirk code overlays for sites, but it's totally a solvable problem.

We know perfectly well who they are.

God I hope you are being funny. Why else would anyone install this crap?

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.

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

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

    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'); };

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.

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.

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

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.

The issue is hardly isolated to news outlets. It's endemic to the web.

I remember when JavaScript became a big Web site driver. The arguments against using it to fetch and build content usually included broken back button functionality.

I don’t think a lot of folks really paid much attention to it, though.

And I've found it so good that I haven't used Google, except by accident, in the past 18 months.

Look what happened with Netflix. They actually got it right, a reasonable price for a bunch of stuff which would end up appropriated based on demand (they needed to have the disk to rent.) And how you have a bunch of players trying to compete in the space, each with it's exclusive content to try to make you choose them.

And look what's happened with Google's "news". It's more and more and more clickbait. I used to think the answer was a small charge per article, run through some aggregator that tracked payment. But these days we see things designed to get you to open the page, not to actually provide value. Or look at the problems Amazon has had with it's Kindle Unlimited stuff--books designed to game the metrics, groups engaging in read each other's books behavior etc.

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

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.

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.

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.

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.

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.

it's dead, per official comment from 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.

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.

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.

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.

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.