To reproduce:
But if I follow that same process in Windows Glulxe, menu navigation works as expected.
Unable to reproduce in Firefox on Ubuntu—pressing ESC or X works as expected, but only once I’ve scrolled to the bottom of the text.
Is it maybe a “where is the keyboard focus” issue? Esc or Q or X work for me if I click or tab to refocus the input field… which is a perennial problem with web-based interpreters for me
Ok, yeah…if I scroll to the bottom, then click, then press Esc or Q or X, then Esc/Q/X works as expected.
If I don’t scroll, but I do click, then press Esc or Q or X, then Esc/Q/X does not work.
If I tab (which I guess auto-scrolls to the bottom), then press Esc or Q or X, then Esc/Q/X works as expected.
If I scroll to the bottom, but don’t click or tab, Esc/Q/X doesn’t work.
Parchment doesn’t know when something is a menu. In a menu it might make sense to be able to press Esc to leave it early, but in other situations it wouldn’t. So Parchment’s normal behaviour is that it doesn’t respond to keypresses unless the window is fully scrolled down.
But there does seem to be one scrolling bug here: if you click, then scroll, then keypress, it’s not recognising the keypresses. That’s weird! I’ll try to fix it. Click then scroll and keypresses aren't recognised · Issue #46 · curiousdannii/asyncglk · GitHub
I noticed the same thing a few days ago when testing a Z-code game, it was waiting for a key-press but Parchment got stuck at that point (nothing would happen).
In my case, it waits for a key-press on an empty line, could that have something to do with it?
If the game is waiting for a keypress, in what situation does it not make sense to respond to a keypress?
I’m wondering if there is some way of handling this that doesn’t make it look like the game has crashed. For example, if the game is waiting for a keypress, and the player presses a key, but Parchment wants the game scrolled to the bottom first before it accepts the keypress, can Parchment respond to the keypress by scrolling to the next screenful of text or something? Or can Parchment communicate the expectation to the player somehow (“Please scroll to the bottom before pressing a key”)? Or can Parchment make an educated guess about whether there’s a menu on the screen? For example, check to see if the word “menu” appears in the status bar? (That’s probably not a very good rule of thumb because sub-menus may not say “menu,” even if the main menu does. But maybe someone else will have a better idea.)
When the player hasn’t finished scrolling whatever instructions there might be explaining what keys to press may not even have been read yet! I also don’t want the game eating any keypresses that the browser would use to scroll the window.
Well when the bug is fixed I don’t think it will appear to be crashed anymore. That should do for about 95%+ of cases.
This is what Quixe (Lectrote) does, and I think it’s what people expect as “standard” scrolling behavior.
Well Parchment tries to keep the standard browser behaviours working… so the down arrow, page down, and space will all scroll downward. Other random keys won’t. Quixe behaves more like a console app in that regard, but I don’t think it’s objectively more standard.
In any case, while people no doubt do have opinions about these edge cases, they’re typically very quiet about them. In all the years I don’t think anyone has ever before indicated to me that they’d like something different for Parchment. (There’s maybe been a little bit of desire of seeing a “more” indicator, but not for many years either.)
Parchment’s behaviour is indisputably buggy right now, so I will fix that, though I don’t think its general scrolling behaviour needs changing.
I guess my intuition is that if space scrolls down (in a “MORE” context), then why not X and Q? It feels like it should be analogous to “Hit any key to continue”, rather than “Hit SPACE to continue” (which I never like – what is gained by discriminating?)
But it’s true that we never write this stuff down! Maybe we discussed it back in the 1990s, but I can’t remember.
One thing I noted while trying to figure out browser behavior on mobile devices (that activity isn’t abandoned, by the way, but I think assessing Inform’s Parchment release should wait for now), is that it can be hard to prompt a discussion about interpreters. People probably have strong opinions about them (or at least more than 3 or 4 do), or at least some players would like to have good experiences with parser IF in browsers mobile or otherwise, but that thread never took off.
I personally prefer the any key approach, but perhaps that’s because all of my games are released with Quixe. It’s just what I’m used to.
I’ve ranted about this before, but I’ve long believed that GUI Glk interpreters should have a separate input box for the player to type in, instead of what we do now, where the input box is inside the transcript.
The traditional IF UI is a commonplace stdio application, but stdio is totally unheard of on the web.
Consider this bog standard IF transcript:
At End Of Road
You are standing at the end of a road before a small brick building.
Around you is a forest. A small stream flows out of the building
and down a gully.
> east
Inside Building
You are inside a building, a well house for a large spring.
There are some keys on the ground here.
There is tasty food here.
There is a shiny brass lamp nearby.
There is an empty bottle here.
> examine lamp
It is a shiny brass lamp. It is not currently lit.
> get lamp
Taken.
The feeling of play is conversational. You might imagine that the game is playing the role of a Dungeon Master in Dungeons and Dragons, where the player and game are taking turns speaking.
If you’d never heard of stdio, and you were coding a “conversational” game today, you’d probably take examples from chat-based apps like Discord/Slack, where there’s a fixed input box at the bottom of the screen, and a transcript of messages in the main part of the window.
But that is not at all how IF games work (not how they have ever worked historically). Instead of having a separate “input box” into which you type commands, there’s just one main window area, the “transcript.” The game prints messages into the transcript, then prints a prompt symbol (the > symbol) and lets the user type directly into the transcript.
To extend my D&D metaphor, you might imagine the Dungeon Master writing something on a piece of paper, then handing that same piece of paper over to the player, who would write something at the bottom and then hand the paper back to the Dungeon Master, taking turns writing on the page.
That creates bugs that are hard to fix (impossible to fix?) for screen readers and on mobile, and IMO it created the bug bg reported here.
You can’t focus on an <input> in the transcript when the input prompt is scrolled off the screen, so nothing was focused at all, making the page appear to be unresponsive.
But you absolutely could keep focus on the <input> if the input is fixed to the bottom of the screen.
I’ve now fixed this. It was actually a recent bug, which I’d unexpectedly introduced by fixing a check which had previously never passed, meaning that buggy code from 5 years ago finally started having an effect.
I decided that I would do this for regular letter key presses, so Q will now scroll the page down, but Esc won’t. This seems like a safe approach.
Yes, that should be good. People will generally not be surprised if Escape does something unusual. And it’s never bad if page-up, page-down, etc are reserved for scrolling.