search

keymanapp / keymanweb.com

https://keymanweb.com/ source
2 stars 2 forks source link

bug: KeymanWeb 17.0.193-alpha does not function in the Chrome browser when accessed via a mobile device #86

Closed bharanidharanj closed 8 months ago

bharanidharanj commented 8 months ago

Here is what I did:

  1. Opened Chrome browser on a Mobile.
  2. Opened 'keyman.com' site.
  3. Clicked 'Pre-release versions' under Downloads.
  4. Clicked 'KeymanWeb latest alpha on keymanweb.com' link under 'KeymanWeb'.
  5. Clicked the 'Text Area' pane.

Here, I observed that there was no activity in the text area, and a keyboard did not appear on the screen.

I have attached the Screenshot for reference.

jahorton commented 8 months ago

Interesting. This issue does not appear when using Chrome remote-device emulation from a desktop device... or at least, "not on my machine". Guess I should spin up Android Studio and see if that makes a difference, seeing how the reported error above was taken from its emulator.

image

... there is a small chance that the fact I had a keyboard automatically specified could have made the difference, but I'd like to check the Android Studio path first.

jahorton commented 8 months ago

Yep, it's happening in Android Studio, but not plain Chrome remote-device emulation... unless I edit the URL to have a cookie pointing at a previously-set keyboard. At that point, it's happy again.

I can emulate the issue in desktop remote-device emulation if I nuke all cookies and clear the cache. (To be explicit: I had to do a full clear on the cookies to do so.)

The crux of the issue: there's no keyboard set as active when KeymanWeb is being loaded in this circumstance.

jahorton commented 8 months ago

... right, because keymanweb.com uses a cached set of keyboards, bypassing the standard addKeyboards API - as noted during https://github.com/keymanapp/keyman/pull/9304.

Default keyboard selection is handled through Promises on the addKeyboards API in 17.0, so the same underlying issue also causes this one.

Meanwhile, if there's an existing cookie, that has a built-in mechanism to trigger load of the previously-loaded keyboard - hence why I didn't see the issue at first; I had such a cookie.