Notice: The Monaca & Onsen UI Community Forum is shutting down.
For Onsen UI bug reports, feature requests and questions, please use the Onsen UI GitHub issues page. For help with Monaca, please contact Monaca Support Team.
Thank you to all our community for your contributions to the forum. We look forward to hearing from you in the new communication channels.
Displaying keyboard causes ons-template to scroll up and collide with status bar on iOS
-
Hi there,
I’m using Onsen UI in a Cordova project and I’m experiencing an issue where tapping into a form control and thus activating the onscreen keyboard causes the entire ons-template (or perhaps ons-navigator, not sure) to scroll upward to accommodate the keyboard. If I scroll the page (above the keyboard) I’m able to scroll it entirely off screen.
I think the most jarring part of this is that the ons-toolbar scrolls with it., so you can actually get the entire screen to be almost completely white as the page is very short.
Any way to keep the ons-toolbar fixed at the top of the page and limit the scrolling when a keyboard is shown?
Thank you for any assistance you can provide. Much appreciated.
-
Hmm. Unfortunately I think detecting the keyboard state in iOS is something which is not trivial. The reason why the issue appears in the first place is actually due to the fact that iOS does not actually show any change in the viewport sizes, so from our perspective it is really hard to account for that as we have no simple way of knowing when it becomes activated, as well as how much actually has changed.
Here are the things I can come up with:
-
Add an event listener for when an input becomes focused in/out and add some class to the navigator which you can style accordingly. This approach has several potential flaws however.
First you should make sure that if a user moves from one field to another you don’t get blinking due to a temporary removal of your class.
Also the styles may not be trivial and may contain other side effects. If you know the size of the remaining screen / the keyboard it’s doable, otherwise it becomes hard/not recommended.
-
You could try something like
ons-toolbar { position: fixed !important; }
We are currently using absolute positioning to avoid iOS’ buggy implementation of fixed positioning, but I think in this specific case it shouldn’t be a problem since our DOM should prevent it from bugging out. However I’m not completely sure whether this will help when the keyboard is activated.
For the size of the page you could try something like
.page__content { height: auto !important; max-height: 100%; }
However that may break something during the page transitions.
This is what I can currently think of. I would suggest trying out only the first part of solution 2 and maybe go for solution 1 only if you are able to know the new viewport dimensions. Maybe the keyboard size is some constant value like 50% or 40%, but I’m not sure.
-
-
@IliaSky Thanks for your feedback. I’ll give the first line of #2 a shot. Seems like it might get me where I need to be.
What should I be on the lookout for regarding fixed positioning freaking out on iOS?
Thank you!
-
@Steven-Sokulski In this case you should not worry.
In other cases the problem is as follows:
If an element has
position: fixed
and it’s parent is scrolled with a momentum scroll (a single swipe up/down instead of a drag) - then instead of retaining its position on the screen it would scroll together with the other content and then returns to its proper position only after the scroll finishes.In the suggested case the element which is scrolled is
.page__content
which is a sibling ofons-toolbar
instead of a parent so the problem should not occur.
-
This is still an issue which I reported on on https://github.com/OnsenUI/OnsenUI/issues, however, there is no reaction so far!!!
Anyone has a solution?
-
Does someone has any suggestion?
I read how you should include different type of keyboard but that is not a solution.