Support Ctrl (or Shift) + click on link to open it in a background tab (or a new window)
name: Feature request about: Suggest an idea for this project title: Support Ctrl + click on link to open it in a background tab labels: enhancement assignees:
Is your feature request related to a problem? Please describe. I use pads for working collaboratively on lists of links. I tend to open several links at once in background tabs, then go through them. But opening links from Etherpad in a background tab only works via right click – if the context menu isn't disabled (it is e.g. on board.net).
Describe the solution you'd like I'd like links to behave like standard links. In particular, Ctrl + click on a link should open it in a new background tab, and Shift + click should open it in a new window (by default, in most browsers).
Sidenote: Etherpad should not try to emulate Ctrl/Shift + click but delegate the handling to the browser. There are browser settings and extensions that modify link interaction, and those should still work as expected. Effectively, links in pads should be as close to plain, non-scripted <a target="_blank" href="..."> tags as possible.
Plugin? A previous issue on various other link-related things but also including this (#3533) was closed with a mention of plugins, so I guess it might be possible. However, I believe core Etherpad should mirror the standard behaviour of links throughout the web and only non-standard behaviour would be plugin-worthy.
What browser and operating system are you using?
Note that simply setting contentEditable to false when Ctrl is pressed isn't a great solution because it will break paste via Ctrl-V.
Doesn't middle click do this?
@rhansen Firefox 82 on Debian sid
@JohnMcLear Middle-click inserts the X11 primary selection (on GNU/Linux) because it's an editable field. On normal links though, yes, it would. I'm not sure which behaviour is preferable here since inserting the selection that way should also be possible.
Middle-click inserts the X11 primary selection (on GNU/Linux) because it's an editable field.
FYI: That behavior changed with https://github.com/ether/etherpad-lite/pull/4434. Now middle clicking on a link should do nothing (on X11 systems).
Thanks, I suppose that makes most sense: middle-clicking on a link would (after this issue is fixed) open it in a background tab, and middle-clicking anywhere else would paste the primary selection (on X11).
I was looking at how Google Docs handles URLs and maybe we should imitate its behavior: When you click on a link, Google Docs moves the caret to the click location and pops up a bubble that has its own clickable copy of the link (as well as buttons to edit the link or unlinkify).
Since that bubble is above/below the actual link, that means clicking on the link, moving the mouse, and clicking again. Not ideal in my opinion when working with many links.
For context: my current usage is essentially a (commented) list of URLs to be archived, and the interaction with the document consists of opening links (multiple at once for efficiency), doing something with the opened tabs, then marking them as done in some way (e.g. strikethrough) or noting any issues.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
The middle-click workaround exists now (although it doesn't appear to work correctly, but I haven't been able to investigate yet whether a plugin interferes or similar), but this issue is still valid.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue is still valid.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
No, this still isn't stale.
I'm not sure. It seems to open up in new window when clicking SHIFT + click. Is this still relevant for you?
I just retested with the official trial instance (which I assume runs the current dev version or something close to it?) with Firefox. No, it does not behave correctly.
- Shift + click should open a new window but opens a tab instead.
- Ctrl + click or middle mouse click should open a background tab but doesn't work at all.
- Ctrl + Shift + click should open a foreground tab but also doesn't work at all.
Other link interaction doesn't work either: clicking and dragging a link to the URL bar should open that URL in the current tab; dragging it onto the tab bar would open a tab in the relevant position, etc. None of these things work; trying to drag selects text instead despite the hand pointer cursor on the link.