Make sure that you have Open all external links in a new tab option checked in /my/preferences/interfaceOther interface options (It seems to be the default setting, anyway)
Find any post with an external link – random examples in meta and in try
Click the first external link you find in that post (preferably the same)
It opens in a new tab, good.
BUT:
Make sure that you have Open all external links in a new tab option checked in /my/preferences/interfaceOther interface options (It seems to be the default setting, anyway)
Open same post as previous test
Select any text in this post (1+ letter, 1+ word, any selection will do) – You should see a floating Quote button
Click the first external link you find in that post
Now the external link open in current tab, instead of new tab.
If you don’t have the skills to submit a PR (I don’t think I do) then just using control-click to open in a new tab will work, isn’t hard to automatize, and will solve the problem on every site, even those that don’t open links in new tabs.
I would use Ctrl+click but we have this nice option, called Open all external links in a new tab.
But what this option relay does is Open random external links in a new tab.
It took me months, if not years, to pinpoint a reproduction scheme.
It felt really random to me.
Maybe remove this option, for a consistent behaviour?
I remember trying to setup a Discourse dev environment for a simple CSS issue PR.
But, if I remember correctly, I gave up because my PC was too old and I could not install or run all requirements.
I hope it helps, I haven’t really tested it yet but seems works fine.
Edit: user-select: text should added to the link because not only the .cooked selected text affect it but every selected text on the site. I changed the code.
Here’s the piece of code causing the bug (from app/assets/javascripts/discourse/app/lib/click-track.js)
// Cancel click if triggered as part of selection.
const selection = window.getSelection();
if (selection.type === "Range" || selection.rangeCount > 0) {
if (selectedText() !== "") {
return true;
}
}
Removing this code solves the problem and doesn’t appear to break tests (I have some tests failing before and after the change for some reason but no new ones apparently).
So I’m wondering whether this code does anything useful because one thing it sure doesn’t do is what it says it does, otherwise the bug reporter would experience no link follow at all upon ‘select + click’ but that’s not his complaint.
Can someone share what this code is supposed to accomplish?
I only have access to windows platform for testing.
this fix can be tested easily as the file can be pasted as a whole into the console.
@sam you know which file we should paste in the console after loading a topic page? @Aleksey_Bogdanov could give that file and I could paste it in my Windows Vivaldi, Firefox, Android 9 Kiwi browser consoles, and you could paste it in your iOS, Mac OS Safari.