Add repo file tree middle click open

[bytedream]

When clicking a file in the repo view file tree with the middle mouse button, the file will be now opened in a new tab.

file-tree-mouse-click.mp4

[wxiaoguang]

It should also follow the browser's default behavior: Ctrl+Click / Command+Click means "Open in New Window"

[bytedream]

Done, thanks for pointing this out

[wxiaoguang]

Everything is handled in @click.stop, so the @click.middle.stop should be removed?

[bytedream]

@click.stop does not fire for aux clicks. @click.middle.stop is transformed into a mousup event by vue internally, which is able to recognize aux clicks. @auxclick.stop also exists, but Safari only added support for it lately, so it may not work for some users with older browsers.
@click.stop only fires if the click is released on the same button where it was pressed. The mouseup event always fires when the click is released, regardless of the starting point. This difference in behavior is why I didn't unify both handlers into a single @mouseup.stop.

[wxiaoguang]

@click.stop only fires if the click is released on the same button where it was pressed.

But that's the expected behavior.

For example, if you "mousedown" in a normal <a>, then move mouse out, the link won't open.

[bytedream]

What I just wanted to say is that I didn't unify both calls into a mouseup because that would mess with the current behavior

[wxiaoguang]

What would happen if "Ctrl+LeftClick"? I guess it won't trigger click.middle?

[wxiaoguang]

It doesn't seem right. Here it is doLoadDirContent, not doLoadFileContent. And does it really work here?

[bytedream]

9c4a8e2. Yes it works here, it doesn't matter if the target is a file or directory

[wxiaoguang]

By doing some searches, I think "middle key" is not a widely used approach to "open a new window". I do not see browsers officially support it.

The widely supported approach is "Ctrl+LeftClick"

[wxiaoguang]

If you'd like to support "middle click", the ideal approach can be like this:

• make the items to be real <a> links, then middle-click works for users by default.
• use our @click handler to handle ctrl/meta keys, and stop the default link's behavior.

[silverwind]

I think we should just render a native <a> element and only preventDefault the click event with button 0, while letting the browser handle all other interactions.

This way, stuff like middle click, ctrl+click, cmd+click will all work natively and don't even need explicit handlers.

[wxiaoguang]

I think we should just render a native <a> element and only preventDefault the click event with button 0, while letting the browser handle all other interactions.

This way, stuff like middle click, ctrl+click, cmd+click will all work natively and don't even need explicit handlers.

The same as #34730 (comment) ? Or is there something I missed?

[silverwind]

I think we should just render a native <a> element and only preventDefault the click event with button 0, while letting the browser handle all other interactions.
This way, stuff like middle click, ctrl+click, cmd+click will all work natively and don't even need explicit handlers.

The same as #34730 (comment) ? Or is there something I missed?

Basically the same, but I guess the code still need to check whether any modifier key is held, and only e.preventDefault when none are because deciding only on e.button is not enough.

[wxiaoguang]

I see, maybe ideally it could be like this:

• use <a> for tree items with real links.
• if no ctrl/meta/alt key, then use our "fetch" to load the file view content without reload, and preventDefault.
• otherwise, we do nothing and leave the work to the browser.

[silverwind]

Yes, so basically:

if (e.button !== 0 || e.ctrlKey || e.metaKey || e.altKey || e.shiftKey) {
  return; // let browser handle the click
}

e.preventDefault();
// update view to clicked file

Maybe shiftKey can be removed, I'm not aware of any special functionality tied to it. altKey is useful for text selection within a link.