Counterfeit Monkey freezes iPhone Safari

[dfabulich]

I've encountered a reproducible crashing bug in Counterfeit Monkey Release 10. I'm on iPhone 13 Pro, iOS version 16.3.

https://iplayif.com/?story=https%3A%2F%2Fgithub.com%2Fi7%2Fcounterfeit-monkey%2Freleases%2Fdownload%2Fr10%2FCounterfeitMonkey-10.gblorb

After a few dozen moves, Safari will freeze up. The keyboard will be visible, but tapping keys on the keyboard does nothing at all, and the transcript stops being scrollable. I've tried waiting more than 60 seconds to see if it unfreezes, but it doesn't work. Navigating back to the iPhone home screen and back into Safari, it will show the game UI for a few seconds, and then Safari will crash. At that point, if you navigate back into the game, you'll see this on-screen error:

Quixe run: glk_put_jstring: window has pending line input

Clear autosave and restart

You can click "clear autosave and restart," but you'll just hit the error again a few turns later.

Note that Release 10 is hard to play on iPhone because of the map. You can type graphics off in Release 10 after answering the initial questions (y / andra). In Release 11 and up, the map will be hidden by default, and you can turn it on and off with map on and map off.

I also like to use highlighting to highlight words, and this might make it more likely to reproduce, but that could be superstition.

[dfabulich]

@angstsmurf In case you have any thoughts on this

[curiousdannii]

Using Browserstack I can confirm that it gets pretty slow at times, but it's always resumed responsivity for me. Oddly it seems to be hanging after outputting text, not while the VM is running, which is what I'd expect if it was Quixe being very slow processing the game code. No idea of the cause yet.

[angstsmurf]

Is there a previous release of the game where this does not happen?

[curiousdannii]

Does Zarf's Quixe also freeze?

https://eblong.com/zarf/glulx/quixe/quixe/play-remote.html?story=https%3A%2F%2Fgithub.com%2Fi7%2Fcounterfeit-monkey%2Freleases%2Fdownload%2Fr10%2FCounterfeitMonkey-10.gblorb&enter=Play+it%21

[dfabulich]

I just tried it on iplayif.com with release 7, and it froze. I got as far as turning off graphics, turning off the tutorial, turning on highlighting, and going north, and it froze.

[dfabulich]

It did seem to freeze in Quixe, (using the Release 10 link above), but less, and for shorter periods of time.

In Zarf's Quixe, the iPhone keyboard closes after every command you type, forcing you to tap on the command area to re-open the keyboard. I found that sometimes, I'd go to tap in that area, but it just… wouldn't tap. Then maybe I'd leave and reenter Safari, and it still wouldn't tap, but then a few seconds later, it would be tappable again.

It never locked up quite as bad as Parchment did/does.

I note that I was able to play through Lost Pig without issue, so it does appear to have something to do with Counterfeit Monkey. I speculate that the problem has to do with memory usage, and specifically I think it has to do with garbage collection; perhaps CM is generating a lot of garbage, so the garbage collector is freezing after we yield the UI thread.

I might poke around with this at some point. https://webkit.org/blog/6425/memory-debugging-with-web-inspector/

[dfabulich]

I discovered just now that this bug doesn't repro when using an external keyboard on iOS. (Or, to be specific, I tested it using iPhone Mirroring (new in iOS 18). iPhone Mirroring treats your Mac keyboard as if it were an external keyboard.)

When you use an external keyboard on iOS, it doesn't pop up an on-screen soft keyboard. That's convenient, because when playing Counterfeit Monkey, the on-screen keyboard pops up and disappears quite a lot, and it's quite slow whenever it does.

To my surprise, I found that the game didn't crash any more when playing in this way. So I think at least one part of the problem has to do with making the on-screen keyboard open and close a bunch of times.

[curiousdannii]

Does it still have issues with the soft keyboard, even after all the GlkOte improvements I made over the past couple of years?

