Live data from Hacker News

A new spam policy for “back button hijacking”

developers.google.com

431–440 of 532 posts

Re: A new spam policy for “back button hijacking”

#431

Earlier quoted context omitted.

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…

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

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.

Re: A new spam policy for “back button hijacking”

#432

Earlier quoted context omitted.

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.

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…

"You're browsing it wrong." This and other bizarre behaviours are why you'll never catch me using the thing.

Re: A new spam policy for “back button hijacking”

#433

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…

Was honestly thinking "yeah nice Google, now do it for Android" since the worst offenders are apps (looking at you, Tiktok)

Re: A new spam policy for “back button hijacking”

#434

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

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.

Re: A new spam policy for “back button hijacking”

#435

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.

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

Re: A new spam policy for “back button hijacking”

#436

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

You can mostly do it with ublock origin filters. Here are mine, though they do more.

www.youtube.com###contents-container > .ytd-rich-shelf-renderer.style-scope

www.youtube.com###rich-shelf-header

www.youtube.com###content > .ytd-rich-section-renderer.style-scope

||www.youtube.com/shorts/$document

Alternatively on firefox you can use either the "unhook" extension (https://addons.mozilla.org/en-US/firefox/addon/youtube-recom...) or "enhancer for youtube" (https://addons.mozilla.org/en-US/firefox/addon/enhancer-for-...) extension (which has an option for this).

Re: A new spam policy for “back button hijacking”

#437

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

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.

Re: A new spam policy for “back button hijacking”

#438

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.

There should be a toggle control near the navigation buttons that toggles between document mode and app mode.

Re: A new spam policy for “back button hijacking”

#439
post #300

Earlier quoted context omitted.

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.

Re: A new spam policy for “back button hijacking”

#440
post #276
post #265

Earlier quoted context omitted.

If you're referring to Google Safe Browsing lists, all major browsers check agains the same list. I've managed to get mine listed there and immediately banned on all major browsers.

Not only that but I think Google listens to "cyber security" companies lists and feed from them. My website got in some of these lists ( https://www.virustotal.com/gui/url/a4c9f166d2468f5bbb503ec79... ) and I had to go through like 6-7 of them to whitelist my domain again. Something about code and input triggered something in some of these list's filters that my website is hacking related.

[flagged]
Post reply on HN