iOS: Native Text Field Incorrectly Inserting Characters If Cursor Is Moved

Solar2D Daily Builds and Public Releases
#1

Hello,

I’m experiencing an issue with native text fields on iOS (both on device and in the xcode simulator)

When a user manually adjusts the cursor position in an input field and continues to input text via the keyboard, the last character inserted is being appended to the end of the .text value string. If they continue to type, the characters move to their correct position, all except for the last inserted character.

The native text field displays what is typed correctly, it is only the text field’s .text value that is incorrect.

Here’s a video of the bug in action:

http://cl.ly/1o0d2l0m2u0d

This is still happening using daily build 2013.1260

I’ve submitted a bug report, just wondering if anyone can think of a work around.

We’re trying to launch our app this week, and while I don’t expect this to get resolved before then, it would be really cool.

I’ve attached sample code for replicating the issue, but it happens with the SampleCode/Interface/NativeKeyboard field sample code as well.

#2

Hi Jake,

I’ve tested and confirmed this behavior. Thank you for submitting the bug report and code example. We’ll look into it.

Thanks,

Brent

#3

Awesome, glad to know it’s not just me. :slight_smile:

#4

Hi, we have this bug too, as well as some facebook issues - 1260.

Can someone confirm that you will continue to fix regression bugs in the legacy builds? There will be a 1261 that fixes Facebook login and the text input thingy, no?

#5

See David’s response to same question on another thread…http://forums.coronalabs.com/topic/41391-which-download-updated-api-docs/#entry215295In a nutshell, we either go G2 or get nothing fixed. If we go G2 then we get more and new bugs which we must help CL identify and fix… Oh and we keep paying for the privilege. Life is not good.

#6

I can confirm this as well, it’s been a pretty big annoyance for my users to have to enter their text multiple times. Especially since my app is largely text-based.

Any updates on this?

#7

It’d be really nice to not have to port our app to G2 just to resolve this issue.

#8

Agreed! I tried doing a workaround in the mean time - using the event listener - but couldn’t come up with a viable fix.

#9

Hi @apps638,

This has been fixed in a recent G2.0 build (I can look up which build number if necessary). We will also look into getting that into a 1.0-based build if possible.

@mail1347, just as a side note, myself and several other developers have found that converting to G2.0 is easier that expected, even without relying on V1 Compatibility Mode (which should make it even easier). Last night, I ported 90% of a fairly complex app over to 2.0 functionality within about 4 hours, and I could cut that time in half now that I’m familiar with the process. The migration guide can help toward this goal, if you wish to do so.

http://docs.coronalabs.com/guide/graphics/migration.html

Best regards,

Brent

#10

Hi Jake,

I’ve tested and confirmed this behavior. Thank you for submitting the bug report and code example. We’ll look into it.

Thanks,

Brent

#11

Awesome, glad to know it’s not just me. :slight_smile:

#12

Hi, we have this bug too, as well as some facebook issues - 1260.

Can someone confirm that you will continue to fix regression bugs in the legacy builds? There will be a 1261 that fixes Facebook login and the text input thingy, no?

#13

See David’s response to same question on another thread…http://forums.coronalabs.com/topic/41391-which-download-updated-api-docs/#entry215295In a nutshell, we either go G2 or get nothing fixed. If we go G2 then we get more and new bugs which we must help CL identify and fix… Oh and we keep paying for the privilege. Life is not good.

#14

I can confirm this as well, it’s been a pretty big annoyance for my users to have to enter their text multiple times. Especially since my app is largely text-based.

Any updates on this?

#15

It’d be really nice to not have to port our app to G2 just to resolve this issue.

#16

Agreed! I tried doing a workaround in the mean time - using the event listener - but couldn’t come up with a viable fix.

#17

Hi @apps638,

This has been fixed in a recent G2.0 build (I can look up which build number if necessary). We will also look into getting that into a 1.0-based build if possible.

@mail1347, just as a side note, myself and several other developers have found that converting to G2.0 is easier that expected, even without relying on V1 Compatibility Mode (which should make it even easier). Last night, I ported 90% of a fairly complex app over to 2.0 functionality within about 4 hours, and I could cut that time in half now that I’m familiar with the process. The migration guide can help toward this goal, if you wish to do so.

http://docs.coronalabs.com/guide/graphics/migration.html

Best regards,

Brent

#18

converting to G2.0 is easier that expected

Sorry, Brent, but I disagree. If there are third-party libraries with buggy unsupported code it can be a nightmare. We have one project that uses LoqSprite (now 2 weeks into upgrading) and another one that uses Lime (even more horrendous, we canceled doing the upgrade). Not only is upgrading painful, I now have to maintain a virtual PC with an old Corona version just to maintain the Lime-based project, while working on the other.

I’ve never seen a framework by any vendor (Android, iOS, Java, .NET, Unity, XNA, OpenGL, DirectX to name a few I’ve used) that actually breaks existing APIs. Quite the opposite, they drag the same old legacy functions for decades. And now you simply decide to break every single Corona project that has been written? Nice going, guys

Edit: OK, I lied. Apple broke our builds with iOS 7 recently. And now Corona does the same. Prepare to be sued for patent infrindgement :stuck_out_tongue:

#19

converting to G2.0 is easier that expected

Sorry, Brent, but I disagree. If there are third-party libraries with buggy unsupported code it can be a nightmare. We have one project that uses LoqSprite (now 2 weeks into upgrading) and another one that uses Lime (even more horrendous, we canceled doing the upgrade). Not only is upgrading painful, I now have to maintain a virtual PC with an old Corona version just to maintain the Lime-based project, while working on the other.

I’ve never seen a framework by any vendor (Android, iOS, Java, .NET, Unity, XNA, OpenGL, DirectX to name a few I’ve used) that actually breaks existing APIs. Quite the opposite, they drag the same old legacy functions for decades. And now you simply decide to break every single Corona project that has been written? Nice going, guys

Edit: OK, I lied. Apple broke our builds with iOS 7 recently. And now Corona does the same. Prepare to be sued for patent infrindgement :stuck_out_tongue:

#20

This problem is bad. In build 1259, not only does it update the end of the text instead of the middle, but it also considers a select/cut action to be the deletion of the last character of the text. User selects and cuts characters 3-8 of the text, and character 12 disappears instead.

It also seems like autocomplete doesn’t work anymore.

As far as migration to G2 being “easy”, I use a lot of widgets. Widgets have their centers as origin in G2 instead of top left. Center origin causes fuzzy text, as we know from many other posts/discussions (fractional x/y values cause fuzziness due to aliasing, and the solution is to use non-center origins to avoid fractional x/y values for left and right edges of text objects).

So, I don’t see G2 as an easy solution. I see retrofitting the G2 fix for a bad bug into a Corona G1 build as an easy solution, or a having the compatibility mode include all the G2 fixes and not have widget incompatibilities as an easy solution.