Frequent spurious command-click file opens on macOS

[resistor]

I'm seeing a new problem in 1.1.0 related to the spurious link clicks (particularly on file paths) when I'm trying to copy/paste something from GhosTTY.

What happens is:

• I highlight a blob in GhosTTY that happens to end with a file path
• I start to press Command-C to copy the blob before I've left go of the mouse button
• When I release the mouse button, GhostTTY interprets it as a Command-Click and opens the file at the path at the end of the blob.

I'm hitting this issue several times per day, and it's quite annoying because it often ends up launching Xcode, which takes forever. I want to have Command-Click to open links, but something has changed that's making it overzealous here compared to 1.0

[resistor]

This is continuing to happen for me at least 5 times per day.

[taylrfnt]

I think the most straightforward answer is just going to be to be careful that you don't overlap inputs. The recent changes, as far as I understand them, were to introduce more matches for uris (files, web links, etc.). I haven't noticed any increase in sensitivity in recent releases in my workflows.

That said, I am on tip and this is an easily reproducible "issue" (I hesitate to call it an issue since this is the super+click feature working as advertised). I don't know that there's much more to this discussion unless one of the relevant subsystem maintainer(s) have any thoughts about if there's any merit to changing the current implementations.

[resistor]

I hesitate to call it an issue since this is the super+click feature working as advertised

There's are at least two aspects of this behavior that are surprising to me:

• A click that initiates a text selection probably shouldn't also count as a click for the purpose of super-click. In general a mouse-release while highlighting should never trigger an action.
• More broadly, click-then-super shouldn't be treated as super-then-click.
• It's a little surprising to me that super-click is triggered on mouse-up rather than mouse-down, but this one seems less clear cut.

An alternative that would at least mask this issue would be to allow super-click to be remapped as super-double-click, which is what Terminal.app does.

[taylrfnt]

I think I misunderstood the method you were using for highlighting text - I assume you were double or triple-clicking (or some other variant, there's lots in the iterm/Terminal.app world).

I was able to reproduce it easily with overlapping my selection clicks and command key via double/triple click selections, and that was my perspective originally, since the overlap is truly a normal command + click action.

It sounds like you are saying this is from manually (click-and-drag) highlighting text, so I'll have to do some more digging to try and reproduce!

[taylrfnt]

Alright, did some more testing and it does indeed happen with click-and-drag style highlighting as well. I would have to dig into the source but just in my testing it appears to be that click events that open links are triggered on release of the mouse click, not press (you can verify this by attempting to open any link using cmd+click and "holding" your mouse button down for a few seconds prior to releasing it), so that is likely the culprit here.

A maintainer would likely need to confirm if this is intentional behavior or not.

[resistor]

Yes, I am highlighting text via click-drag drag, and then getting an inadvertent super-click when the mouse-up from the click-drag overlaps with the super key being pressed for copy.

As I enumerated above, triggering super-click on mouse-up rather than mouse-down seems like a questionable UX decision, but if we're determined to have it work that way then I think the other two surprises would still benefit from addressing.