Sometimes return key doesn't work

[GoogleCodeExporter]

What steps will reproduce the problem?
- I haven't been able to recreate this bug because it prevents me from 
restarting a story file.

What is the expected output or behavior?  What do you see instead?
- Story plays normally for a while and then stops responding to return key. I 
can still type commands, but hitting return scrolls the screen and the commands 
entered are ignored. This happened immediately on loading "Alabaster", and 
something similar happened part way through "9:05" though this later 
self-corrected, leaving a long string of command responses.

What version of Frotz are you using?
- 1.5.3 for iOS

What device model are you using (iPhone 3GS, iPad, iPod Touch 3rd gen,
etc.)
- iPod Touch 

What version of iOS?  3.2, 4.0, 4.3, etc.)
- 4.3.3

Original issue reported on code.google.com by bkal...@gmail.com on 18 Jul 2011 at 3:17

[GoogleCodeExporter]

I have the same problem starting alabaster, and also in bronze, although bronze 
usually resolves itself as described above.  But alabastar is unplayable.  It 
also cannot be deleted.

Original comment by cherryju...@gmail.com on 26 Dec 2011 at 7:37

[GoogleCodeExporter]

Note: a hang like this seems to be consistently reproducible in Aotearoa in the 
help / glossary; hopefully this is caused by the same issue.
However, I haven't been able to reproduce problems in either Bronze or 
Alabaster... both are very computationally expensive games so it may be an 
issue with running on older, slow iPod Touches.

Original comment by spath...@gmail.com on 12 Mar 2012 at 12:59

[GoogleCodeExporter]

Issue 171 has been merged into this issue.

Original comment by spath...@gmail.com on 7 May 2012 at 7:47

[GoogleCodeExporter]

I was about to raise an issue about a bug I've found that sounds very similar 
to this one. Exactly the same symptoms, you press return and all it does is 
move the screen up.

In my case I tracked it down to a single line of code added in Frotz 1.5.3, 
line 534 in the function gli_put_char, file glkios/ipstream.c that sets 
str->win->line_request to 0:

case strtype_Window:
            if (str->win->line_request) {
                gli_strict_warning(L"put_char: window has pending line request");
                str->win->line_request = 0;
                //break;
            }

That line didn't exist in 1.5.2 and earlier.

The Inform game I was debugging (A gblorb created by Inform 1.2 6.31/6H98) was 
executing the line "KeyboardPrimitive(buffer, parse);" to read a line of text, 
and using breakpoints I could see Frotz set "win->line_request" to TRUE in 
order to allow this, but before it could process my typed input 
"win->line_request" had been set back to 0. With some more digging I found that 
when I touched the iPad's screen to bring up the on-screen keyboard, 
"gli_put_char" was called to write out a newline character and that caused 
"win->line_request" to be set back to 0.

Once Frotz gets in this state future calls to "gli_input_handle_key" end up 
doing nothing. That function iterates over the windows looking for one with 
either "win->line_request" or "win->char_request" set to TRUE to indicate that 
it's expecting some input. Since none do, nothing happens.

Original comment by matt.bro...@gmail.com on 27 May 2012 at 7:38

[GoogleCodeExporter]

Thanks for helping debug this!
If I recall, I added that line to try to fix  malfunctioning game that was 
hitting that warning in the line above over and over again, and I noticed the 
game didn't have this problem in Spatterlight, and they reset the line request 
in this situation, although the glk spec doesn't say to do this.

I think the best thing to do would probably be to just back out of that change, 
since it was intended to 'correct' behavior of a glk game that was doing 
something incorrectly in the first place.  (When I have time I'll try to go 
back and figure out what game file that was... I should take better notes.)

Original comment by spath...@gmail.com on 27 May 2012 at 5:23

[GoogleCodeExporter]

In my case the game seemed to work fine in Gargoyle, but that didn't reset the 
line request. I'm not sure where the gli_put_char with the newline when 
bringing up the soft keyboard came from however. With a physical keyboard 
plugged into the IPad it didn't occur, so the line request was never reset, and 
the game ran normally. I tried to reproduce the issue with a basic single room 
game too, but that newline never occurred with either keyboard in that 
situation.

Original comment by matt.bro...@gmail.com on 27 May 2012 at 7:50

[GoogleCodeExporter]

Fixed in svn revision 267.

Original comment by spath...@gmail.com on 27 Sep 2012 at 6:46

• Changed state: Fixed-Pending

[GoogleCodeExporter]

Fixed in 1.6 on App Store.

Original comment by spath...@gmail.com on 23 Oct 2012 at 1:47

• Changed state: Fixed