Don't re-append the inputel in line input mode

[curiousdannii]

This fixes to a large extent the rapid race condition flashing of the keyboard reported in erkyrath/quixe#32

[erkyrath]

Let me go through the logic and make sure I know the plan:

Your change is meant to only call frameel.append() when the input element is first created, and otherwise to leave it in the same place in the DOM.

• If line input was just accepted and is now being restarted, then win.inputel will be null, and this has no effect.
• If line input is continuing through some other event (like resize or timer), then the window DOM has not changed and it's correct to leave the input element in the same place.
• If character input is continuing, text might have been printed, in which case we'd want to move the input element, really. But City of Secrets doesn't do this.

Is all that correct?

[curiousdannii]

Yep that's correct. But won't the case of character input continuing after newly printed text be handled by accept_one_content? (Except it only covers buffer windows not grid windows?)

[innodonni]

Issue erkyrath/quixe#32 causes Android Accessibility Suite's TalkBack feature to abort reading new transcript output even though the element has the attribute aria-live="polite". In the case of one buffer window and line input, this patch allows selecting the output to be read manually (unfortunately, Firefox for Android 68.1.1 then crashes when navigating with TalkBack).

I have set up a copy of windowtest.ulx and Quixe 2.1.6 with this patch at https://innodonni.github.io/play-full.html to facilitate further testing. Typing "open bottom fixed buffer 5" followed by "getline" seems to function nicely on Android, although the new input is not focused automatically.

Is anyone able to test this on iPhone with Siri?

[erkyrath]

Finally got this one in! (I still have to run it through some more tests.)

Thank you for your patience.