Skip to content
This repository

Text fields on iOS fail to receive typed characters on first try -- detectResolutionBreakpoints() bug #756

briangershon opened this Issue January 03, 2011 · 36 comments
Brian Gershon

This bug renders first field of a form (on iPhone) unusable, until the they click on another field, and come back.

Details of this JS-related bug here:

When we first saw this problem, we were able to reproduce when we hit a certain number of fields or form DOM elements. e.g. 2 fields didn't show problem, but as we added fields/dom-elements, the problem appeared.

We traced through various scenarios such as focus-related code, simplifying our DOM, etc.

This problem appeared post Alpha 1.

I also filed an earlier bug that caused similar problem (though may ultimately have just been related to this detectResolutionBreakpoints() bug) which was CSS-related:

Todd Parker

I just tested this in on an iPhone 4 and I'm not seeing any issues on our test pages. I can focus into any text input on the first tap:

We have a critical issue the prevents you from dismissing a typo suggestion in iOS but other than that, all seems good. Can you confirm?

Alex Veenendaal

i've encountered this issue with 1.03 on an iphone 3gs (both actual and emulator).

This gist contains a snippet which produces the problem for me.

As noted elsewhere, introducing a field before the search removes the problem - uncommenting line 14 in this case.

Todd Parker

Thanks for the details, flagging this as critical.

Brian Gershon

I just confirmed that alpha3 is still exhibiting this behavior on our project.

Commenting out call to detectResolutionBreakpoints() was our only consistent fix for iPhone 3GS (and even some versions of 4G and recent iPod Touches).

Code snippet mentioned here by keri.k:

Brian Gershon

Problem always seems to be first field with initial focus. If form loads, then initially click on 2nd text field (which always works), then click back on 1st, the typing works fine.

We tried various focus/blur combinations as workarounds (prior to finding culprit) but to no avail.

Joel Westerberg

fwiw, adding a submit button to @odogono's gist makes input work (at least in iphone emulator). I've had this problem intermittently but managed to work past it by changing either form tag or submit button or adding labels (not sure). Adding an input field made it work in this case anyway.

Scott Jehl

I can't reproduce this problem in our demos on the devices mentioned. It sounds like it has to do with the markup in your app. Missing labels could perhaps be involved...?

Closing as can't reproduce, but please feel free to fill in more details and if you can reproduce this in our demo pages, or can find the culprit that caused the issue in your code, that'd be particularly valuable information.


Scott Jehl scottjehl closed this March 27, 2011
Alex Veenendaal

re-tested using this gist - issue remains. Also tested using latest js/css from repo (*).

  • load page in iphone simulator or device

  • tap on field. keyboard comes up. key taps do not cause characters to appear in textfield.

  • edit page to uncomment hidden input field

  • reload, tap on field, keyboard comes up, key taps cause characters to appear in textfield.

Todd Parker

odogono - I just pasted your gist into JSBin and tested it on my iPhone running iOS 4.3 and had no issues at all, with out without the hidden field commented out.

commented out:

not commented out:

What version of iOS are you seeing this on? Note that the framework (and the web) gets cranky when you don't have a label properly associated with the input. Even if you want to hide the input offscreen for visual users, it should have a label for semantics and accessibility.


I can reproduce this bug currently in alpha 4 using odogno's code. Here's the weird thing: If I use the jsbin link that toddparker posted, it works fine and I cannot duplicate the behavior. I can see in the view source that jsbin adds some additional content; maybe that has something to do with it.

Anyway, I took odogno's code and put it in my Google Apps area:

If I navigate to it on my iPhone 4 (4.2.1) and click the input box, most times the characters I type will not appear. If they do, refresh the page and most often it will bug out again. Here is a video of the behavior:
The eagle-eyed may notice that I'm using Atomic Browser in the video, but Safari yields the same results. Also this happens identically on my iPad (4.2.1).

I'm seeing this behavior in my actual web app and the only way I've been able to get around it is to hack out the call to detectResolutionBreakpoints() in jquery mobile as detailed in this thread (my post is at the end):

Todd Parker

Well at least we're seeing consistent results: I just tested the link on your server and I can see the issue. However, if I copy and paste the same code and paste into JSBin, it works fine on my iPhone 4 (4.3). So odd.

Your code on JSBin:

JSBin does add some cruft to the page if you view the rendered source so it's not 100% clean but it still works, unlike the page on your server.

We'll re-open and try to figure out what's going on now that it's reproducable.

Todd Parker toddparker reopened this April 03, 2011

This also happens when I use jqm with jquery validate. when i submit the form without filling in any fields and the first field is an input text field you can't enter any text into the field even though it's focused. if you click off the field and click back you can enter text

I'm using an iphone 4 with the latest firmware


Hey, this is my first contribution to jQuery nor jQueryMobile, so forgive any mistake.

Im having trouble with this too and spent lot of time trying to fix.

