| Keep in mind that this check+logic would only come into play within the call to `history.push` or the `window.location.href` setter. It's not "add a browser-default click event listener that shims in special behavior" (which wouldn't be able to catch the JS navigation in the first place, since that would be occurring in its own, separate click event listener.) It's instead "when I-the-browser have been called by page JS to do something navigation-like through the native `location` or `history` APIs, first check if the current call stack has a event-listener call triggered by a browser-delivered click event in its ancestry. If it does, check further whether the click was a "special" [middle-mouse-button / shift / ctrl-or-cmd / alt] click. If it was, then cause some other side-effect depending on the "special" modifier [i.e. open the target URL in a new tab, or new window, or download it] while silently failing to actually navigate this tab. Otherwise, proceed with the original semantics of the native `location` / `history` API call that was made." If your game isn't specifically trying to have middle-clicking / ctrl/cmd-clicking navigate the tab, then this check+logic would never fire. --- That being said, in theory, if you bound a listener to `auxclick` and told it to `e.preventDefault()`, that should maybe tell the browser you're doing something special and different where the middle-mouse button isn't just "the left mouse button with extra flags set", and therefore that navigation triggered via the middle mouse button shouldn't be seen as "navigation triggered via the left mouse button with extra flags set." I say in theory because web developers would probably use that to prevent people from opening their site/app in multiple tabs at once. And the whole point here is that people should be able to do this whether web developers like it or not. -- Also, a tangent: Web developers may have what are, to them, good reasons for preventing the user from opening their page/app in multiple tabs. For instance, each instance of a page/app on their site might open its own persistent websocket connection to their backend, and so having O(N) tabs open to their site means O(N) websocket connections. And if many users do that, their backend falls over. Or each instance of the page/app thinks it has exclusive ownership of a local IndexedDB, and so might try to migrate the data in a non-atomic way at any time; where if other instances of the page/app are also running and accessing the same DB, they might blow up, or do the same thing and corrupt the DB. (I've seen both of these in practice. In fact, I believe Reddit [in its new design] does the former; at around ~100 open Reddit tabs, they all crash! [I think it has something to do with their chat system.]) IMHO, any webpage that can't stand being open multiple times simultaneously is badly architected. Such pages have been "coddled" too long by browser vendors, by allowing devs to mostly disable the user's ability to easily open links as tabs. We should stop coddling these pages. If we give users back the ability to easily open tabs on modern websites, we'll see the owners of these sites finally [probably begrudgingly] fix the problems that cause them to want to disable opening things in tabs in the first place. |