V17 BackOffice UI overrides natural browser behaviour

[craigs100]

Which Umbraco version are you using?

V17.0.0

Bug summary

Cannot have more than one back office section open at once.

Specifics

With "Content" section open and displaying a page content, can't hold Ctrl key and click on "Settings" and have that open in a new tab as it should do in the Brave browser. This is a regression in UX from the last LTS V13.x

Steps to reproduce

With "Content" section open and displaying a page content, can't hold Ctrl key and click on "Settings" and have that open in a new tab as it should do in the Brave browser. causing a lot of extra clicking and wasted time going from item deep in one section to another item deep in another section.

This is a regression in UX from the last LTS V13.x

Expected result / actual result

Expected the other back office section to open in a new tab.

The other back office section actually opens in the same tab.

[github-actions]

Hi there @craigs100!

Firstly, a big thank you for raising this issue. Every piece of feedback we receive helps us to make Umbraco better.

We really appreciate your patience while we wait for our team to have a look at this but we wanted to let you know that we see this and share with you the plan for what comes next.

• We'll assess whether this issue relates to something that has already been fixed in a later version of the release that it has been raised for.
• If it's a bug, is it related to a release that we are actively supporting or is it related to a release that's in the end-of-life or security-only phase?
• We'll replicate the issue to ensure that the problem is as described.
• We'll decide whether the behavior is an issue or if the behavior is intended.

We wish we could work with everyone directly and assess your issue immediately but we're in the fortunate position of having lots of contributions to work with and only a few humans who are able to do it. We are making progress though and in the meantime, we will keep you in the loop and let you know when we have any questions.

Thanks, from your friendly Umbraco GitHub bot 🤖 🙂

[galaxxy22]

Also noticed right-clicking on the content section below the languages or on a content-node is not opening the "Do something else" items anymore, maybe related

[AndyButland]

Just to note that I can't replicate this on Chrome - "open in new tab" and Ctrl+click seems to work as expected to open the new tab with the expected view loaded. Given we support deep-linking much better than we did in 13, I'd expect this to be the case.

Searching for issues with Brave I do see some reports of extensions interfering here, so that might be something to investigate.

The removal of right-click and the "Do something else" option is deliberate and a different concern, which is discussed here. Ironically one of the reasons for this change is to not override default browser behaviour, which is what this issue is raising a question about.

[skttl]

Also noticed right-clicking on the content section below the languages or on a content-node is not opening the "Do something else" items anymore, maybe related

This is intended, see #16233 (comment)

[craigs100]

If it makes a difference, my set up is:-

Browser: Brave 1.84.131 (Official Build) (64-bit)
OS: Linux Mint 22.2 Cinnamon

Both latest versions with latest updates installed.

I can have the V13 and V17 versions of the same site in the same browser. The V13 will ctrl+click to open in a new tab, the V17 won't.

Package list from csproj:-

    <PackageReference Include="Our.Umbraco.Slimsy" Version="6.0.4" />
    <PackageReference Include="Our.Umbraco.TheDashboard" Version="17.0.0" />
    <PackageReference Include="Skybrud.Umbraco.Redirects" Version="17.0.0" />
    <PackageReference Include="Umbraco.Cms" Version="17.0.0" />
    <PackageReference Include="Umbraco.Community.Forms.uCaptcha" Version="6.0.0" />
    <PackageReference Include="Umbraco.Forms" Version="17.0.1" />
    <PackageReference Include="uSync" Version="17.0.0" />
    <PackageReference Include="uSync.Forms" Version="17.0.0" />
    <PackageReference Include="Umbraco.Cms.DevelopmentMode.Backoffice" Version="17.0.0" />
    <PackageReference Include="Microsoft.ICU.ICU4C.Runtime" Version="72.1.0.3" />

And the Umbraco System Information:-

Umbraco system information
--------------------------------
Server Troubleshooting: 
Server OS: Linux Mint 22.2
Server Framework: .NET 10.0.0
Default Language: en-US
Umbraco Version: 17.0.0
Current Culture: en-US
Current UI Culture: en-US
Current Webserver: Kestrel
Models Builder Mode: SourceCodeManual
Runtime Mode: Development
Debug Mode: True
Database Provider: System.Data.SQLite
Current Server Role: Single

Server Information: 
Umbraco build version: 17.0.0+da502e0
Umbraco assembly version: 17.0.0
Server time offset: 00:00:00
Runtime mode: Development

