intfiction.org

The Interactive Fiction Community Forum
It is currently Sun Dec 17, 2017 6:06 pm

All times are UTC - 6 hours [ DST ]




Post new topic Reply to topic  [ 48 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
PostPosted: Fri Aug 11, 2017 10:33 am 
Offline
User avatar

Joined: Fri Sep 30, 2016 7:02 pm
Posts: 404
Location: USA
zarf wrote:
Quote:
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?


(This is about traditional single-window line input.)
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 http://www.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.

_________________
Glulx interpreter Android apps are in open beta testing! Three apps to watch for: Incant!, Thunderword, and Thunderword enhanced Text Fiction.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Fri Aug 11, 2017 11:13 am 
Offline

Joined: Fri Jul 28, 2017 9:04 am
Posts: 32
I commented out those two lines related to resizing and it did not fix CoSv3.blb.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Fri Aug 11, 2017 11:17 am 
Offline
User avatar

Joined: Fri Sep 30, 2016 7:02 pm
Posts: 404
Location: USA
chrisryan wrote:
I commented out those two lines related to resizing and it did not fix CoSv3.blb.


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).

_________________
Glulx interpreter Android apps are in open beta testing! Three apps to watch for: Incant!, Thunderword, and Thunderword enhanced Text Fiction.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Fri Aug 11, 2017 11:26 am 
Offline

Joined: Fri Jul 28, 2017 9:04 am
Posts: 32
Yes, it was on my S8. Also doesn't fix it on the emulator using the recommended Nexus 5X.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Fri Aug 11, 2017 11:31 am 
Offline
User avatar

Joined: Fri Sep 30, 2016 7:02 pm
Posts: 404
Location: USA
chrisryan wrote:
Yes, it was on my S8. Also doesn't fix it on the emulator using the recommended Nexus 5X.


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 ;)

_________________
Glulx interpreter Android apps are in open beta testing! Three apps to watch for: Incant!, Thunderword, and Thunderword enhanced Text Fiction.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Fri Aug 11, 2017 11:36 am 
Offline

Joined: Fri Jul 28, 2017 9:04 am
Posts: 32
I was using your own words from the bolded section ;)

Specifically, commenting those two lines out does not fix the hide/show loop in CoSv3.blb on my S8 or in the emulated Nexus 5X.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Fri Aug 11, 2017 11:37 am 
Offline
User avatar

Joined: Fri Sep 30, 2016 7:02 pm
Posts: 404
Location: USA
chrisryan wrote:
Specifically, commenting those two lines out does not fix the hide/show loop in CoSv3.blb on my S8 or in the emulated Nexus 5X.


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.

_________________
Glulx interpreter Android apps are in open beta testing! Three apps to watch for: Incant!, Thunderword, and Thunderword enhanced Text Fiction.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Fri Aug 11, 2017 11:53 am 
Offline

Joined: Fri Jul 28, 2017 9:04 am
Posts: 32
Retested, and I can confirm I was incorrect. I may have been using the wrong local copy of glkote.js. No keyboard loop.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Fri Aug 11, 2017 12:25 pm 
Offline
User avatar

Joined: Fri Sep 30, 2016 7:02 pm
Posts: 404
Location: USA
chrisryan wrote:
Retested, and I can confirm I was incorrect. I may have been using the wrong local copy of glkote.js. No keyboard loop.


Cool. If nobody else is working on a solution, in the next few hours I hope to come back with a hidden-input code to try.

_________________
Glulx interpreter Android apps are in open beta testing! Three apps to watch for: Incant!, Thunderword, and Thunderword enhanced Text Fiction.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Fri Aug 11, 2017 2:15 pm 
Offline
User avatar

Joined: Fri Sep 30, 2016 7:02 pm
Posts: 404
Location: USA
zarf wrote:
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.


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.

I'm adding a sustained input element to the page, edits here: https://github.com/WakeRealityDev/quixe ... 5f714454c5

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.

_________________
Glulx interpreter Android apps are in open beta testing! Three apps to watch for: Incant!, Thunderword, and Thunderword enhanced Text Fiction.


Top
 Profile Send private message  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 48 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

All times are UTC - 6 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group