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.
Related
This will be difficult to explain so I won't paste any code.
I'm implementing a wysiwyg editor on my site called wysihtml5 and there are several issues when selecting the textarea/editor with the iPad. On a desktop browser, all is fine, the text can be selected, edited, pasted etc. But on the iPad multpiple issues occur:
Can't tap anywhere in the text to move the cursor there
If I manually move the cursor, all of a sudden I can't type anything anymore
Tapping outside of the texteditor doesn't bring the keyboard down
Basically I'm just hoping there's someone who has had similiar experiences with iPad cursor not behaving correctly in text input fields and what possible solutions there might be. I'm stuck and have no idea how to debug this.
Did you use touch event? iOS has a bug: you can't input in editable iframe if you are listening(or had listened) any touch event(touchstart, touchmove...), I tested this bug occurs even you listen other elements but iframe itself. yes, it's a serious bug, you can check out:
wysihtml5 issues98
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'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.
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.
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