So I have an input at the bottom of my page, positioned like so:
position: fixed;
bottom: 0;
left: 0;
width: 100%;
height: 40px;
When I open the keyboard on iOS Safai, there is unwanted whitespace below the input. You can scroll up from it but it shouldn't be there.
The highlighting is from Safari Dev console, I've highlighted HTML, so the extra whitespace is not being caused by my HTML/CSS I think...
This does not happen on Android.
Any Help?
iOS safari does not respect position: fixed when the input has focus. What seems to be happening is that the element's position attribute is changed to static.
There are a couple aways around this, but the ultimate best answer for now would be to not use fixed.
Additional reading: https://medium.com/#im_rahul/safari-and-position-fixed-978122be5f29
Related
I have a native iOS app with a webview to display web content.
I have a fixed header in my app with the following properties:
#header {
height: 60px;
background-color: #mainColor;
color: #ffffff;
padding: 10px;
text-align: center;
position: fixed;
width: 100%;
z-index: 1;
}
Before I upgraded to iOS 11 everything worked fine. Now when I scroll down/up the header disappears during the scroll, and when the scroll is done, the header appears again.
This can also be reproduced in Xcode 8.
I'm just writing some code, try with one by one
Try with below
self.automaticallyAdjustsScrollViewInsets = false
Try with below
[self.webView.scrollView setContentInsetAdjustmentBehavior:UIScrollViewContentInsetAdjustmentNever];
Try with below (change your code)
header {
height: 60px;
background-color: #mainColor;
color: #ffffff;
padding: 10px;
text-align: center;
position: fixed;
width: 100%;
z-index: 1;
transform: translateZ(0);
-moz-transform: translatez(0);
-ms-transform: translatez(0);
-o-transform: translatez(0);
-webkit-transform: translateZ(0);
-webkit-font-smoothing: antialiased;
}
And some helpful links might be useful for you!
http://ayogo.com/blog/ios11-viewport/
https://forums.developer.apple.com/thread/90472
How to fix the iOS 11 input element in fixed modals bug
https://github.com/PierBover/ios-iframe-fix
https://stanko.github.io/ios-safari-scoll-position-fixed/
From Apple official note:
Important:
Starting in iOS 8.0 and OS X 10.10, use WKWebView to add web content to your app. Do not use UIWebView or WebView.
So you should try once with WKWebView.
position: fixed has always been a problem with iOS. It seems that in every version of iOS the problem persists. Now, I couldn't find anything regarding the change of behaviour of your application from iOS 10 to 11, you could consider reporting this as a bug; on the other hand having seen the multitudes of people who encountered this problem and the fact that affects more or less all the recents versions of iOS I would suggest not to use position: fixed.
The most common workaround is transform: translateZ(0), this not only works on iOS and prevent any possible flickering, it also forces the browser to use hardware acceleration to access the GPU to make pixels fly. It should work also without the prefix -webkit- from iOS 9.
I had this very similar issue with a Cordova project built for iOS, which uses a webview. Cordova uses the UIWebView by default as its webview engine and I tried all the possible fixes mentioned in this thread and many others. Finally our only solution was to change the webview engine from UIWebView to WKWebView (https://developer.apple.com/documentation/webkit/wkwebview). With Cordova, introducing the WKWebView is pretty straightforward with a plugin https://github.com/apache/cordova-plugin-wkwebview-engine
After introducing WKWebView and dealing with some of the issues it causes we are no longer experiencing the flickering or disappearing fixed positioned elements while scrolling in iOS 11.
We had the similar issue and it got fixed with below 2 plugins
https://github.com/apache/cordova-plugin-wkwebview-engine
https://github.com/TheMattRay/cordova-plugin-wkwebviewxhrfix
First plugin will change default WebView to WKWebView and second plugin provide fix for CORS issue that we see for using WKWebView.
The trick is to force GPU acceleration. Do this by adding translate3d to the #header element.
transform: translate3d(0,0,0);
If elements nested inside the #header element continue to disappear add translate3d to them as well.
Position fixed doesn't work well with iOS, but I used position absolute in my cordova apps which never causes any issue for me.
You may have already seen this post on some changes in iOS 11, but if not maybe it would apply to your situation?
One of the viewport-fit: contain/cover/auto options?
Or changing your code to use a constant value for the padding-top?
Did you try to use position:sticky instead of position:fixed?
In past it works really well on iOS.
Please make note that is position:sticky requered rule top to be defined.
So final solution in your case should be:
#header {
height: 60px;
background-color: #mainColor;
color: #ffffff;
padding: 10px;
text-align: center;
position: -webkit-sticky;
position: sticky;
top: 0;
width: 100%;
z-index: 1;
}
Also if you need extra offset from top you could adjust top:0; rule from zero to any number in px.
And one more final note: that is sticky element will not extract element from document flow and will act as ordinary document element (like div with position:static or relative), but not like absolute positioned element (in case of fixed or absolute).
http://caniuse.com/#feat=css-sticky
I have been battling against this very same problem myself.
The issue (at least as manifested in the app I am working on) only seems to happen on screens which are a combination of tall (in that they require a good deal of scrolling) and fairly complex.
Generally, at least for me, the problem only seems to really manifest when momentum scrolling kicks in.
Although there's one screen in particular, which contains 15 left-right-scrollable rows of images, that will break the head/footer no matter how slowly you scroll it.
In my own defense... I had absolutely nothing to do with the design. :-)
At any rate...
After much searching an experimentation, I have managed to come up with a "solution" of sorts.
Mind you, I'm not claiming this is the way to go here. But perhaps someone with more experience than I have in the mobile app space, can take this information and extrapolate something less sucky from it.
The first piece looks like this:
html,
body {
position: fixed;
width: 100%;
height: 100%;
overflow: hidden;
-webkit-overflow-scrolling: auto;
}
And then for the container that acts as the main body of your screen:
.main-content-area {
overflow-y: auto;
height: 100%;
}
This is going to kill momentum scrolling for your app. Which is not great, I know. But as a result of curtailing the user's ability to scroll very quickly, screen rendering seems to be able to keep up and the problem goes away.
Again, I'm not recommending this as a viable solution for production. Because it's obviously not great.
I'm offering this up more as a possible stepping-stone to a real solution, in the hopes that it helps.
===>>> UPDATE:
I have a working solution. But, as others before me have pointed out, I had to avoid the use of Fixed Positioning.
Instead, I used Absolute Positioning to define Header, Footer and Main Content sections of the page. Then allowed scrolling only in the Main Content section.
If it helps, I have the POC I put together available on BitBucket
this works for me
position: sticky
I had this same issue with both position:fixed and position:sticky. Chaging from UIWebView to WKWebView fixed it for me:
#import <WebKit/WebKit.h>
....
#property (weak, nonatomic) IBOutlet WKWebView *myWebView;
"Starting in iOS 8.0 and OS X 10.10, use WKWebView to add web content to your app. Do not use UIWebView or WebView."
https://developer.apple.com/documentation/webkit/wkwebview
I'm working on a simple tic-tac-toe application and building it in CodePen. When the user loses or forces a draw (designed to be unbeatable), a jquery UI dialog box pops up informing the user of said result. Issue I'm having, is that when this happens, a large empty space appears causing a scroll bar to appear at the right of the page. This is a small detail - but I'd like to fix. I cannot put overflow: hidden on the body because then users won't be able to scroll on small screens or in resized browser windows. I've already tried the following to no avail:
adjusting position of dialog to very top of screen
putting overflow: hidden rule just on .ui-dialog
adjusting the height of the dialog box
adjusting the margin-bottom of .ui-dialog
messing with other dialog options to see if they were the cause
Some of these seemed far-fetched but I wanted to try everything I could think of before coming here. Research has turned nothing up either. I'm running Chrome and the pen in question can be found here: http://codepen.io/no_stack_dub_sack/pen/YGNRxO.
Any help on this would be much appreciated! Thanks in advance.
Again, this is a small detail, but since the app fits all on one page without scroll on most screens, I'd like to keep it looking as clean as possible.
Here's the code:
// DIALOG BOXES
$('body').append('<div id="draw" class="gameOver"><p>It\'s a Draw!</p></div>');
$('body').append('<div id="loser" class="gameOver"><p>You Lose!</p></div>');
$('.gameOver').dialog({
autoOpen: false,
resizable: false,
height: 120,
dialogClass: 'no-close',
buttons: {
'Play Again?': function() {
$('.gameOver').dialog('close');
setNewGame();
}
}
});
Somewhere in the dialog creation process, the position is set to relative on your dialog, which causes the height of your game to calculate the dialog, which gives the empty gap. You can simply set ui-dialog position to absolute in the css, and it'll solve the problem:
.ui-dialog {
position: absolute;
box-shadow: 1px 1px 30px 5px;
background: #04A777;
border-radius: 10px;
outline: none;
overflow: hidden;
margin-top: none;
}
http://codepen.io/anon/pen/EgmoGZ
I'm trying to get momentum scrolling to work, by setting a class called momentum-scrolling on a top level div that wraps the part of the content that scrolls. The class is defined as:
.momentum-scrolling
{
overflow: auto;
-webkit-overflow-scrolling: touch;
}
Yet it is not working (testing in simulator on both iOS 7.1 and 8.1).
Here is a link to view the example on jsbin directly (suitable for viewing in a mobile device for testing):
http://jsbin.com/cewobokisi/1/
Here's the link to the editable stuff on jsbin:
http://jsbin.com/cewobokisi/1/edit?html,css,output
(Note that the CSS shown includes minified bootstrap, and a few other things. I left this like this because while it's a bit harder to edit, I was trying to reproduce the issue exactly as we have it in our site now, in case anything we're doing is causing the issue.)
Update
I've got a modified version here (http://jsbin.com/sibofucexe/1) where I've modified the .momentum-scrolling style to include position: fixed, height/width 100% (based on some other posts I found with momentum scrolling examples):
.momentum-scrolling
{
position: fixed;
height: 100%;
width: 100%;
overflow: auto;
-webkit-overflow-scrolling: touch;
}
And that does now allow for inertial/momentum scrolling to work!
However, now I lose the ability to tap on the top bar to scroll the window to the top, and occasionally I cannot scroll up or down (typically when the DOM is being manipulated by JavaScript, due to an ajax hit to add more data).
Any ideas on these issues? Am I doing this wrong?
I know this is a late reply, but for the sake of future Googlers:
According to CSS Tricks, you must use overflow: scroll rather than overflow: auto. That may cause your first example to work.
I've run into an issue with CSS sprites used for a sidebar widget in our site. On the iPad with iOS 7.1, the sprites are all pushed down too far.
I have tried several other suggestions with no noticeable changes:
Specifying a background-size to prevent scaling (not a scaling issue)
Using background-clip and -webkit-background-clip to clip to padding box
Setting the viewport to minimum-scale=1.0, maximum-scale=1.0, as well as initial scale, disabling user scaling, etc.
You can see the icons on the following website:
http://eugenedining.com/featured-restaurants/
You'll notice it is only a vertical alignment issue. The icons are all in the right place horizontally. When you click on an icon, the active state (white on orange) does not shift around, althouhg it is still cut off. It is not a sizing issue.
I think the <span> element is actuall being pushed down by something.
Any ideas?
Preview:
So I guess there is a mysterious padding / linebreak issue of some kind that appears inside the <a> and before the nested <span> element.
Switching the span to absolute positioning has fixed the issue, but I'm still clueless where the extra space comes from.
Luckily most of my structure is done to the <a> element, so this was pretty straightforward to implement.
.tag-list li.tag-item a {
position: relative;
}
.tag-list li.tag-item a span {
position: absolute;
top: 0px;
left: 0px;
}
I have attached two pictures, the first shows the "desktop" of the webapp I work on, some of the icons you see open dialogs made of a <div/> containing an <iframe/>, but while on a normal pc it all works properly, on the iPad it seems there is a problem with the z-index of some elements, as shown in second picture.
The small red rounds with number inside are defined as follows:
.countComunicazioni {
position: relative;
background: url(/images/admin/menu_sgs/counter.gif) no-repeat center center;
height: 35px;
width: 35px;
color: #FFF;
top: -105px;
left: 120px;
z-index: 0;
font-weight: bold;
display: none;
}
.countComunicazioni p {
margin-top: -5px;
padding-top: 10px;
}
The markup is a <div class="countComunicazioni"/> tag and a <p/> tag inside.
I also noticed that now the problem also appears in Google Chrome V22, the numbers in red circles are always on top even if they have z-index == 0 and the dialogs have z-index > 1000.
As per this bug report ( http://code.google.com/p/chromium/issues/detail?id=144518 ), the change seems to be intended, even if I would bet it'll broke many layouts, not only ours.
This problem was not present in previous versions of Google Chrome, nor is present on Firefox V15 or Internet Explorer V9, where everything is rendered problem.
How can this problem be solved? I'm no CSS expert, so I must admit I have tried little, if anything, so far... And also, who is "right" here? Is our markup incorrect, or does the problem lie in google chrome new rendering strategy?
EDIT
It seems I've been able to solve the issue shown in the two pics: all the dialogs generated from my web app are placed inside a <div/> with position:fixed placed on the very top of the body, now I tried to move the div to the very bottom of the page, and the layout seems now correct.
There is one more problem though: when opening a modal dialog, the opaque layer that is supposed to be created between the dialog and the below content, is actually created above it, see new screenshot.
How could this problem be solved? Does it require modifying our javascript or is it an issue with jquery ui itself?
Just found out myself that the way that chrome 22+ handles z-index has been altered.
Check out this awesome explanation here that I didn't write here...
http://updates.html5rocks.com/2012/09/Stacking-Changes-Coming-to-position-fixed-elements
Basically the way I understand it is that elements which have
position: fixed
now get counted with their own z-index layer so you'll have to adjust your pages accordingly to suit.
Hope that helps!