Once again I am here because I have exhausted my research on the subject. I have a very simple setup with very simple markup and yet a very strange behavior.
The behavior is eerily similar to (Firefox and Angular: Textarea placeholder doesn't appear until first focus) but I am experiencing it in a different environment.
Consider the snippet with a readonly text area. This brings bad a list of comments, where 2-3 fit on the screen before having to scroll for some more already loaded comments.
<div class="row">
<div class="col-xs-2 text-right font-sm-dark"
style="height:20px; line-height:20px; font-weight:bold;">
<label>Comment:</label>
</div>
<div class="col-xs-10 text-left font-sm">
<div class="col-xs-12 text-left font-sm">
<textarea style="text-align:left; width:100%; padding:0,0; line-height:normal; resize:none;"
rows="5"
ng-model="comment.Text"
readonly></textarea>
</div>
</div>
</div>
This works great when running the application on the browser (chrome, safari, etc), but once I build the application using PhoneGap and run it on the ipad device I get the following behavior:
The comments visible already show fine in the textareas. When I scroll down do read more comments, their textareas are empty BUT if I tap the textarea then the text appears.
After scrolling, the Comment boxes are empty until "tapped" in iOS.
That is it, there is no complicated CSS related to this markup, and no weird server loading issues. When this area loads it brings all the comments with it.
I'd like to point out that this is a large mobile app with much more sophisticated markup/functionality that works fine on the browser and translates perfectly to both Android and iOS mobile apps.
The first link I posted upthere leads me to think that there is some weird bug in ng-touch handling textarea focus on mobile clients.
Any ideas? I'd hate to dump textareas for text inputs, but I am almost at that point.
This issue is triggered by the textarea element within a container using:
-webkit-overflow-scrolling: touch
in its parent container.
Removing the class solves the problem with the 'initially hidden text not loading' but losing desired inertia scrolling UX.
Adding
-webkit-transform: translateZ(0px)
to the style of my affected textarea elements solves my problem.
In my particular case I dont believe I will incur in prohibitive performance penalties since my hidden elements that I am yet to scroll to wouldnt be loading rich content (videos/animations/etc) that would tax the VRAM on the mobile device. I am basically taking advantage of the additional rendering context (hardware assisted) being triggered by this, which makes my text render normally, and thus bypassing an iOS BUG.
Great information on translateZ (and its close cousin translate3d(0,0,0)) http://aerotwist.com/blog/on-translate3d-and-layer-creation-hacks/
It seems that when using:
-webkit-overflow-scrolling: touch;
iOS places the form elements in an odd z-index
placement where it is visually hidden yet still clickable (knowing where the elements are: can type text, press buttons, etc). The hack-fix until iOS corrects this bug (which is present in both Safari and Chrome on iOS) is to explicitly set a lower z-index
on all elements with -webkit-overflow-scrolling: touch
set.
For example, if the page doesn't use z-index
at all then using:
z-index: -1;
-webkit-transform: translateZ(-1);
-webkit-overflow-scrolling: touch;
will correct the issue.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With