Middle click on links must not insert text

[PVince81]

Describe the bug
Middle clicking on links still inserts text

To Reproduce
Steps to reproduce the behavior:

1. Create a text document with a link
2. Middle click on the link to open to a new tab
3. Come back to the editor's tab

Expected behavior
New tab is opened, no text inserted.

Screenshots

Client details:

• OS: openSUSE Tumbleweed
• Browser: Firefox
• Version: 97.0
• Device: desktop

Server details:
c.nc.com

[luka-nextcloud]

Middle click does nothing - neither insert a text nor open a new tab.
It should open a new tab.

[mejo-]

@luka-nextcloud not sure what operating system you're using. The problem with middle-click inserting text is probably on Linux only. There, middle click inserts content from a buffer that contains the last selection. I can reproduce the issue and regularly run into it myself 🙈

[ChristophWurst]

I'm happy to find out it doesn't only happen to me. I'm just used to opening links in new tabs and here in Text that leads to very unexpected text alteration.

[mejo-]

In latest Text (both NC 25.0.2 and NC 26 development branch), middle clicking on links no longer opens the links on Linux. Instead, it only inserts text from the selection clipboard. I don't know which code change introduced that change of behaviour, though. Maybe some upstream changes in Tiptap?

I wonder whether opening links in new tabs also doesn't work anymore on non-Linux operating systems. Maybe people with Windows and MacOS X can comment.

To be honest, I would be fine with this behaviour. Middle-clicking for opening in new Tab is probably a niche featue anyway and those who use it will learn quickly that it doesn't work in Text. It's kindof useless in text anyway as we open external links in new tabs/windows per default.

For me, this solves the issue at hand (other than expected, admittedly 😉). Waiting for others to confirm before closing the issue though.

[juliusknorr]

On macOS middle click also does nothing when clicking a link.

Could be related to introducing the click preventer in 3669903

Without that custom behavior I could imagine an upstream issue like ueberdosis/tiptap#3302

[mejo-]

Could be related to introducing the click preventer in 3669903

Reverting this commit doesn't change the behaviour for me.

In any case, given that the changed behaviour fixed the issue at hand, shall we close this issue?