Shell blank on return from background IOS26

[MikeBeller]

In the latest blink 18.4.2.1052 on IOS 26.1 iphone 16 pro

Description

Open two mosh sessions on separate shells. Return to home screen on iphone. Close phone. Wait a while -- say 20 minutes. When I return often (not always) one of the two shells will be completely blank except the keyboard.

I can restore the screen by quitting the blink app and starting it again.

Expected behavior

Not blank. I should see what I saw on the screen before I switched apps.

Screenshot on return from sleep (blank):

Screenshot on quit and restart app (restored):

[brendandebeasi]

Note this seems to only affect the undrawn session. If I have 2 screens (created via the two finger tap), the “back” screen is the one with the issue, whereas the front screen does not have this issue.

I have tried to resolve this issue over SSH and MOSH, but both have the issue. TY!!

[carloscabanero]

Does the rest of the interface work? Does the double tap Cmd work?

I haven't' seen this for a few years, and it was reported in Discord too. Back in the day, the issue was with the WebKit control, but it could happen more often. I will keep an eye on this. Coming up, we have new controls for the sessions, so I'm thinking of adding something there too.

[carloscabanero]

One more thing, using Mosh, if it is the same issue as before, closing the app and reopening should then recover the sessions successfully. Would you mind trying that next time you experience this as well?

[MikeBeller]

Thanks. Yes quitting (via flick up) and reopening the app fixes it. But just switching apps or going to Home Screen and back does not fix it. Does it make sense to add a “redraw” control to help as a backstop for this and a few other quirky rendering issues that seem to pop up periodically over the years in the issues?

…

