Bug: Push notifications via escape sequence not working?

[josephschmitt]

Supposedly Ghostty supports OSC9

printf '\e]9;Test notification\a'

Or OSC 777

printf '\e]777;notify;Title;Body text\a'

escape sequences to trigger push notifications.

I couldn’t for the life of me get it working on my iPhone. But when I switched to my iPad and ran it, the notification showed up on my iPhone. I'm however unable to get it working from the iPhone to the iPad so not sure what's going on. And then it’ll stop working on my phone, too. I’ve tried doing a sleep and then printing and quitting the apps but still nothing consistent.

[kitknox]

I was mainly testing this feature on macOS when it was originally created. I can go do some iPhone and iPad testing. It is designed to only send notifications when it receives the OSC sequence and that tab is NOT currently the focused tab. That is something I could make configurable in the future. I was actively using this on macOS earlier today and it was working there.

[kitknox]

OK I did some iPad testing. If I trigger a delayed notification via sleep and switch to another tab while in the foreground the notification comes through. If I have anything connected or running that enabled location diary and switch to another tab and then switch to another app the notification comes through. If I switch to another app without changing to another tab before the notification is triggered rootshell filters it and does not send. If I do not have anything running to trigger location diary and switch to another app, rootshell is paused and doesn’t process the notification.

My initial thoughts :

1. Treat backgrounding the same as non-focused tab. As long as rootshell is running, process the notifications based on that criteria.

2. Add a new setting to allow notifications to be processed when received from a focused tab.

3. (Maybe?). I could add an always mode to location diary if any tabs are open. Does anyone want this?

The iOS/iPad app lifecycle is remains different from macOS and doesn’t always act the way you would want. I will think about this a bit more.

[awahlig]

Agree on 1 and 2.

3. (Maybe?). I could add an always mode to location diary if any tabs are open. Does anyone want this?

Also yes. Before I filed the issue about Location Diary for Local Shell, I was thinking about suggesting an always-on mode.

I also think the Session Only should not be a mode but just a switch that forces it on until the app is closed (at which point it goes back to the configured mode). Then it could have a keyboard shortcut and a small toast message to indicate when it’s turned on/off. It could work even if LD is off.

So I would do two modes, Auto and Always, and add an “Always until closed” switch.

[awahlig]

I can confirm (1) working in build 35 (location diary on, OSC 777 in focused tab, rootshell in background).

[josephschmitt]

@kitknox seems to be working more like how I expected in the latest builds on iOS!

[kitknox]

As far as changing the location diary behavior goes I am just holding this until I get an initial build that gets through Apple App Store review. We are now at day 5 of "Waiting for Review". The last reason for rejection prior to this was our use of the MFI YubiKey mode supporting lightning. I've made an AppStore variant of the app now which removes this support as I await Yubico adding the rootshell bundle ID to their allow list. It's wild that third party companies get to device if Apple should approve your app submission. Unfortunately their developer support is unable to provide any ETA or status on this either. A bit frustrating that the extra work to add security features is resulting in delays.

[awahlig]

That’s unfortunate, and I really appreciate you sticking with it. I’m very glad we’re finally getting a proper terminal app for iPads (and iPhones) from someone that cares about security and performance. The other apps already feel like toys in comparison :p.

I agree, it makes sense to hold off on any changes to Location Diary for now.

[kitknox]

The good news is that it went into review today. The bad news is it was rejected for a different reason this time stating that individual developer accounts are not allowed to submit VPN apps. (There were additional asks including me producing a video of the NFC functionality working with a physical device. Weird but not a real blocker.)

[awahlig]

The VPN requirement is likely due to liability concerns.

A video demonstrating the NFC functionality is probably the best alternative when the physical device isn’t available for testing.