Android: various problems while typing in forms

[claudiobosticco]

SmartClient Version: SNAPSHOT_v11.1d_2017-05-14/AllModules Development Only (built 2017-05-14)

Chrome on Android Nougat 7.1.2 - Nexus 5x (real device)

Hello, please try the #maskedTextItem sample.
While typing in the "Phone No." form item you'll see that the cursor will go back after the first 4 digits. In the "Date" form item, same effect after the first 3 digits.

Other problems:
1. if you add characterCasing:"upper" to the "firstName" form item, the characters doesn't become uppercase while typing.
2. if you remove the mask from the "firstName" item, and also add characterCasing:"upper", then the uppercase is enforced, but if you type fast, many characters will be lost.

[Isomorphic]

Just a note that this is assigned and will be looked into shortly - we'll update here when we have more information.

[Isomorphic]

We aren't seeing any of these issues in testing against latest 11.1, using Tahoe.

We're not sure what you mean by "the cursor will go back", but we don't see any bad behaviors when typing into the Phone and Date fields, however many characters, and however quickly they're typed.

As doc'd, TextItem.characterCasing is ineffective in the presence of a mask, so your point 1) is expected behavior - if we simply comment the mask out and add set characterCasing, that seems to work as expected, with no lost characters. Also, if we change the mask to just be <??? etc, all chars are upper case and none are lost.

Perhaps you can retest with the latest build, and show a video if it still fails for you?

[claudiobosticco]

SmartClient Version: v11.1p_2017-07-03/AllModules Development Only (built 2017-07-03)

Chrome on Android Nougat 7.1.2 - Nexus 5x (real device)

Hello, please try the #maskedTextItem sample.
While typing in the "Phone No." form item you'll see that the cursor will go back after the first 4 digits. In the "Date" form item, same effect after the first 3 digits.

Hello, sorry for the late reply.
Please see this video illustrating the above issues:
https://www.youtube.com/watch?v=viR1RUViLAA

[Isomorphic]

Can you clarify whether you see this on any other devices? In particular, ones that are not running Nougat 7.1.2...

We've successfully tested hitting the online sample [URL="www.smartclient.com/smartclient/showcase/?id=maskedTextItem"]here[URL] from a couple of emulated Nexus 5Xs running Nougat 7.1.0 and 7.1.1 - those work as expected - Android Studio provides no 7.1.2 ADV, so we haven't yet been able to directly test that Nougat build.

[claudiobosticco]

Yes, I see this also on a Nexus 5 running Android 6.0.1

[claudiobosticco]

Hello, did you succeed in replicating the issue?

[Isomorphic]

Apologies for the delay on this one - yes, it's been reproduced on a real device, but it hasn't been fixed as yet - we'll get to it shortly.

[Isomorphic]

Apologies for the further delay on this one - we've fixed a number of bugs in our selection-range logic for value masking and character-casing in the last week or so.

Can you retest with today's build on your Nexus devices and let us know if you see any improvement?

[claudiobosticco]

SmartClient Version: v11.1p_2017-08-02/AllModules Development Only (built 2017-08-02)
and
SmartClient Version: SNAPSHOT_v12.0d_2017-08-02/AllModules Development Only (built 2017-08-02)

Chrome on Nexus 5 running Android 6.0.1

Hello, I've just retested the #maskedTextItem sample, and only the problem with the 'Phone no.' form item is still present, as in the video from post #4.

[Isomorphic]

Thanks for the feedback - we'll sort this out tomorrow.

[Isomorphic]

Ok, after yet another delay, we do now have some feedback on this one.

It turns out to be a severe native bug with that particular handset, the Nexus 5X - it doesn't fire native key-press events for standard character keys, so our EH._handleNativeKeyPress() never fires on this device.

We do have existing mechanisms for synthesizing such events for some browser/key combinations - but these don't work out of the box, in this case, due to what is apparently a longstanding bug on mobile Chromium wherein the keyCode passed to the native onkeydown EH handler is invalid: see this thread (via this one).

This may take some time to resolve - so, for production apps, you may want to turn off masking on Android devices for now.