I'm working on an html5 app that will be used on iPads in a kiosk mode. The first thing users must do is sign in, so when the homepage loads, I'd like the onscreen keyboard to popup with the focus in the first field.
I've tried all the variants I can think of, including
html5 <input autofocus> attribute
calling document.getElementById("nameFirst").focus() in window onload
same as the previous, but the onload calls a timer method to invoke the focus call later
Has anyone figured out how to make the keyboard automatically appear?
Mobile Safari doesn't allow keyboard showing up without user touching text input element. I think it's by design.
http://www.quora.com/Mobile-Safari-iPhone-or-iPad-with-Javascript-how-can-I-launch-the-on-screen-keyboard
Related
Can I manually show/hide device keyboard?
My application is behaving strangely if device keyboard is on display and, say, I hit next button then the CSS of jQuery Mobile is getting distorted. I am not getting any javascript or any other error in the console. Any help is appreciated.
I have used one of the suggestions in the following question (the one with 84 up votes...), and it worked well for me: iPad Safari - Make keyboard disappear
Lets assume you have an <input type="text" id="myInput" />.
So in your change page code you can do the following, which will first dismiss the keyboard and then perform the page navigation:
function changeToPage1() {
$("#myInput").blur();
$(':mobile-pagecontainer').pagecontainer('change','page1.html');
}
Tested in iOS Simulator but should work in Android as well.
This is a bug that I have managed to fix by brute force, but I don't understand why the solution worked.
The problem was that embedded YouTube videos weren't working on a particular (responsive) site on iPad (tested in iOS7) in landscape view. I managed to narrow it down to a particular CSS rule that was showing a search input in the header when the browser was wide enough, so it would show in an iPad's landscape view but not in its portrait view.
After a little more brute force fiddling, I found that removing the type="search" from the input tag (which causes it to fall back to the default type="text") would fix the problem. None of my searches have come up with an explanation for why this works though, or even anyone else experiencing the same thing.
Some more details on the bug
The site works by showing an image at first, which would be replaced via JavaScript with the YouTube iframe when clicked. After this first click, it would autoplay on desktop browsers, and on the iPad it would load the video but wouldn't play until the user presses it again.
If the type="search" input was visible (display: block;), then tapping on the embedded video would not cause it to play; there would be no visible response to the tap. If I zoomed in and tapped on the controls at the top, like the name of the video, I could see them being underlined, and testing showed that there was no element covering the iframe and intercepting events.
Strangely, tapping on the very edge of the right hand side of the iframe would cause the video to start playing correctly. Otherwise, changing the iPad to portrait view (causing the search input to be hidden via CSS) would enable the iframe to be clicked in order to start the video playing. After that first click, all the video controls would work regardless of whether or not the search input was showing.
Just experienced this first-hand myself and wanted to add my kudos for you having written this up. Your SO question, even without an answer, pointed me in the right direction.
In my case it was nothing to do with Youtube. I had a page generated by Drupal in a large-ish site, in which the site-wide search mechanism used an auto-complete drupal module which had type="search" as the main input's type.
In IOS, users reported that Facebook, Twitter and Google Plus's respective "like" buttons all didn't work, along with a much larger angular app embedded in the page. They all used iframes and none of them seemed to respond to clicks.
Changing this seemingly innocuous, unrelated input's type from search to text solved this problem immediately.
Baffling.
I am building a mobile web app that uses jQuery and hammer.js for touch controls. hammer.js has a feature called "prevent_default" which turns off Safari's scrolling/zooming/prettymucheverything. I have a page with a form using < input > for text fields, and a javascript listener that calls .focus() when you tap the form.
This all works well up until a point. The page is fixed in place and looks real pretty, and when you click on a form field it zooms in and the iOS keyboard appears. The problem is that when the user is done entering text, there is no way to zoom out. The browser is so zoomed in from .focus() that the browser bar is gone and you have to close the browser tab and re-type in the URL instead of refreshing.
I am looking for a way to force the browser to zoom out back to the initial view. I've looked all over the internet for some solution but have yet to find anything.
I have the viewport meta tags in the header to disable zooming from the beginning, but is not useful in solving this issue
A hacky solution is to focus and blur an inputfield after you have changed the viewport attributes.
function refreshViewportZoom(){
var viewport = document.querySelector("meta[name=viewport]");
viewport.setAttribute('content', 'initial-scale=0.5, maximum-scale=0.5, scale=0.5, user-zoom=0.5, zoom=0.5');
document.getElementById('myInputField').focus();
setTimeout(blurLater,2000);
}
function blurLater(){
document.getElementById('myInputField').blur();
}
The blurLater is needed as a function, because Safari seems to look ahead and ignore it otherwise.
I have a form that appears in a FancyBox iframe modal. On iOS 5 (specifically on an iPhone - does not occur on iPad) when I touch the submit button it activates a <select> that appears about 50 pixels above the submit button and I'm then presented with the <select> options at the bottom of the screen.
I've zoomed in as much as possible to verify that I'm not touching the select – I am indeed clicking on the submit button and it highlights itself as expected, but the form of course does not submit and I get the options to pick from.
Has anyone experienced a bug like this in iOS 5? I can't pin this down to anything else – there is some javascript that would normally run to process the form on submit click but it's not being activated at all and it has no effect on the form itself, the <select>, etc. I have seen several odd things with iframes on iOS and wonder if there is a potential correlation.
You might have the connections for your actions going to different buttons than the outlets. That would explain why the right thing would happen (Action is OK) but updating the Frame Rect would get messed up (Outlet is on the wrong button).
iframes on ios don't behave like normal iframes in every other browser (including desktop safari).
ios safari renders them at the full height of the page inside the iframe.
To get them to scroll like a normal iframe of fixed height you have to put them in a div and set the divs overflow to auto or scroll. I'm guessing your modal overlay is already doing that.
But even a plain in-page iframe with no special positioning (other than using a parent div to crop its height and make it scrollable) will often only have the submit button work 1 time if the submit buttons original rendered location was below the fold of the parent div.
So the first submission will work, but if the form comes back with missing required field errors you can't hit the submit button again.
Further research on my old ipad shows that if the submit button is down far enough it won't even work that first time.
The bug is present in safari for ios 5.1.1 and also ios 8 !!!
I can use an onclick javascript function on any element in the iframe that is not an input type=submit to force the form to form.submit().
But specifically about the iphone issue what was probably happening was that the OS was trying to zoom in to the form field so the use could clearly see what they were typing. The fix for that might be to declare a font-size of at least 16px on input elements. That way the OS knows the text in the field is already at a fairly readable size and won't try to zoom in. Zooming in to the contents of an iframe within an absolutely positioned modal overlay is super buggy even in ios 8.
I'm coding an iPad application that uses a UIWebView which contains an <input> tag. It doesn't make sense in the context of the app to use AutoFill, but when editing the field, a bar appears above the keyboard with "AutoFill" and "Previous / Next".
Is there a way to tag/style the <input> so that this bar does not appear? Adding autocomplete="off" doesn't do it. Barring that, is there a way to bypass Safari's keyboard, and call out to iOS APIs to handle the text input instead? Thanks!
As far as I know, this is a feature of Mobile Safari which is under the control of the end user, and cannot be enabled/disabled by your application.