Prevent IOS autofocus first input when page opens

There is a page in our app that has a single input field. When going to that state on IOS, the keyboard automatically pops up. This is not what is desired. This doesn’t happen on the Android version.

I’ve tried all sorts of things, but nothing is sorting it. My last attempt was to call $cordovaKeyboard.close() in the app.js run block within a $stateChangeSuccess handler. Alas, nothing.

Any pointers would be greatly appreciated!

Could you show us some code (markup / js) ?

Is the focus actually going to that field? I had an issue where there were no input fields and the keyboard was still popping up on iOS when the page loaded. I had to add a listener to make sure the keyboard was dismissed if the active node wasn’t an input, select or text area. Even if it’s correctly getting focus you could probably do something similar and use a little logic to dismiss it on initial loading.

Cheers for the prompt responses :smile:

There’s not much to put in code terms. The offending input:

<ion-item class="item-input-inset">
  <label class="item-input-wrapper bg-light-grey-30 text-center">
    <input type="text" class="text-center tracker" ng-model="values.exploreSearch" placeholder="Enter city, street, username or keyword"/>

And the JS in the app run block:

$rootScope.$on('$stateChangeSuccess', function (event, toState, toParams, fromState, fromParams, error) {
  if (window.cordova && $cordovaKeyboard.isVisible) {

I previously tried putting a block in the page controller that looked like this:

$ionicPlatform.ready(function () {
    if (window.cordova && $cordovaKeyboard.isVisible) {

Which, according to my client (as I don’t have an IOS device to test on), worked the first time the page loaded, but not subsequently. If you left the page, and came back, the keyboard would pop up.

I have had a development. It turns out the reason the keyboard is opening is because the ui-sref link that the user clicks to get to the state (where the keyboard popped up) is in the same position on the screen as the input in the new state. The touch event seems to be carried over to the new state, and registers again causing the input to get focus, thus bringing up the keyboard.

So, the question is now, why is the tap event carried across the state change in IOS?

I may have to make this in to a new post as this is a different thing to my diagnosis in the original post.

1 Like

Hi Jim,

i think I have the very same pb. The back button triggers the focus in the search input in the back view so the keyboard opens.
Did you find a way to prevent the propagation?

I’m afraid not. In the end our client changed their design which moved the search field to a different area of the screen such that the tap didn’t happen on it when routing through to the page. Obviously, one can’t go back to the client to ask them to change their design over something like this, but our client changed the design seemingly every week.

Your problem sounds a little different. For us it was the fact that the ui-sref link that was tapped was on the same part of the screen as the search field in the new state that opened, and the tap carried over. Sounds more like yours is something else I’ve read about, whereby focus is given to the first input field when the state opens, and because of this IOS automatically triggers the keyboard to open. Unfortunatley I’m not sure how to get around this.

For our problem, I tried using ionic.keyboard to trigger a close event after the state resolved, but this didn’t work.

Sorry I couldn’t be of more help!

1 Like

thanks a lot for your quick answer
I’ll continue to investigate. Cheers

I’m experiencing this issue where the click is carried over to an element animated into the original button position (via css). I’d appreciate any information if you found a solution (2 years later).

I’m afraid not. The client changed their designs and repositioned the offending element. I’d imagine ionic has come along way in the last two years, and I haven’t used it since, so can’t be of much help.

I’d solved this problem at this documents.

and maybe this blog help you.

1 Like

Thanks @byeonghun. Yeah, I do recall tackling the 300ms thing, somewhere in the dim mists of time…

1 Like