I have a problem with the KeyboardShrinksView feature that is included in Phonegap 2.6 (ios).
When I tap in the textarea where I want to include text, the keyboard appears and the webview is contracted as I wanted.
The problem is that I lose the focus on the textarea and the user has to tap again in the text area to start writing in it.
Is anyone having the same problem with this new feature?
Thanks!!
add a tap (or touchstart) event on your input which will focus on your field.
element.on("tap", function(e){element.focus()});
The issue comes from the fact that focus is done on ios using the ghost click event. But the view has already changed (because of the keyboard) when it's fired.
This problem will be even more common on ios7 since KeyboardShrinksView is the default behavior...
After the web view is contracted try writing this code.
[TextFieldOnWhichFocusIsExpected BecomeFirstResponder];
I ran into this problem for iOS after upgrading from Phonegap 2.9 to 3.1. Solved by adding height=device-height to my meta tag, so it now looks like this:
<meta name="viewport" content="width=device-width, height=device-height, initial-scale=1, user-scalable=no">
Related
My site used to work in full screen when I created a Web App for it, however lately it doesn't show in full screen anymore. Is there something that has changed with the new iOS version or a new Safari version?
I still have the meta tag : <meta name="apple-mobile-web-app-capable" content="yes">
Just to confirm, I am refreshing the website and adding the bookmark to the home screen. I can't seem to figure out what has changed.
Thanks
RF
This is a subject that gives us a lot of problems whenever IOS is updated. So now iOS 9 is here we have once again been searching for answers. I am happy to say we have found a fix and it may well work for you too.
For iOS 8 we found that adding the following meta tag
<meta name="viewport" content="width=device-width,initial-scale=1.0,minimal-ui">
... and scrolling the page about a bit and back to the top using JS would do the trick - which no longer works with iOS9
window.scrollTo(0, 1);
window.scrollTo(0, 200);
setTimeout(function() {
window.scrollTo(0, 1);
}, 100);
But, what we have now found is that changing the meta tag slightly has once again rectified the problem (notice the scale):
<meta name="viewport" content="width=device-width,initial-scale=1.01,minimal-ui">
I've stumbled across this strange Meteor JS behaviour when using the following meta tag in the head:
<meta name="viewport" content="width=device-width, initial-scale=1">
When tapping anywhere on the body in iOS Safari some kind of click/touch event is triggered. It's clearly visible because it creates and outline/highlight on the body just like it would for a normal link when it's clicked.
For a demo open this link on your iPhone:
http://metaviewportissue.meteor.com and click anywhere on the body.
Code is here:
https://github.com/st3phan/meteorviewportissue
When I remove the meta viewport tag the click/touch event on the body is gone.
Does someone know what's going on here and maybe how to get rid of this strange behaviour?
Versions:
Meteor 1.0
Safari 8.1
I am developing a mobile web site using Sencha Touch. In iOS7 Safari I cannot make the top address bar & the toolbar below go away. Sencha used to handle this upto iOS6 but some recent changes in iOS7 is causing this issue.
http://java.dzone.com/articles/safari-ios-7-and-html5
I read the above link & it seems this is also an issue for HTML5 Games & a few other apps.
The old window.scrollTo() which worked for iOS6 no longer works.
Add minimal-ui in your meta tag viewport, this will hide he address bar and browser controls in safari iOS7:
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0, user-scalable=no, minimal-ui">
More info on iOS7 and fullscreen mode for mobile websites: http://blog.initlabs.com/post/81716286465/how-to-display-websites-in-fullscreen-mode-in-ios7
With iOS 7 I don't think you really have a choice. Obviously Apple doesn't want developers doing this anymore, and even if someone finds another workaround it probably won't stick around for that long.
Honestly, I think getting fullscreen functionality is a fair trade off for users to install the app to their home screen. Obviously there are certain cases where this isn't true, but I guess I find it understandable to some degree. You should still be able to add the following meta tag and it will be fullscreen once added to home screen:
<meta name="apple-mobile-web-app-capable" content="yes">
There are a few nice libraries out there that add an "add to homescreen" prompt that you can set up to be rather unobtrusive with custom messages. In this case, might be best to embrace the change...
I'm trying to recompile an app for iOS 7, since nothing of the old one works so far.
One of the many problems is that I'm using some inputs inside UIWebViews. Text inputs, pickers etc.
Now, when the iOS 7 shining white keyboard appears, all the bottom fixed elements in the webpage (such as, confirm buttons) are scrolled upward, as if the 'top' of the virtual keyboard is the new bottom of my UIWebView. This is a substantially different behavior from iOS6.x
Is there any magic trick to make the virtual keyboard behavior work like it used to, without injecting JS/CSS to the webView?
This fixed the problem for my cordova app. I'm not sure if it applies to you but just in case.
Check your html meta tags for something like this:
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0, user-scalable=0">
Replace it with this:
<meta name="viewport" content="width=device-width, height=device-height, initial-scale=1.0, maximum-scale=1.0, target-densityDpi=device-dpi" />
In our case this would fix itself as soon as user scrolls. So this is the fix we've been using to simulate a scroll on blur on any input or textarea:
$(document).on('blur', 'input, textarea', function () {
setTimeout(function () {
window.scrollTo(document.body.scrollLeft, document.body.scrollTop);
}, 0);
});
I ran across exactly the same problem & gave up after two days of experimenting. It seems that:
a) all bottom-fixed elements go upwards so that their bottom offset is relative to the top edge of the keyboard
c) all top-fixed elements stay in their original position (do not move upwards as they used to) - note that top-absolute elements work ok.
The only solution I found was to have a custom iPad stylesheet that replaces all fixed elements with absolute elements, sets the css bottom property to auto and uses top instead
Opposum, your solution worked for me but only when the scale was set to 1.0. If I set it to 0.9 then it would be like it was before your suggested fix. I set initial-scale, maximum-scale, and minimum-scale to 0.9 and the bouncing effect of the fixed objects when the keyboard appeared was still happening.
I developed a web app for the iPhone which has a page with a textarea widget. When I begin editing the contents of this textarea widget Safari zooms in and makes the text really, really big. Now I can't see the document anymore, just a little postage stamp sized piece of it.
Are there any properties I can set which will keep mobile Safari from doint this? I just want the textarea font to stay the same size when I edit its text. Thanks.
You can add:
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0, user-scalable=no">
to your HTML header.
You would need to set your textarea font-size to 16px and have an initial-scale of 1.0.
But if your app is not really designed for the iPhone, that is, if it’s essentially a normal web page that users should be able to scale, then you should probably just become okay with it. The worst thing to do to your users is show them 6pt text they can’t zoom, you know? Some of them won’t have perfect vision.
See also: Apple's list of all Safari/iOS special meta tags.