[derefr]

I wonder why browsers don't intercept JS-triggered navigation (or history.push) events that happen with a click handler on the stack — where it can be determined from the event data of that click handler that the user additionally used the middle mouse button or was holding cmd/ctrl at the time — and rewrite them into navigation-in-new-tab. (Ideally, without making the caller aware that anything different happened than what it was expecting.)

It might not be what the developer of the site/app intended; but it's exactly the semantics the user is expressing their desire to trigger. So why not do what the user wants? Browsers are user agents, not developer agents, after all.

(Before you say "that sounds like a layering violation" — well, yes it is, but that particular layering violation already exists to support most browsers' JS engines' "suppress popup-window / new-tab navigation if the stack of the navigating call doesn't contain a click event" logic. The code ugliness was already bought and paid for; we may as well reap as much benefit from it as we can!)

[yakshaving_jgt]

> it's exactly the semantics the user is expressing their desire to trigger.

That’s not necessarily true. You could imagine writing perhaps a video game or something where this control is intended to have a different meaning. For this reason, I don’t think this is a liberty that browser developers can take.

[8n4vidtmkvmk]

Vivaldi recently took liberty to "restore" a scrollbar to the body tag of my app even though I had intentionally moved it to an inner div. It royally effed up my app with no workaround.

Their intentions were good, but.. you don't know what devs are going to do. As long as they're following spec, let them. Users can vote with their wallet or eyeballs.

NB: I don't want to throw too much shade at Vivaldi. I reported it. They fixed it. Still my fav browser

[derefr]

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.