Noticed I missed ctrl + click, will amend

There is indeed no way to monitor the browser for multiple tabs in CDP. We also don't do this anywhere as we don't really want people to have a lot of parallel cockpit sessions in multiple tabs - we never test this, and at some point the communication overhead becomes quite severe.

I triggered the tests, I'll leave the functional review to @jelly . Thank you!

There is indeed no way to monitor the browser for multiple tabs in CDP. We also don't do this anywhere as we don't really want people to have a lot of parallel cockpit sessions in multiple tabs - we never test this, and at some point the communication overhead becomes quite severe.

I triggered the tests, I'll leave the functional review to @jelly . Thank you!

Thanks Martin, yea, I guess a middle ground is merging the middle click, which works as expected, I didn't really put much thought into CTRL + CLICK, as it currently fights with multiple selection, just wanted to showcase that.

@jelly can I get a review? :), do not mind the ctrl click, I think we need to discuss it further, but if you are happy I can remove it and we could partially work only the middle click

Thanks!

However, this doesn't work as expected:

1. It directly opens the tab, instead of respecting the tab open behavior, where, for example, in when middle-clicking on a link in Firefox, it (by default) opens the tab in the background and stays on the current tab. (This is configurable in the browser, and it should respect the browser defaults.)
2. When opening a new tab, this only shows the content area that is normally in the iframe, but it does not show the rest of Cockpit.

In other words, I would expect it to open in the background like other tabs and be within Cockpit.

1. It directly opens the tab, instead of respecting the tab open behavior, where, for example, in when middle-clicking on a link in Firefox, it (by default) opens the tab in the background and stays on the current tab. (This is configurable in the browser, and it should respect the browser defaults.)

Not able to find anything that would work everywhere, if anything chrome still seems to be the issue: https://stackoverflow.com/a/76529021 whether that is intended or not, I am not sure.

Not able to find anything that would work everywhere, if anything chrome still seems to be the issue: https://stackoverflow.com/a/76529021 whether that is intended or not, I am not sure.

Err... uh... what? That code looks ridiculous. Creating an anchor element from a button? 😕

Why not just use an actual anchor element within the DOM and use that, like intended?

<a href="link-goes-here">filename.txt</a>; then if it's a middle-click, allow it to pass through without preventing default behavior (and without doing secondary event handling behavior too)? Then you have the native action acting upon the native element intended to go places. And the even handler can intercept and preventDefault if it's a middle click (or right click and open in new tab).

Control click gets harder — normally I'd suggest that work too, but file managers generally have control-click for multi-select.

Basically you'd ususally do something like this with HTML + JavaScript like this simple example:

  <div id="fileList">
    <a href="Documents/" class="folder">Documents</a>
    <a href="Projects/" class="folder">Projects</a>
    <a href="document1.txt" class="file">document1.txt</a>
    <a href="image.jpg" class="file">image.jpg</a>
    <a href="archive.zip" class="file">archive.zip</a>
  </div>

document.getElementById('fileList').addEventListener('click', event => {
  // On folders, let a middle click go through and be handled natively
  if (event.target.matches('.folder') && event.button === 4) return;

  // Don't follow the link and instead do other things below
  event.preventDefault();

  // Do stuff to files and folders
  if (event.target.matches('.file, .folder')) {
    console.log('Clicked:', event.target.href);
  }
});

(It basically is using event delegation on the parent of the folders, then checks if it's a folder and if middle click was active, then returns if so, otherwise it prevents default actions and does stuff to files and folders.)

I haven't tested the JS, but it probably works. If I type something wrong, pretend it is pseudocode. 😉

(Hopefully something like the above can be adapted.)

Also middle click on my end seems to not open in foreground, I am using chrome / windows, even with my changes (I am ignoring ctrl click).

(It basically is using event delegation on the parent of the folders, then checks if it's a folder and if middle click was active, then returns if so, otherwise it prevents default actions and does stuff to files and folders.)

Also make sense, will give a try

Also middle click on my end seems to not open in foreground, I am using chrome / windows, even with my changes (I am ignoring ctrl click).

Ah, I'm using Firefox on Linux.

I tried Chromium and see the tabs open in the background as expected. Weird that this is different!

I just tried GNOME Web (WebKit, like Safari) and middle clicking does absolutely nothing at all. No tabs at all, nor navigation.

Hi @garrett, can you take another look? I did test on both chrome and firefox and respects the background opening just fine, but of course in list view, it only triggers from the <a> portion

friendly ping @garrett

@garrett one last check?

Updated to match path changes from #678

It looks fine to me, but we had a philosophical question about enabling this, even at this level, and some high priority things came up meanwhile. So... I'm not sure at the moment.