Your statement isn’t making sense to me. As I (speculate) understand the issue, the sequence is this:
User is at > prompt of story, types in “go west”, sent to Glulx to advance the story turn / frame
input element removed or focus to nothing by the web app
Android OS responds by hiding the keyboard
Glulx responds with next turn / frame of the story to draw
input element is added + focus put on input by the web app
Android OS responds by activating the keyboard at the newest > prompt
I’m suggesting step 2 changes: shift focus to another input field on the HTML page. Changing focus between two input fields of an HTML page, like using [tab] key on a keyboard when entering a username and password for login to Amazon.com - does not make the keyboard hide and reappear.
I see what you’re saying, however your description can’t be the entirety of the issue, because it gets stuck in a hide/show loop that persists after the input is recreated and the next turn has been rendered. It would not actually be a big issue if the keyboard hid and showed again one time between turns, IMO. Annoying, but not unplayable.
You and I are on different pages. 1) The prompt of City of Secrets and similar that goes crazy. 2) Other ‘routine stories’ that don’t have the crazy behavior, but I still noticed briefly that the keyboard goes away and comes back in routine interaction.
To describe #1 crazy behavior there would be more than the 6 steps going on. But the general issue I’m raising could be the same: Is the input field being removed, disabled, or otherwise? On a hard keyboard / USB / Bluetooth - that works OK, but on a soft keyboard with Android - that’s possibly the problem: Android believes there is no need for the keyboard any more.
At this point, what I’m asking for clarity on: What happens to the HTML input field after a user types in a response and presses [enter] key. Is it being removed, disabled, what?
Not recently. However, I would point out that the issue with Z-machine is that they are almost always “classic two-window layout”. This is why a lot of interpreters don’t support .z6 stories. And why Android had gone a decade with little to no ability to run Glulx stories - because once you get into Glulx stories like 2010’s Best of Three - you have to get much more into Glk features like timers, multiple windows, multiple input sources, etc. Android apps like Son of Hunky Punk, Twisty 1, Text Fiction, etc - all only support two windows, and only one of those windows takes input. That one window can also be practically any size. It becomes much more complex once you have 8 windows in defined places on the screen and multiple places to put a cursor or mouse.
Whether the keyboard should be hidden after you’ve entered a command or hidden and then shown only when you tap the screen is a personal preference. Some prefer to have it always visible, others prefer to maximise the space on their phones for reading. Ideally the terps would let you choose.
That’s a separate matter from the race conditions shown in City of Secrets. I’d recommend filing a separate issue for the first, but leaving it to be dealt with after the much more serious buggy behaviour of the second is fixed.
Social gate-keeping here? Since the six steps I was discussing before happen extremely fast, keyboard goes away, keyboard comes back - like on the order of 1/100th of a second, why do you think it’s not a relevant discussion? I can’t imagine user preference to flap the keyboard and flash the screen. The discussion I initiated was about a proposed fix of having a hidden input control and setting focus to it if indeed there is no input field at all set with focus (which is still an ‘unconfirmed theory’ as to the behavior I’m witnessing and trying to interpret conceptually).
(This is about traditional single-window line input.)
The input element is removed at the accept_inputcancel() stage and then a new one is created at the accept_inputset() stage. These are called from the same function (glkote_update), so there’s no time interval in which the browser presents a DOM with no input line. However, mobile browsers are obviously still uncomfortable with it.
I guess the direct solution is to keep the input element in the DOM and just move it. I’m not sure if that will actually work, however. The discussion of the CoS-character-input case seems to imply that jQuery’s implementation of “move an element within a DOM” will still cause a keyboard close on Android!
(Mixing the two issues, as I suspect they are both related - one is just looping very fast, but the issue of “disappearing keyboard” I suspect exists in traditional single-window line input.)
The conceptual theory here is that a “browser window resize” is the significant event on the disappearance of the Android soft keyboard in this specific webapp. Normally people don’t think of resizing a window on a mobile phone, but with Android 7 and newer starts to allow resizing of windows more like a desktop system - and that’s the the theory of what is going on with the soft keyboard on Chrome with all Android versions.
Normally web pages are resized all the time with the cursor sitting right there in that input field. I’m proposing that it is in fact this particular webapp that’s choosing to remove the html input field in response to a window resize. If I’m on a typical HTML page, like intfiction.org phpBB, is it removing the input field when I resize a window (and possibly on normal player turn/frame)? Recall: earlier in the thread we confirmed turning off resize events fixes City of Secrets v3 on Android. Is that removal of input field the key behavior difference of why this particular web app is behaving this way and Android reacts different - when other HTML web pages / apps don’t have this keyboard behavior on Anroid?
Is anyone looking at this code and trying one/both of the two ideas: 1) hidden input field, shift focus on, shift focus back. I figured that involves less code changes. 2) zarf is proposing have jQuery reposition the input control. If nobody else has time, I can take a stab a it now.
I’m still thinking this should be optional change, at least to start with, a parameter or setting in the webapp. Please excuse my messy verbosity on all this.
Was this on your Samsung S8? On a 10" tablet in landscape mode - when I disabled resize, it did exactly that. When I raise and lower the soft keyboard - the story opening graphic does not shrink to the ~top 40%. In other words, Chrome and the webapp behaves just like it does with a hard keyboard and no code disabled. If nobody is looking at the code right now, i can dive in and retest and start to look at the next step (hidden input idea / focus).
Your use of word “fix” is ambiguous to me. I was not proposing these two lines as a “fix”, merely to confirm that the resize was significant to the issue. Does it change the behavior of resizing the content of the page? Anyway, I’ll retest now… maybe it was 3 lines
Sincerely, I still don’t understand if you are saying it altered the size output, did it change ANYTHING? Earlier in the thread I also talked of changing resize timer to 3.0 instead of 0.something - and to me that dramatically changed the keyboard behavior. You could visually see that the resize is what was triggering the keyboard to open/close without me touching or otherwise commanding the device.
For sake of additional clarity: I just rested unmodified code on 7.1.1 Emulator @ 10" tablet. And it isn’t looping endlessly. To me: the symptom is that the soft keyboard is up, and I press back to make it go away - and it re-asserts itself. This prevents me from seeing the story in full size, as the web app insists on countering my request to hide the keyboard.
This is proving insightful education for me. So far, eliminating the removal of elements and shift-focus to a always-present element does not cure the problem. I am now pursuing if it is the addition of the new input element that’s the issue. This seem to invalidate my theory about having zero input elements being the reason the keyboard retracts.
Remove not seeming to be the issue: I still don’t understand precisely why keyboard goes away yet. Is it the blinking (which continues even with the keyboard retracted) or something else asserting the keyboard? I notice when I click back/forth on the “sustained input” field and the “press any key” window of City of Secrets that the keyboard goes uppercase and the blinking begins.
More questions than answers at this point. Hopefully we figure it out soon.
