Input complexities

[curiousdannii]

• Android browser (Chrome)
  • Focusing an input forcibly scrolls the input into view, and you cannot scroll the window afterwards. This means that if we focus the input and the last update is longer than can fit on the screen, we cannot make it show the update from the top. The solution I've found is to measure the height of the input, and to only focus the input if the update will fit even with the virtual keyboard taking up half the screen.
    For now I'm applying this code in all browsers. If focusing the input is important for screen readers or something else, then we may be able to do some feature/bug detection.
  • There's a weird bug in which the browser or virtual keyboard thinks that spaces remain in an input, even though the value of the input was emptied, such that backspace events aren't sent until all phantom spaces have been deleted.
  • Investigate the VirtualKeyboard API
• iOS
  • Safari changes the visual viewport when the virtual keyboard is shown, rather than the height of the true viewport. It also likes to scroll the window even though body is meant to be height: 100%.
  • iOS 15.0 has a bug in which the visual viewport height doesn't account for the URL bar when the keyboard is active
  • iOS screen layout incorrect while opening the keyboard #14
• Screen readers
  • iOS VoiceOver: it's hard to focus the text field in char input mode #13 - because it was offscreen?
  • Inactive <input>s should be aria-hidden
• General
  • I switched to the flexbox system because it means I don't have to handle repositioning when the browser is resized. But if it adds complexities because of the <input> being moved, then we can change back to absolute positioning so that it's moved visually but not moved within the DOM tree.
  • GlkOte has been semi intended to play nice with others things in the page. The "app" sets the styles for #gameport, and GlkOte stays within it. This would let you put other things around the page, including a header, such as on PR-IF (which doesn't use GlkOte btw.) Is this feasible with mobile browsers? Should we just set a rule that on mobiles #gameport must be the whole screen?
  • I'm currently taking the height of an update starting from 20 pixels above the previous command. This could be reduced to the bottom of the command, in order for more updates to be shown with the virtual keyboard active, only those that truly don't fit would close the keyboard. Or is it more useful to show the previous command?
  • Allow pinch zooming, and handle it properly

A question from the development side: I haven't used web components before, and I'm wondering if the TextInput class would fit being made into one. Some code would probably have to be moved out of it, but that's okay. It uses jQuery now, but it wouldn't have to. I'm wondering how it would work... make a component be a subclass of an Input element, or hide the input element within it? Use callback functions like it does now, or raise a custom event with the normalised Glk data?
https://github.com/curiousdannii/asyncglk/blob/master/src/glkote/web/input.ts