Client Information: 
Umbraco client version: 17.0.0

Current user: 
User is admin: Yes
User sections: Umb.Section.Content, Umb.Section.Forms, Umb.Section.Media, Umb.Section.Members, Umb.Section.Packages, Umb.Section.Settings, Umb.Section.Translation, Umb.Section.Users
User culture: en-US
User languages: All
User document start nodes: 

Temporary file configuration: 
Max allowed file size: Not set (unlimited)
Allowed file types: 
Disallowed file types: ashx, aspx, ascx, config, cshtml, vbhtml, asmx, air, axd, xamlx
Image file types: png, apng, jpg, jpeg, jfif, gif, bm, bmp, dip, ppm, pbm, pgm, tga, vda, icb, vst, tiff, tif, webp, qoi

Browser Troubleshooting: 
Browser (user agent): Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36
Browser language: en-GB
Browser location: https://localhost:44349/umbraco/section/user-management/workspace/user/edit/1e70f841-c261-413b-abb2-2d68cdb96094

[iOvergaard]

I'll add a few tests from MacOS (latest):

✅ Chrome 142
✅ Safari 26.1
✅ Firefox v109 and v145
✅ Brave 1.84.141 (Chromium 142.0)

Tested on https://backofficepreview.umbraco.com

[craigs100]

Currently, for me, the reported behaviour exists on the backofficepreview link provided.

[nul800sebastiaan]

Can repro on Brave on Linux. Middle-click works though.
I have the exact same problem on Firefox, CTRL+click doesn't work (opens tab in current tab), Middle-click the link works.

I am on Ubuntu and Mint is a Debian-based distro too. Since it's not browser-engine related, I suspect it's more to do with Debian but I've hit a dead end in ChatGPT suggestions (seems to think it's related to accessibility settings but I never touched those and none of them are enabled).

[craigs100]

Have you tried having a V13 backoffice and V17 backoffice open in separate tabs in the same Brave browser? You should find the V13 will ctrl+click but the V17 won't. Hence why I suspect the V17 backoffice rather than the browser or OS.

[nul800sebastiaan]

I did another round with the LLM and yes, came to a similar conclusion. Links are a proper <a> element in v13 so they work. It claims that on Linux no browser will open a link that's on a <uui-tab>, it needs to be a proper <a href..>.

[craigs100]

Interesting! Well I'll have to leave that to the "Wise Ones" ;) Pity because it's loss is keenly felt, even on a simple site :(

[craigs100]

I asked ChatGPT and received the following reply:-

Is this true? On Linux no browser will open a link that's on a <uui-tab>, it needs to be a proper <a href..>

Short answer: No — that claim is not true.

Long answer:

<uui-tab> is a custom element. Browsers treat custom elements like any other DOM element unless they contain built-in interactive behavior. A browser will not automatically treat a <uui-tab> as a link because:

It is not an anchor (<a>)

It has no default click-navigation behavior

Browsers don’t guess navigation targets from custom elements

This has nothing to do with Linux. It is the same on Windows, macOS, Android, etc.

Why your <uui-tab> isn’t opening a link

Browsers open links when:

There is an <a href="…"> element
OR

JavaScript code handles the click and calls window.location = ... or similar.

A <uui-tab> won’t navigate unless you implement that behavior in one of these ways.

Valid patterns
✔ Pattern 1: Put an anchor inside the custom element

<uui-tab>
  <a href="/somewhere">Go somewhere</a>
</uui-tab>

✔ Pattern 2: Make the whole tab clickable using JS

<uui-tab onclick="window.location='/somewhere';">
  My Tab
</uui-tab>

✔ Pattern 3: Extend/customize the component to behave like a link

(e.g., making it fire an event and navigate).

So the claim “on Linux no browser will open a link in a <uui-tab>” is incorrect

The real issue is:

Browsers never automatically treat a custom element as a hyperlink.

If you want navigation, you must use an actual <a> element or add a click handler.

If you'd like, I can show you best-practice patterns for making a web-component tab act like a link (including accessibility considerations). ;)

[iOvergaard]

@nul800sebastiaan and @craigs100, the "href" attribute on the <uui-tab /> element is merely there to pass it down to the underlying <a /> tag.

I wonder if it would help to convert the href attribute on the <uui-tab /> element into a property instead, so it doesn't show in the browser. It is odd that it's a Linux-only issue, and Brave and Firefox work just fine on other OSes.