9 Apr 2013 6:09 AM #1
Unanswered: Android and iOS issues with scrollable form
I'm currently working on a big ST2 + Phonegap project for iOS and Android. So far everything (Scanner, CORS Ajax Requests, Geolocation) is working fine.
The only thing I can't seem to figure out are several issues with scrollable forms. The problems on iOS and Android are different and vary depending on the devices used.
This is my layout:
Bildschirmfoto 2013-04-09 um 15.33.33.png
Behaviour on iOS:
When a input field is focused, the whole viewport will be scrolled to the center of the screen, so the field will be fully visible while typing.
Problem 1: If you use the 'next' and 'back' buttons of the softkeyboard, it will jump to the next / previous input field. If you do so from the first field to the last field of the form following bug will appear. The scrollable container get's a lot of extra padding at the bottom, but it can't be scrolled to the very top. The whole scrollable container can be scrolled off the viewport until it's not visible anymore.
Problem 2: If you scroll the scrollable container whilst the softkeyboard is still visible, the cursor is stuck on the screen where the input field used to be at.
Behaviour on Android:
I turned off the default "Android webview field focus behaviour" by setting the windowSoftInputMode to 'adjustPan'. Then i implemented my own function which basically scrolls the focused field to the middle of the scrollable area. (This is shown in IMG 2)
Problem 1: The cursor and the 'text position indicator' are rendered at the position the input field used to be at before the scroll. (I fixed the position of the cursor but not the 'text position indicators' by waiting 50ms before scrolling the field and then focusing it again after another 50ms )
Problem 2: The content of the focused input field can be added if there is no cursor in the field, but it can't be deleted. You could delete the whole input but it'll still be visible in the field. If you focus the field again and start typing, the new input will appear before the old input.
Problem 3: If you focus a field and start scrolling, the rendered focused field won't scroll but is stuck on the screen where the input field used to be at before scrolling. (you can see this in IMG 3)
Bildschirmfoto 2013-04-09 um 15.26.42.png
Has anyone experienced these problems, and by any chance has come across a solution? Am I doing something essentially wrong? I've searched the internet for these problems, but I couldn't find any working fixes.
The common fixes i've found are:
- android: adjustPan instead of adjustresize
- android: use window.scrollToTop to fix gap when softkeyboard is hidden
Hope anyone can help?!
11 Apr 2013 5:11 AM #2
- Join Date
- Mar 2007
- Gainesville, FL
- Vote Rating
Mitchell Simoens @LikelyMitch
Sencha Inc, Senior Software Engineer
Check out my GitHub, lots of nice things for Ext JS 4 and Sencha Touch 2
Think my support is good? Get more personalized support via a support subscription. https://www.sencha.com/store/
Need more help with your app? Hire Sencha Services firstname.lastname@example.org
Want to learn Sencha Touch 2? Check out Sencha Touch in Action that is in print!
When posting code, please use BBCode's CODE tags.
18 Jun 2013 11:21 AM #3
Has there been any movement on this?
To me, it sounds like it's related to the TOUCH-2704 bug (http://www.sencha.com/forum/showthre...081#post975081) as opposed to the TOUCH-3178 bug (http://www.sencha.com/forum/showthread.php?233093)
Either way, has anyone managed to come up with a workable solution?
6 May 2014 2:38 AM #4
I have form which on filling it using tab key(on desktop) and next key on ipad, i am experiencing an extra padding which gets added to container as said by a.kuelzer . I am using sencha latest released version 2.3.1 if any help related to this will be valuable..
13 Dec 2014 1:54 PM #5
Same problem here with touch 241, android 5
15 Dec 2014 12:20 AM #6
Not sure if it can be useful to someone, but I've found a dirty workaround to reset view once soft keyboard has been hidden on Android.
This is not fully tested but at least it's something.
I found out that if I toggle (removeCls and addCls) the "x-scroll-view" css class on "scroller.getElement().getParent().getParent()" the additional bottom padding goes away.
I toggle css class at scroller's scroll event when I get that:
scrollerY===0 and fieldset.element.dom.getBoundingClientRect().top < myCustomLimit