Hi @Satheesh,
Since you have a fairly current project which exhibits it, can you put this into an official bug report and list the device(s) that you know it’s occurring on? This is the fastest way to bring it to the attention of the engineers.
http://developer.coronalabs.com/content/bug-submission
Thanks for your help and patience,
Brent
I’m doing a slightly different version of the native.text shuffle, maybe it’s not a big adaptation for someone.
I’m using display.newRoundedRect() for the background of display.newText() fields onscreen (like it sounds most people are), and when the user taps one of the rects, I call my native.field editing routine – passing in the rect object that was tapped. The edit routines create a new native field of the same size and dimensions as the passed in rectangle, perfectly covering the area. (the editor is called after fields have been slid up to make room for the keyboard. Once the edit routine is done of course, it deletes the native field and passes back the result.
Just thought I’d throw that out there in case someone has nice rectangle fields already in place they can shift their offscreen field onto just to get past the issue asap.
Any updates on this issue? @Tom, @Brent, and @Rob, I really appreciate that you guys have bumped up the priority on this. It’s really great to see Corona staff actively on the forums and giving attention to issues and bug requests! Keep up the good work guys!
@Brent
Ok I just submitted a bug report.
Case 24464
@mpappas
That would work, but the problem is different Android devices have difference text fields, and there is the chance that some textfields may screw up the UI. But I guess I’d do that as a last resort.
Everyone,
This bug is now fixed. The fix will be made available in daily build #1162.
Satheesh,
Thank you for taking the time to submit a bug report. That got this issue on engineering’s radar and expedited the matter.
I’d like to throw my hat in the ring here. I’ve had a detailed bug report filed for this issue (Case 23692) since May 24th. I haven’t heard anything back on it yet. This issue is currently a show-stopper for me (I’m ready to publish now). It affects Android devices (I’m testing on a Droid X running 2.3.4), but not iOS devices. I was previously using .971 and everything worked fine. When I switched to .1076 I noticed the bug. I just updated to .1137 and it’s still there. I’m using fake text fields with off-screen native text fields out of necessity, since native text fields vary so greatly between devices/operating systems. I appreciate you guys taking a look at this.
I second @drewns on the urgency on this
Although it seems like a minor annoyance, it really is a major frustration.
@Brent
I saw in http://bugs.anscamobile.com that you guys had classified it as “Important”, below “Critical-significant impact” and “Showstopper”. Does that mean it is not high priority? Can you give a timeframe, so that we can do some workaround, if it seems the fix would take awhile? (although will really appreciate it if you guys fix it ASAP)
Can you humor me and try it by leaving it on screen (even if just partially, so the event handler works) but set it’s .isVisible flag to false?
@Rob I remember trying it sometime back. Invisible textfields never received keyboard focus
Still, I tried again with build 1150 now… Nope. no luck.
Then I tried by setting alpha of the textfield to 0.
Now a weird thing happens. The keyboard appears and focus is seemingly set to the textfield. But the textfield becomes visible. After it loses focus, it is hidden again.
EDIT:
Also, when the alpha is set to 0, the textfield responds to user touch…
Yea, I tried it to. I’ll ping the engineers on it but it’s getting to be late on a Friday.
@Rob I had very similar results to @Satheesh. isVisible acts the same as having the text fields off of the screen (even though I had them fully on the screen–nothing hanging off the edges). Setting the alpha to 0 works on the device, but the native text field responds to touch even though it’s invisible. Unlike @Satheesh I didn’t see the native text box on the device when I was using my fake text fields, though I did see the native cursor pointer when I touched the native text field directly.
Hi all,
I discussed this with the engineers this morning (Monday 7/1). They will investigate if some of these issues ever worked (in older builds) or if it’s some kind of issue with recent builds. It appears to be an Android-only issue, but working fine on iOS. In any case, the bug priority has been pushed up in importance.
Thanks for your patience,
Brent Sorrentino
We determined that this has been broken for a couple public release builds (1076 and 1137). Build 1051 works and build 1053 breaks off-screen textfields. This is when we fixed an issue with native textfields not transitioning off screen correctly. We are looking into a fix for this issue.
Lol! downloading 1164 now! 
Thanks again for this fix! I’m currently using starter, so I don’t have access to daily builds. Any idea when the next public release will drop?
We haven’t set a release date yet.
Come to think of it, I think you might be able to work-around this issue by setting “textField.isVisible = true” and setting the keyboard focus on it by using a timer right after you move the field offscreen. This might fool the code into making it visible and editable again. I haven’t tried it for myself, but it might be worth a shot.
Hey, that worked! In my case the native text fields are off screen from the moment they are created (the X and Y parameters are populated when I call native.newTextField). The only text fields the user ever sees are my fake fields. The fake fields have touch listeners that give focus to the corresponding native text field and make what is typed in the native field appear in the fake field. If I set “.isVisible = true” on the native text field right before calling “native.setKeyboardFocus( txtField )” everything works as normal.
What’s weird is I thought I had experimented with using .isVisible before, but apparently hadn’t tried setting it to “true” right before setting focus. In any case, it’s working now. You rock! Thanks again!
Happy to help! I’m glad it worked!
Yeah, when we fixed this issue, we noticed that this bug was caused by our “culling” routines in our rendering code where it would hide and not attempt to render objects that were offscreen. While this makes sense for OpenGL rendered objects (it can provide a huge performance boost), it doesn’t make sense to do this for native objects such as text fields, web views, etc. I saw a “flaw” in our culling of native objects which you’re now taking advantage of 
. The newest daily build fixes this issue by disabling culling of native fields, which is really the operating system’s job and shouldn’t be done by Corona.
Just to be clear. Is the right method to have textField on screen and isVisible = false now?
That seems to work for me (but have not tried on devices yet). I tried off screen and its not working in simulator (build 1168).
>> Just to be clear. Is the right method to have textField on screen and isVisible = false now?
That’s the work-around for those who do not have access to daily builds. The newest daily build fixes this issue on Android. I didn’t realize this was an issue on the Corona Simulator for Mac as well. That’s the first I’ve heard this mentioned.