upvote
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!
reply
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

reply
I think I've seen one page override ctrl-f for good reason -- it was a page that lazy loaded literally millions of lines of text that wouldn't have fit into RAM.

Every single other page that does it just wastes my time. It's always a super janky slow implementation that somehow additionally fails to actually search through all the text on the page.

reply
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.
reply
On Firefox, the “Prevent Shortcut Takeover” can be used to prevent websites from binding to Ctrl+F/Cmd+F: https://addons.mozilla.org/en-US/firefox/addon/prevent-short....
reply
Half of the time those sites also lazy load anyway so whatever you're looking for isn't even in the DOM yet
reply
And lazy unload, so you can't find it even if you've already scrolled through the whole thing.
reply
I used to hear it called "virtual scroll", and I remember webpages ballooning in RAM when they didn't do it.
reply
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.
reply
Just use Ctrl+G - it does almost the exact same thing as Ctrl+F
reply
it's asking me for a line number
reply
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.
reply
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.

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

reply
It's possible but this seems to be quite rare. In my experience it is always just that they think a div with an onclick handler is the same thing as a link.
reply
I've installed one of those and it doesn't seem to help in the ecommerce case.
reply
This one drives me nuts. I get it if it’s a single page app, but in many cases right-clicking the same link and choosing “open in new tab” works fine so that’s not the issue.
reply
That’s because of React. The React Router is bad and people don’t spend extra time configuring it against its own bugs.
reply
I keep a bookmarklet handy that blocks all keypress listeners to disable this stuff. Agreed it's quite annoying! Can share if desired, though pretty straightforward.
reply
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.

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

reply
Looking at you ctrl+r in web outlook...I want to reload the page not reply to the email!
reply
Try ctrl shift r
reply
There should be a toggle control near the navigation buttons that toggles between document mode and app mode.
reply
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);
  })();
reply