This might seem really bizarre, but the code bellow fix the problem decisively.

 $('input').one('keypress',function(ev) { $('<div></div>').appendTo('body') });

That must be called on "pageshow" event.

I hope this may help you find the truth about this bug.



We had this problem consistently in our app, especially when the app was first loaded, and not from cache. It was hard to reproduce if you had "recently" loaded the app, even if you navigated away from the page and back, and it was hard to repro in simpler testcases.

So my best guess is that it is an iOS bug that is provoked by jQM's effort to focus the first text input. Folks who have tried it will know that setting text input focus from script (or even from the autofocus HTML5 attr) is not allowed in iOS to start with. We looked at the jQM code and decided that the best workaround was to put a different element on the page to reFocus() on when the page is shown, because it only tries to focus on a form element if there is no .ui-title to focus on. So we just added the ui-title class to an element in the header, and voila, no more problem.

Todd Parker

Interesting. We're looking into re-thinking how/if we programmatically handle focus on pages because it's been causing issues in other places. We're doing this for accessibility and keyboard navigation reasons but there might be other ways to achieve the same goals.


I've noticed a similar issue (on my iPod Touch) where if you select an item from a select menu, click "Done", and then immediately go to a text input field, you cannot enter text into this field. You have to get focus elsewhere and then come back to the text field. I can replicate this on your test site on the Form Element Gallery page.


I had this issue and it was css related for me:

  • {
    -webkit-touch-callout: none;
    -webkit-tap-highlight-color: rgba(0,0,0,0);
    -webkit-user-select: none;



Having this issue with the beta. Working my way through the workarounds, but no luck so far. The issue is on ASP:TextBox's on an Ipod touch we're using to develop our webapp.

EDIT: Has there been any updates on this? Is a revamp or fix planned for Version 1 or do I need to continue to look for a consistent workaround?


Can you please provide any update on this issue. I am working on jQuery Mobile 1.0b3 and notice this issue on iOS4 but not on iOS 5. Is it fixed in the new release candidate builds? It seems to be very critical and on the most popular platform. Or is this issue only triggered in certain scenarios?

Todd Parker

Is there a really crisp test page where is is consistently reproducible? Looking through the thread, I'm not seeing a test page and reliable steps to reproduce so I think that's the holdup.


Try this: (taken from a post above) If that does not help (I did not test it using this sample though), I can try to make up something later by tomorrow.


Also, see the comment by scytalezero . He/she even has a youtube video

Todd Parker

Here is that gist in a jsbin for testing. I updated the head to point to 1.6.4 and the latest jQuery Mobile CSS and JS:

Todd Parker

I just tested the jsbin above on my iPhone 4 running iOS5 and another running iOS4 and if I tap on the search input, it gains focus on the first tap and I can enter text normally. Are there some specific steps needed to reproduce?

Unfortunately, a video isn't helpful for us. We need to be able to reproduce this on a real device relaibly so we cna troubleshoot and fix and issue so hopefully, we can get some clarity on what code is needed to reproduce this reliably on a specific platform version.


I will try to get something to you by Monday...I had a similar issue with text fields.

Todd Parker

Thanks for helping us track this one down @himanshuranavat. This issue seems like chasing a ghost!


This issue was fixed for me around beta 1 or 2.


Where the code is seems to have an impact as well. We have a development and a demo server. Same code on both (just did a merge) and it would work just fine on demo but would require you to refocus on development.

Todd Parker

@twomz - now that is really bizarre. This is such an odd issue...


@twomz @toddparker - does this mean you guys have reproduced the issue?

Todd Parker

Looks like I hadn't actually tested as much as I thought I had.

Using 1.0b3 it didn't work on our dev server for the webapp or on our hybrid app, but worked on demo/live. Using 1.0rc1 it now works everywhere (there is a hidden field in front of the hybrid app login page, that didn't work for 1.0b3 but is working 1.0rc1). We had code in a js file that used ui-collapsible-contains instead of ui-collapsible that was preventing some css from being applied so we reverted to 1.0b3 and I forgot about it. But now that it is fixed we have everyone on 1.0rc1 and everything is working (at least, the login page that was the main problem is now working correctly, I still have to test our other text boxes).

I'll edit this post if I find a problem somewhere else.

Todd Parker

Looks like we have confirmations that this is fixed in latest from @scytalezero and @twomz but I want to give @himanshuranavat a chance to day to cook up a test case before closing.


@toddparker: I am unable to come up quickly with a simple page that demonstrates this issue. On the page where this issue could be reproduced we are continuously changing CSS of a progress bar and other things in the background in a ajax success handler that runs every few seconds. It will take me some time to isolate the actual scenario in which the issue is occurring. I will use the new release candidate and see if I can still reproduce the bug.

Todd Parker

@himanshuranavat - please use jsbin and reference the latest, not RC1. Here is a template:

Todd Parker

I haven't gotten a clear test case in 4 months, closing as fixed.

Todd Parker toddparker closed this February 15, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.