Hide, Remove, or Move: "Open link in split view" context-menu action

Capability Request: Simplify Context Menu actions - by removing “Open link in split view”

  1. Enable ability to action Open a Link in (New Tab|New Window|New Private) in context menus without risk of false positive selection of unrelated features like new UI/UX “Split View” action. Explicit-allow context menu would be ideal.

-or-

  1. Enable removal of “Open link in split view” action from all context windows. Explicit-deny is ugly, but works.

Opportunities to solve:

When I accidentally trigger split view, it breaks my workflow and some of my UI/UX automation, requiring me to stop, determine what broke, manually undo the unwanted view, and re-open in tab or window (depending on use-case). It is a constant cognitive tax from a feature I will never use.

Security Implications: this feature also forces unauthorized UI behavior:

Previously, I had explicitly disabled “Split View” and “side-by-side” flags in Brave. Recent updates effectively blocked my explicit permission, forcing this explicitly-deauthorized UX into my workflow. Is silent scope-suppression an ideal AuthZ model and best practice to propagate, in an agentic AuthZ world?

How can this issue be reproduced?

  1. Launch Brave Browser + Load browser content with links
  2. Trigger context/action-menu over link
    1. (Default trigger: right-click mouse, or shift+F10 in windows IF mouse context persists sufficiently)
  3. Contemplate why “Change UI Mode” feature embedded in “New Object” UX list.

Expected result:

Action = New Window | New Private Window

Generally for automation I use new windows.Window, to leverage windowId. Prefer not to deal with arrays of tabs and their permission issues, or attempt to parse splitViewIds.

Brave Version( check About Brave): 1.87.186

Additional Information: Reference:

10/2025:

forum: brave feature requests, desktop requests
tags: linux

10-11/2025:

forum: browser support, desktop support
tags: windows

forum: browser support, desktop support
tags: browser

10-12/2025:

forum: browser support
tags: windows browser feedback performance

It was removed from Chromium itself (the entire mechanism to make it switchable) and is now a permanently baked in Feature. Every Chromium browser is now forced this way, and once the mechanism (the lock) is removed, the key no longer controls anything.