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.
A new spam policy for “back button hijacking”
431–440 of 532 posts
Re: A new spam policy for “back button hijacking”
#432Earlier 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…
Re: A new spam policy for “back button hijacking”
#433I 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…
Re: A new spam policy for “back button hijacking”
#434Looks 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
Re: A new spam policy for “back button hijacking”
#435I 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.
// ==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".
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”
#437Looks 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”
#438I 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.
Re: A new spam policy for “back button hijacking”
#439Re: A new spam policy for “back button hijacking”
#440Earlier 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.