search

keymanapp / keyman

Keyman cross platform input methods system running on Android, iOS, Linux, macOS, Windows and mobile and desktop web
https://keyman.com/
Other
398 stars 111 forks source link

bug(ios): iPad Initial"nextlayer" Change Fails #9189

Open dyacob opened 1 year ago

dyacob commented 1 year ago

Describe the bug

Using a touch keyboard on an iPad where "Default" key types use a nextlayer attribute, the very first time a key is hit, the layer change fails and the keyboard remains on the default layer. Any following nextlayer change will be successful.

I do note that the keyboard appears to flicker, possible the nextlayer change happens for a moment and the keyboard switches back to the default layer.

I have not tested this on an iPhone recently, the issue may also be present there. I'll report back if I experience the issue there also.

Reproduce the bug

  1. Launch the Keyman App
  2. Select an installed GFF keyboard, we can use gff_tigre as an example. But any GFF touch keyboard where the letters left and right of the spacebar will appear to update dynamically.
  3. Note that the letters left of the spacebar are አ, ኡ, ኢ and on the right side are ኣ, ኤ, and ኦ.
  4. Touch the ል key (positioned where "H" would be on a QWERTY keyboard).
  5. ል will appear onscreen as expected, but note that the letters to the side of the spacebar remain unchanged (the screen may appear to flash).
  6. Touch the ል key, the keys will now update to offer: ለ, ሉ, ሊ,ላ,ሌ, andሎ`.

After the first strike of ል any other key can be hit and the modifier keys (left-right of spacebar) will update.

Expected behavior

The initial layer change should be successful.

Related issues

No response

Keyman apps

Keyman version

16.0.139

Operating system

iPadOS 16.2 (20C65)

Device

iPad (5th geneartion)

Target application

Keyman App, any editor

Browser

No response

Keyboard name

gff_tigre (any other multilayer gff keyboard)

Keyboard version

1.0

Language name

Tigre

Additional context

No response

mcdurdin commented 1 year ago

@jahorton can you repro?

jahorton commented 1 year ago

I'm not getting a repro on my iPhone... though of course, this is reported on an iPad.

jahorton commented 1 year ago

Update: it also doesn't happen on an iPad in Simulator... with iOS 15.5. I've kept my phone on a similar version. Perhaps this is iOS 16 related somehow?

Also, a question: does this happen only if the affected keyboard is the first keyboard activated when using Keyman keyboards, or does it also happen after swapping keyboards?

jahorton commented 1 year ago

Managed to get a Simulator instance operable for 16.2... I'm not getting a repro with it, either. Not even if I uninstall all other keyboards and force-quit the app before trying.

dyacob commented 1 year ago

@jahorton thanks for looking into it. To answer your question, it does happen after swapping keyboards. It's completely repeatable in that respect.

Is there a debug mode that I could turn on with Keyman or my iPad to help trace what is going on? I could make a screen recording also if that helps in some way.

jahorton commented 1 year ago

I just double-checked our recent error reports; I'm not seeing anything that would be clearly correlated. I was hoping we could get something that way, but oh well.

I don't think it would work with the release version of the Keyman app, but it is possible to debug the keyboard via connecting the device to macOS and using macOS Safari developer mode (at least, during development) using a debug build... once certain steps are followed. It's not the most trivial setup, unfortunately.

One other thing that may be helpful - could you see if this continues to occur with our latest nightly (alpha) builds? There's been some restructuring under the hood since 16.0, so there's a shot that the behavior might be a bit different between versions - and that could help give insights as to the cause.

mcdurdin commented 1 year ago

Other ideas:

jahorton commented 1 year ago

Marking this an iOS bug for now, though we haven't been able to fully eliminate the possibility of this being a bug in the embedded Web engine.

jahorton commented 9 months ago

Testing this with the latest Keyman 17.0-alpha build, I'm not seeing a reproduction of this issue. The layer changes on my first tap of the key in the h position as per step 4 listed above. Downgrading to 16.0.144-stable, same behavior.

This is from an iPhone SE 2 running iOS 16.6.

It's probably too far back to remember at this point, but did you observe this happening upon first load of the keyboard or Keyman app, or was it generally after you'd "backgrounded" it and then restored it to the foreground? If it's the latter, this might be related to https://github.com/keymanapp/keyman/issues/6542.