I wonder if the Glulxe based one on testing.iplayif.com does any better than Quixe does? Or if it is more caused by the keyboard resizing code I have.

[dfabulich]

This bug #134 occurs on both testing.iplayif.com and on production iplayif.com.

IMO, Parchment's on-screen keyboard (OSK) interactions are 100% "correct," in the sense that it does what it's designed to do, at least for games that have just a single window.

1. When you type a command that has a short response, the OSK stays visible.
2. When you type a command that has a response slightly taller than the visual viewport, the OSK disappears. Then, you have to tap on the input line to resume playing. (On my iPhone 13 Pro, that happens when you go north from the starting room; the "Sigil Street" description isn't taller than the iPhone's screen, but it's taller than the visual viewport when the OSK is visible.)
3. When you type a command that has a response taller than the iPhone's screen, the OSK disappears. You then have to scroll down to find the input line and tap on it. (On my iPhone 13 Pro, that happens when you go north from Ampersand Bend into the Fair. (To solve the first puzzle: n. e. remove x from codex. n..)

That is what it's designed to do. But, whenever the OSK goes away in case 2 or case 3, it takes a while, like, at least half a second for the keyboard to go away. (I've attached a screen recording.) And tapping on the input line to resume playing is fiddly.

As a result, IMO iOS Parchment is quite annoying to play, because the OSK goes away a lot, and every time it does, it's slow and fiddly to reopen. (By contrast, iOS Frotz is much more enjoyable, because the keyboard just opens and stays open.)

So, it's annoying but acceptable for smaller games, like Lost Pig, but for Counterfeit Monkey, the game crashes outright. Is that because of all the resizing? I suspect that the resizing is the last straw in terms of using up all of the tab's memory. But it's hard to say for sure.

ScreenRecording_10-20-2024.22-50-18_1_480.mov

[curiousdannii]

I have an iPhone 13 now (thanks IFTF grant!) What I see basically matches your video, though I've never had it crash on me.

The delay on the gameport expanding after the soft keyboard goes down doesn't seem related to CM's size as it happens on other simpler games like the advent.z5.

A few possibilities for me to remember to investigate later:

• Is the on_gameport_resize throttling not working properly on iOS?
• Is measure much slower on iOS?
• Is scroll_window messing things up? Is it even needed any more?

And tapping on the input line to resume playing is fiddly.

You should never need to tap on the actual input line. As long as the input line is visible (not scrolled off), taping basically anywhere should open the keyboard.

[dfabulich]

When you say that you've never had it crash, are you able to play Counterfeit Monkey to completion? It reliably crashes for me on my iPhone 13 Pro within about ten minutes.

[curiousdannii]

No, I haven't tried it that far. I'll try that some time.

[curiousdannii]

After some testing I've realised the keyboard hiding delay is this issue: https://stackoverflow.com/questions/72747030/delay-on-resize-event-on-virtual-keyboard-on-ios-safari

I wonder if there'd be another resize event that would be more responsive. A ResizeObserver perhaps?

[curiousdannii]

I've found a work around for the delay when the keyboard goes away. But it's not fully working after you submit a turn and then there's a really long output.

I haven't yet done anything for when the keyboard goes up, as it wasn't quite as bad as having a half blank screen, though all the scrolling is annoying.

Still haven't tested to see if CM crashes or not.

[curiousdannii]

Even more weirdness. When opening the keyboard I'm not getting just one visualViewport:resize event, but three separate events, at 73ms for the keyboard being up, 259ms for the keyboard being down, and 591ms for the keyboard being up again. What a mess.

But I think I've found a solid solution. Please give it a try now @dfabulich. The scrolling should now be pretty seamless when showing/hiding the keyboard. The only issue is if you repeatedly open/close it in short succession - the event throttling means it might be out of sync a little bit, though it will settle itself out once you stop changing the keyboard status. And normal use shouldn't have any issues.