I'm building an iOS wrapper application for a web page, which was built using Bootstrap, at the top of my web app is a .navbar div, not fixed or anything and displays perfectly on first load.
The problem starts when I touch an input, type and then hide the keyboard. Once the keyboard has hidden the page has been moved back down, but the navbar is nowhere to be seen.
It turns out this was caused by a bug in the CSS code which gave a margin to the body. The simplest way to fix this was to change the CSS. Although I'm still none-the-wiser as to how control the UIWebView in such situations.
Related
I'm having a problem with on iOS quite unusual - on a form-style screen when I need to type information into a field, the keyboard pops up, but the screen doesn't go up nor allow scrolling, making it impossible to see what I'm typing.
In CSS, I'm using this within classes:
overflow-x: scroll -webkit-overflow-scrolling touch;
overflow: hidden -webkit-transform translate3d (0,0,0);
The curious thing is that on Android is normal...
Why is this happening? What should I do?
The keyboard on iOS behaves in a very special way, here's a quote from a great article on this topic The Eccentric Ways of iOS Safari with the Keyboard:
The fundamental problem is that when the soft keyboard appears due to a user tap on a text input box near the bottom of the screen, Safari doesn’t resize the browser window but instead moves it upward such that it is partially offscreen
You're likely preventing the body to move up, so make sure there's no code that would interfere with that.
I am having a strange problem with input in ios safari
as shown here.
The input is part of an angular app and has some basic checks for ng-length and ng-pattern. Initially as you type all the characters are showed, but if you play around with the page a bit, like tapping out, scrolling up and down, then tapping in again only the first 2 letters of what you type will show and the rest will be invisible, but the cursor will still move.
The input also uses a custom web font, but removing it did not fix the problem.
Is this a known bug and is there a workaround?
You can add
transform: translate3d(0, 0, 0);
to the input's style.
This will form a new stacking context and solve the problem.
I found my problem: an iframe being positioned absolute, hidden, from which I listen to the resize event as a solution of monitoring a div width. Removing position:absolute from it fixed it.
I am developing an app (IOS platform) using HTML5, CSS3, angular and cordova(3.8) and stuck with an major issue.
I have a page with footer having three buttons. On click of each button a modal comes up from the bottom. Modal position is set to fixed and inside it as scroll-able container. scroll-able container contains a text area where user can input some text.
Whenever the modal comes up, text area is focused so that keyboard comes up by default. The issue is whenever native keyboard comes up webview is pushed up and entire modal gets scrolled.
I saw same issues been posted by others and I tried few solutions mentioned in reply for those questions like using ionic keyboard plugin, setting scrollTop to 0 on textarea focus. But nothing worked out.
In config.xml, I have set DisallowOverscroll to true.
It would be great helpful if someone help me with this issue ?
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.
PLEASE NOTE: This is not a "use two fingers to scroll" problem. Whether it is one finger, or two, or three, or the whole hand, for some reason our iframe does not scroll on an iPad. :)
Here is the scenario:
In our web application, which is built using EXT-GWT, we have a few windows that open as (maximized) pop-ups and present some forms to the users. These forms, which are most of the times external, are rendered in an iFrame and some of the forms have their content collapsed at the initial load - the user can choose to expand any section of the form, fill it in and submit. Now everything works fine except the scrolling in iPad. After the iframe's content is loaded and collapsed (collapsing is done using JS on the client side, basically, the content loads as expanded by default and then is collapsed by JS) iPad just fails to provide scolling to the iframe. Even after the content of the iframe is expanded the iframe does not get any scrolling.
As of now, we have solved this problem by increasing the height (using JavaScript) of the EXT-GWT window to the size of the expanded iframe body content. This makes the whole window scrollable, instead of just the iframe within the window. While it works, the window becomes way to big, so I was wondering if there is any better way for us to provide scrolling to the iframe.
Thanks for the help,
Nitin
For iOS devices you need set overflow: auto; or the scrolling won't work. For my web apps I used fancybox to display iframes modally and once I change the overflow setting in the css file the two finger scroll worked perfectly on the iPad.
After trying (almost) everything, I have come to the conclusion that increasing the GWT window height to the iframe.body.height is the only solution for getting the window/iframe to scroll on iPad. Hopefully, this will help someone in future.
I´m pretty new to GWT, but for me it worked like this:
The parent-div of the iframe has a class in my case, x-component.
I made an entry to my css file like this:
.x-component{-webkit-overflow-scrolling: touch; overflow:auto;}
It works as well if I set these entries not to the class, but to the div-element itself.
Hope that helps