Shreya

It is a real objection, and the core of it is that hover is not an intent signal.

A click says "I want this". A pointer passing over something says nothing at all — the pointer has to cross the screen to get anywhere, and it crosses whatever is in the way. If crossing triggers navigation, then every journey across your menu bar fires actions the user did not ask for.

The browser chrome makes this worse in a specific way you will have felt. Reaching for the address bar, the back button or a browser tab means travelling upward through your navigation. On many layouts that path goes straight across every menu item. So the user reaching for the browser triggers several navigations in your app on the way out.

That is not novelty discomfort. That is the interface acting on movements that were not addressed to it.

If you do it, the implementation details are what separate acceptable from hostile.

• Only when it can help. Intercept on the screens with virtualised or server-side content. On an ordinary page, leave it alone.
• Make the escape obvious. Pressing the shortcut again, or pressing escape, should get out of the way and let the native behaviour through. Some apps show a small hint: "Press again for browser search".
• Behave like find-in-page. Highlight matches, support next and previous, do not navigate away, do not lose the user's place. If your search does something dramatically different — running a query, changing the route — you have not replaced the shortcut, you have hijacked it.
• Never swallow it silently. The failure mode people hate is pressing the key and having nothing visible happen.

Get those right and most users never notice a difference, which is the goal.

The question that decides it: does state need to be shared between the open sections?

If each section is independent — a document, a record, a report — browser tabs are almost always right. You inherit an enormous amount for free: back and forward, bookmarks, history, open in new tab, restore after crash, drag a tab to a second monitor, and a tab management model every user already knows.

If the sections share live state — a running process, a websocket, an in-memory dataset, an editor with cross-references — in-app tabs start to earn their cost, because coordinating that across browser tabs is genuinely hard and often means rebuilding it anyway.

Everything else in this decision is secondary to that one question.

There is a targeted exception that already exists and does exactly what you want: a page with unsaved input can ask the browser to warn before it is closed.

That is why closing a tab with a half-written message in some webmail clients does prompt you, while closing a tab showing an article does not. The decision is delegated to the page, which is the only party that knows whether anything would be lost.

Browsers have progressively tightened this because it was abused — sites used it to keep people from leaving — so the dialog is now generic, cannot be customised, and only appears if the user has actually interacted with the page. That constraint is itself a nice illustration of what happens to any interruption mechanism that gets misused.