On Wed, Dec 10, 2025 at 9:18 AM carloscabanero ***@***.***> wrote: *carloscabanero* left a comment (blinksh/blink#2177) <#2177 (comment)> One more thing, using Mosh, if it is the same issue as before, closing the app and reopening should then recover the sessions successfully. Would you mind trying that next time you experience this as well? — Reply to this email directly, view it on GitHub <#2177 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAM7HKQVIORKH3QFK4MEJ5D4BATTRAVCNFSM6AAAAACORB4ND2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMMZXGMYDGOBQGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[carloscabanero]

Yep, something like that. I would like some way to detect this and do on our own - maybe like a "heartbeat". Since you mentioned it, maybe because I'm more aware of it, I'm actually experiencing this in Safari. Sometimes it reloads itself but others only way to go back from the blank / white page is to reload manually. But the heartbeat as we are expecting could work.

[kkebo]

I have experienced the issue, and it happens even if I don't connect to any servers.

Steps to reproduce (100% reproducible on my side):

1. Open Blink Shell
2. Open two tabs (with a two-finger tap)
   • This doesn't need to connect to a SSH/Mosh server.
3. Go back to the home screen and use other apps for a while (about 5 minutes or more)
4. After a while, go back to Blink Shell.
5. Switch to the other tab (with a swipe gesture)
6. The tab I switched to is blank.

Environment:

• iPad Pro 13-inch M5
• iPadOS 26.2
• Blink Shell v18.4.2.1051
• Full-screen
• On-screen keyboard
• System uptime: about 22 hours 40 minutes
• Free memory: 1.14/16.16 GB

[tamasarpad]

I have experienced the issue, and it happens even if I don't connect to any servers.

Steps to reproduce (100% reproducible on my side):

1. Open Blink Shell

2. Open two tabs (with a two-finger tap)

   • This doesn't need to connect to a SSH/Mosh server.

3. Go back to the home screen and use other apps for a while (about 5 minutes or more)

4. After a while, go back to Blink Shell.

5. Switch to the other tab (with a swipe gesture)

6. The tab I switched to is blank.

Environment:

• iPad Pro 13-inch M5
• iPadOS 26.2
• Blink Shell v18.4.2.1051
• Full-screen
• On-screen keyboard
• System uptime: about 22 hours 40 minutes
• Free memory: 1.14/16.16 GB

I experience exactly the same. If I open multiple tabs and working on one tab, the other tabs go black after a couple of minutes and can not be recovered. They are still connected to the server, if I type I can see the typing in the tmux session (from another ssh session). Nor ctrl b r neither any terminal reset workarounds worked. I need to close the tab. Very annoying.
Ipad Pro M1, IpadOS 26.1, 16Gb RAM
Blink Shell v18.4.2.1052, ssh

[carloscabanero]

Thanks everyone for the thorough testing and steps.

Short version: I was able to reproduce the issue. The hypothesis is that WKWebView itself is hiding the WKContentView during backgrounding, and it should recreate them during foregrounding, but sometimes it doesn't. I have been working and testing two solutions during the weekend, they seem to be working fine but the issue is not easy to replicate from my side. Will push to TestFlight before the Holidays and hopefully we can have a patch asap.

---

And now, long message mostly for myself.

I spent most of last week trying to reproduce this on three devices: iPhone Mini, iPad Air M1 and iPad Pro M2. The Mini and Air were running 18.4.2 built from Xcode and never displayed the issue. The iPad Pro is my main device and was running TestFlight.

The steps were not fully reliable for me to test the issue. I have not been able to trigger it in the Mini or the Air, but I was able to trigger it once in the Pro. I followed the steps (new tabs, move to another app), but instead of playing within the other app (which didn't work), I suspended the device, waited a few seconds (this should trigger a suspension in the app but not necessarily a "kill"), woke up device, launched Blink again, and finally the other tabs were 'blank'. Unfortunately, connecting the Xcode debugger was a no go but using the Safari inspector though, and I could confirm the issue looked very similar to what we experienced a few years ago. The Terminal is there, the debugger shows the rows and all that, it even "highlights" the elements. You can type and the terminal and remote will send characters. But it just does not render anything. The difference this time though is that even after a "refresh", the view was still blank.

And then right when I was preparing a response here, it started to reproduce reliably and I finally connected a debugger to it.

• Experiment 1: What is going on? -> Safari debugger is displaying everything. You can type and it will be shown. The rows are highlighted on the device, but nothing is displayed. Tried to played with the hierarchy and restart something, but nothing worked. JS and ready calls all fully functional. Tried to force a redraw from there, but nothing worked.
• Experiment 2: Can we force the WKWebView to draw the missing content on app side? -> Set a trace on SmarterTermInput layout. The SetNeedsDisplay won’t change anything, same with other layouts, etc... Reload will reload the original background, so we know it is working, but the content will remain the same. ReloadFromOrigin won’t do anything different.
• Experiment 3: What exactly is missing? -> I set a background at SmarterTermInput on both a "blank" terminal and an "Active" terminal.
  • On "blank": The blank showed the color I set, still all rows were being highlighted on Safari debugger, but where is the content? Once I had the view corrupted, then I reset the WKWebView and that reset the background color, so the view seemed to be working. I was not sure what I was seeing here so I tried to Hide / Show the view itself. On view hidden, Safari would not display any highlights, so we were definitely seeing the terminal. On Show, the highlights would go back.
  • On "active": The active did not show the color, where is it? I popped up the View Hierarchy in the debugger and then I saw that the hierarchy of the "blank" and the "active" were totally different. The Active had all the WKContentViews while the blank just had a single orphan UIView, nothing underneath.

• Experiment 4: What does show/hide do? -> When the WKWebView is hidden, the Safari debugger is still active. But, the WKWebView purges the remote layer tree (WKCompositingLayers, etc...). On show, the layers will all come up as-is. The "blank" terminal though will not experience any changes between show/hide (hypothesis, could it be a problem with the show/hide flow underneath? Are we triggering it more often due to some condition?).

• Experiment 5: Can we trigger it at any point within the hierarchy and reset things? -> Tried to both go deep in the WKWebView hierarchy and up. On the Blank, going deep was interesting because it proved that some layers were marked as hidden vs the "active" one. So the "show/hide" at one point would not go down the layers for whatever reason. Nothing could trigger the full hierarchy to come back though.

• Experiment 6: expr self.contentView()?.perform(NSSelectorFromString("_killWebContentProcess")) -> Discovered this "nuclear" option that apparently terminates and restarts the web process. And boom, this one worked and brought everything back up, but it would require a full redraw.

• Open Experiments: The hypothesis is that maybe something from our side on show / hide during background is messing up with a new WKWebView mechanism. This can happen on two paths, when the terminal is sent out of view from the PVC and when the PVC will be instanced again. I have reviewed the paths and implemented a few changes there, currently under testing. One thing that I do not know where to fit is that in my experiments, the app was backgrounded but not terminated. Others are reporting this in a time period where the app would be fully terminated (but not necessarily), but a restart always brought everything back. We also know something on the layers has changed because the CursorHiding mechanism that watches layer changes also broke on iOS26 (takes a few retries to actually get the proper layer).

• Discarded. Initially, I thought maybe we could have a mechanism to detect when the terminal would be unresponsive. This is now discarded because the JS and the terminal are actually running, and it is a problem with the remote tree layers.

• Other ideas: I can identify the issue with (self.contentView()?.layer.sublayers?.first?.sublayers?.first as? CALayer) would be nil on Blank. We could use that to trigger a "full restart" cycle.

[MikeBeller]

Wow -- @carloscabanero that's a huge amount of work. Thanks for looking into it. Sorry this one is so hard to track down. It makes me wish for the old days when putting a character on a terminal just involved sending an ascii code to a VT100 terminal over an RS-232 cable. 😄

[carloscabanero]

Ok, so giving a quick update here, I will do a longer one later on (mostly for myself).

I think I have a fix. I have been testing it for a few days and I haven't experienced any blank screens at all in any of my devices. Because of the nature of the fix, this should also fix the rare issues with terminal misplacements when using the software keyboard - this is thanks to doing less calculations and less work in general, as the system now is more accurate.

I will push on TestFlight first, as this requires a lot of testing from a lot of people with different devices. The fix touches some core functionality, so I want to feel comfortable pushing to everyone once we have had a couple days of testing. If it goes well, which I think it will, I will push to production as soon as possible.

Happy New Year!!

[brendandebeasi]

@carloscabanero I would love to test this. Are you able to add me to TestFlight, please?

I applied with the email deleted sry spambots

Appreciate the deep dive you've done on this one!

[carloscabanero]

Yes, but please send me an email instead to Carlos at blink.sh with the email you want me to use.