OSC 7 proxy icon ignores unknown hosts, including blank host (file:/// URL)

[lilyball]

The OSC 7 proxy icon handling ignores any attempts to set it with a hostname that doesn't match the current system. I'd file this as a discussion except that it's also treating the empty string as an unknown hostname, e.g. printf '\e]7;file:///Users/lily\a' is ignored. For that matter someone setting it to a path without the file:// prefix is also being ignored, though Terminal.app handles that just fine.

I do think all of this should be supported, but at the very least using file:///path/to/foo should work since the inclusion of a hostname is merely recommended rather than required.

The behavior for an unknown hostname is to turn it into a remote URL. Here's an example of what that looks like in Terminal.app:

I'm pretty sure you can do this simply by taking the file:// URL you're given and hand it to NSWindow as-is, instead of parsing it for a path and then using that path to reconstruct a URL. Checking the hostname to see if it's local makes sense for the code that opens new windows at the same path though¹, so I think the right thing to do is to keep both a pwd and a proxyIconURL and when you get an OSC 7 you unconditionally set proxyIconURL to that but keep the hostname check before setting pwd (though again, you'll probably want to treat file:/// with no hostname as a local path). This way if I cd to another directory, then ssh to a remote server that sends OSC 7 codes, a new window will open at the same local path that the first window was in prior to ssh'ing.

Footnotes

1. Interestingly, Terminal.app doesn't do this! If I give it a remote file URL and then open a new tab, it still tries to spawn the new shell in the path of that remote URL (and falls back to the home folder if the path doesn't exist locally). I consider that a bug though, it should just separately remember the last local path to use. ↩

[lilyball]

If you want to use this issue to just fix file:///path/to/foo and say "use a discussion for the rest" I'll understand, though the proposed support for remote URLs will also fix the file:/// thing so I'm hoping you'll just do it all.

[mitchellh]

Converted to a discussion. As far as I know, OSC7 has now been specified (kind of) via terminal-wg: https://gitlab.freedesktop.org/terminal-wg/specifications/-/issues/20 As part of this specification, the hostname is now required and is always validated against the local hostname. I haven't re-read this in detail recently so I'll keep this discussion open, but terminal-wg is going to supersede Terminal.app for me if this ends up being true. Following that, seeing what the majority of terminals do will also supersede Terminal.app.

[dgl]

I'm not finding where that spec says hostname is required -- the closed merge request in https://gitlab.freedesktop.org/terminal-wg/specifications/-/merge_requests/7/diffs says:

While the scheme and path are mandatory, the hostname is optional. However,
adding the hostname is recommended, because it allows checking for remote paths
by comparing the URI's host to the one the terminal is running on (e.g. when
using ssh).

The discussion gets kind of distracted by exactly how to deal with unique hosts and SSH. I think there is an opportunity here for Ghostty to adhere to the intent of the spec while supporting some nice features (see my comment on the SSH integration request).

[dgl]

BTW, one aspect not mentioned in the spec, is this is a privacy/potential leak issue as currently implemented in Terminal.app -- it does a DNS lookup to confirm if the host given in the file:// URL is local. Don't do that. (I've reported this to Apple years ago and it's mentioned in a public talk.)

[mitchellh]

As you suggested, I’m somewhat willing to relax these requirements for the sake of the proxy icon, since it’s a unique thing that’s only implemented on macOS and only by Terminal.

I’m not trying to build a Terminal.app clone though so I want to carefully consider if this is the right thing to do or not.

If we go that route, I think we should create a new apprt action that reports unverified URLs directly from OSC7. Then the macOS app can handle that on its own separate from the Ghostty core which can remain adherent to the de facto spec.

[lilyball]

This sounds reasonable to me. Report all OSC7 URLs such that the macOS app can just feed that to the proxy icon, and keep the existing verification logic for the notion of "current directory". If I recall correctly you also decided that the proxy icon should not be part of the window title stack and should instead simply save the proxy icon when entering the alternate screen and restore it when exiting the alternate screen, so if the proxy icon is handled separately from the notion of current directory then the macOS app simply needs to be notified when entering/exiting alternate screen mode so it can handle that itself.