I have a fixed footer with bottom: 0. It works fine except on android it is appearing below the screen. I have some other fixed elements that are also appearing off screen. For some reason I cant container them within the screen I've searched around and tried a view things but no joy. My guess is that if I change something in the viewport it will fix it. The image was taken from google chrome emulating the site on an S4 but the same problem persists on my actual phone also. The code for the footer should just make it sit at the bottom and it works fine in other browsers. I can change the value of bottom to around 26px then the whole footer becomes visible on the screen but that is not the fix I want. Any ideas?
.footer-fixed{
position: fixed;
bottom: 0;
z-index: 99;
width:100%;
background-color: #111;
height: 50px;
}
i've had this issue before,
but only on android versions lower then 4.4, so maybe you could tell me what android version you are working on,
try adding:
<meta name="viewport" content="width=device-width, initial-scale=1.0, minimum-scale=1.0, user-scalable=yes"/>
to your
<head></head>
on Android < 2.3 devices for elements that are fixed behave as "STATIC", (thats why your top element could be functioning normally, because its the first element and pushes the rest down)
Android 2.3 supports it but u need to disable viewport scaling as i think once written by bradfrost cant exactly remember, it was a while ago
if you experience flickering of the elment try adding
-webkit-backface-visibility: hidden;
to your css class, or even extend it with
-webkit-transform: translate3d(0,0,0); makes some devices run their hardware acceleration.
-webkit-perspective: 1000;
its solves the flickering, but the thing is on some android versions you only need to add the backface-visibility hidden and on some the other 2 rules (trial and error). i should go for the first one, (at first) because adding the translate 3d, will drain more battery
anyways if its just a website try the solution above,
if you are making a cordova app, try adding https://crosswalk-project.org/ which add their own webview to your cordova package solving all these browser quirks on android.
--
a sidenote
when a element has position fixed, its display will be set to block,
and you have width: 100% on your elment, so if you are not using box-sizing:border-box;
the element would have a width of 100% + padding + margin added to it,
i don't know the rest of your css, maybe you are setting margin or padding by a container class which is
(check the metrics of your element with chrome inspector)
If this is the case you could do 2 things
change display
width: 100% to auto;
or add: http://www.paulirish.com/2012/box-sizing-border-box-ftw/
box-sizing: -webkit-box-sizing: border-box;
or add normalize: https://necolas.github.io/normalize.css/ to your project, above your own css (link tag) within the head (Normalize.css makes browsers render all elements more consistently and in line with modern standards. It precisely targets only the styles that need normalizing.)
Related
I have searched a lot and havent found any solution that works so here it is.
I have created a button that is after the content and have applied css for it to become sticky at the bottom of the page...
<button class="ocs-trigger ocs-toggle ocs-toggle-posts-toc-mobile">Περιεχόμενα</button>
button.ocs-toggle-posts-toc-mobile {
display: block;
bottom: 10px;
position: sticky;
position: -webkit-sticky;
margin: auto;
border-radius: 4px;
box-shadow: 0 0 3px 0 #d5d5d5;
background: #232f3e;
font-weight: 500;
font-size: 18px;
padding: 7px 12px;
}
It works everywhere in any browser i tested except mozilla android.
If mozilla bottom adressbar is visible the button works okay.
https://imgur.com/a/EJosALR
BUT if mozilla’s bottom address bar is hidden, the button isnt clickable.
https://imgur.com/a/A2jwzIl
When the mozilla’s bottom address bar is hidden i think the viewport height changes, and maybe because the button is now where the visible adressbar was maybe it out of the "active" viewport of mozilla... that's definetely a bug i believe cause it doesnt happen in other browsers!
Nevertheless can you take a look and see if i have anything i have missed?
I would really appreciate it cause i have looked almost everywhere i believe...
test url: https://thefinterest.kinsta.cloud/p/asjalska/
Investigations using Firefox remote debugging
TL;DR: With high probability a bug in the Firefox mobile app
So I've linked up my phone to the computer and started a remote debugging session on the page you provided.
When inspecting the button element <button class="ocs-trigger ocs-toggle ocs-toggle-posts-toc-mobile">Περιεχόμενα</button> we can see the exact box position highlighted in the viewport: screenshot
And now it gets interesting. Apparently, the DOM box of the element gets shifted as soon as the bottom bar disappears. Or rather: The initial viewport (when the bottom bar is visible) doesn't change, because the box is still located at the same position.
So you can in fact still click/touch the button but in an area above it.
You can see this behavior in the screen recording below:
Cookie banner is repositioned as expected
Interestingly, the behavior of the cookie banner (hidden in the screen recording because already confirmed) looks as expected though. So what's the difference to the button?
Workaround and working solution: move the button above the #ocs-site element
Apparently, after quite a lot of experiments, I realized the only difference between the button (incorrect behavior) and cookie banner (correct behavior) is the fact, that the cookie banner is in a rather top level of the DOM, whereas the button is nested quite deep in the tree.
Finally, I could find a working solution that makes the button behave as expected. Here you can see the correct scrolling behavior:
The solution I've come up with is to move the .ocs-trigger button above the #ocs-site div element. This fixes the incorrect scrolling behavior when the bottom bar disappears/appears.
Also, apply some styles on the .ocs-trigger element for the correct positioning.
position: fixed;
bottom: 10px;
z-index: 11;
left: 0;
right: 0;
Here you see the final DOM in a screenshot:
Please note, that you probably have to apply additional styling changes. This solution's major aspect was to get rid of the incorrect scrolling behavior.
Follow-up: Firefox Bug? Seems to me.
As it still appears to me at this moment, I would say this is a bug in the mobile Firefox implementation. My guess is, that the viewport calculations are somehow incorrect for nested elements.
In order to get some attention on this topic, I would recommend you to share these investigations and documentation with the Mozilla team at https://github.com/mozilla-mobile/fenix/issues. Let me know if I can help you with this.
The problem only appears on KitKat with the new WebView mechanism.
Basically I am loading 12 images, one after another in a row. I want the WebView to load all images on a row and auto zoom the webView to fir the entire row.
How it works prior android 4.4
the images are loaded on the row and the zoom is made to fit the entire row. The user can scroll in and out
How it works on 4.4
the images are wrapped, so I have the first image drawn and the next one is under it, not to its right
The html loads images like this:
<meta name="viewport" content="width=device-width, height=device-height, minimum-scale=0.3, user-scalable=yes, initial-scale=1"/>
<style type="text/css">
body {margin: 0; padding: 0; border: 0; float: left; white-space: nowrap;}
.Image .Tile-0-0 {background: url(tiles/tile_0_0.png) no-repeat; width: 128px; height: 128px; float: left;}
.....
and then
<body>
<div class="Image">
<div class="tile-0-0"></div>
<div class="tile-1-0"></div>
.......<br/>
Any ideas? My guess is that somehow I need to tell webview to fit the entire row, not wrap on the device's width.
How could I fix this ?
Android 4.4 (KitKat) has a completely different WebView (based on Chromium source) than previous Android versions. There is a migration guide that describes common problems you might experience.
In your case the first thing I'd check is whether the HTML renders correctly in Chrome.
If it does, try setting targetSdk to 19 in your manifest (this disables some quirks) and see if that helps.
If it doesn't it might be a change in how CSS is interpreted/layout is performed between the two WebView implementations. Try fiddling with your CSS and see if that helps. Using DevTools should make it simpler.
Another thing to look at is the viewport - see if the document.documentElement.clientWidth differs between the two versions. If it does then that's the reason it looks differently. If you're using wrap_contents height try using match_parent/a fixed value.
I'm working on optimizing a website for mobile devices, and I'm nearly done (yay!) but one thing makes me rack my brain:
How it works
I used CSS to restyle a tab-bar (actually a list) to work like a dropdown-menu. When touching the only visible list element, jQuery toggles the class "open" on the ul-element and all list elements appear also. That's how it works.
The Problem
When unfolding the dropdown-menu, it's font-size increases from 15px to 19px. And in Inspector there is absolutely no hint why this happens. Adding a rule like font-size: 15px !important; has no effect.
I made a little screencast for you: http://youtu.be/MUTJfTK70PE?hd=1
Affected devices
Android (Samsung Galaxy)
iOS (iPod, iPhone, Simulator)
Windows Phone (Internet Explorer) is not affected (wow!)
I would be very thankful for every single idea!!
You may try adding something like this: font-size: 1.5rem;
It turned out, that Mobile Webkits font resizing was the origin.
This rule solved it:
-webkit-text-size-adjust: none;
In html5 this is best solved by explicitly setting the viewport in the page header. The statement
<meta name="viewport" content="width=device-width, initial-scale=1.0">
turns mobile font resizing off. Setting text-size-adjust to none has the disadvantage of disabling zoom on mobile devices, still requires heavy prefixing and the value none seems to be ignored by some browsers.
After looking all around for solutions, I am just tired of trying out every straw I find.
So, my situation is like this:
I have a scrollable div with floated images in it and I am using scrollLeft, offsetLeft and style.width to dynamically expand this div.
Now, while this is working great on iOS and PC, on Android (7") the scrollLeft value is scaled down nearly to 50%! However style.width value is not scaled down, like the other ones.
This would be the css for my items:
.slider-item {
margin: 0 13px 0 0;
width: 300px;
float: left;
height: inherit;
}
And my viewport:
<meta id="viewport" name="viewport" content="width=device-width, user-scalable=no, initial-scale=1.0, minimum-scale=1.0, maximum-scale=1.0">
My questions:
is there somewhere a complete guide to webview from the HTML/JS point of view? because most of the time I stumble on solutions, where it is necessary to adjust the android-app - i would like to avoid that.
how can I determine the adapted scale of my device using JavaScript or the correct style.width respectively the correct image position?
If someone could explain this to me, I would be so happy!
PS.: Just found an additional bug: When I have scrolled some elements to the left, so far, that I reached the empty area; then tap in the empty area, it actually opens a link of one of the elements, which is by now out of sight! But the point where I tap would fit to the actual position, where the element should be on a normal display.
I am quite lost with this o_O
Edit: I mistakenly had put the wronk variable here: it's the syle.width of my slider-items, which is wrong, not their offsetLeft.
Working with #media might be impossible, as my window.innerWidth is 1280px on android and 1024 on iOS. Both show an offsetWidth or width property for my slider-items of 300px - BUT Android scrollLeft shows 155px, when I already have scrolled away one whole picture, which should have been 300px wide - there's the problem.
have you tried playing with WebView initial scale? Like this: webView.setInitialScale(100);
The Android browser, since 2.2, supports fixed positioning, at least under certain circumstances such as when scaling is turned off. I have a simple HTML file with no JS, but the fixed positioning on three Samsung phones I've tried is simply wrong. Instead of true fixed positioning, the header scrolls out of view then pops back into place after the scrolling is done.
This doesn't happen on the Android SDK emulator for any configuration I've tested (2.2, 2.3, 2.3 x86, 4.0.4). It also doesn't happen when using the WebView in an app on the Samsung phones: in those cases the positioning works as expected.
Is there a way to make the Samsung Android "stock" browser use real fixed positioning?
I've tested:
1. Samsung Galaxy 551, Android 2.2
2. Samsung Galaxy S, Android 2.3
3. Samsung Galaxy S II, Android 2.3
Sample code:
<html>
<head>
<meta name="viewport" content="initial-scale=1.0,maximum-scale=1.0,user-scalable=no,width=device-width,height=device-height">
<style>
h1 { position: fixed; top: 0; left: 0; height: 32px; background-color: #CDCDCD; color: black; font-size: 32px; line-height: 32px; padding: 2px; width: 100%; margin: 0;}
p { margin-top: 36px; }
</style>
</head>
<body>
<h1>Header</h1>
<p>Long text goes here</p>
</body>
</html>
The expected behaviour is that the grey header fills the top of the screen and stays put no matter how much you scroll. On Samsung Android browsers it seems to scroll out of view then pop back into place once the scrolling is done, as if the fixed-positioning is being simulated using Javascript, which it isn't.
Edit
Judging by the comments and "answers" it seems that maybe I wasn't clear on what I need. I am looking for a meta tag or css rule/hack or javascript toggle which turns off Samsung's broken fixed-positioning and turns on the Android browser's working fixed-positioning. I am not looking for a Javascript solution that adds broken fixed-positioning to a browser that has no support whatsoever; the Samsung fixed-positioning does that already, it just looks stupid.
Maybe you could consider a different approach that doesn't require fixed positioning...
Add scrolling to the paragraph element instead of on the (default) body element. You can then position the paragraph element just under the header. This will ensure that the header always displays at the top of the page yet allowing you to scroll through the text in the paragraph.
h1 {
height: 20px;
}
p {
position: absolute;
top: 20px;
left: 0px;
right: 0px;
bottom: 0px;
overflow-y: auto;
}
I think the best way for android 2.2 browser implement javascript.
You can find more info via this link. It is about fixed positioning in all mobile browsers.
http://bradfrostweb.com/blog/mobile/fixed-position/
In his comment to Brad Frost's article Matthew Holloway suggests a solution along the lines of Anita Foley's answer, but with a polyfill for overflow:auto, where not supported. Check it out here:
http://bradfrostweb.com/blog/mobile/fixed-position/
It's not Samsung's Android broken browser, it's Android 2.2 which has the broken support.
In general as you might know position:fixed was and in some cases still is pretty broken in many mobile devices/systems.
To answer to your question, there is no "toggle or meta tag" that will "turn on the Android browser's working fixed-positioning". If a browser doesn't have support of something, then there's no "toggle" to "switch" it. It's not a feature.
Otherwise, you can use http://cubiq.org/iscroll-4 which emulates it.
(edit: some facts)
According to http://caniuse.com/#search=position:fixed Android 2.2 and Android 2.3 have PARTIAL and not full support of position:fixed. (partial support seems buggy support)
An Android simulator is not and will never be identical to an Android native browser, as much as IETester for example is not the same as IE native (there are differences)
Motorola ATRIX 4G does NOT have Android 2.2 but Android 2.3 ( http://www.motorola.com/us/consumers/MOTOROLA-ATRIX%E2%84%A2-4G/72112,en_US,pd.html?selectedTab=tab-2&cgid=mobile-phones#tab )
You are suggesting that SAMSUNG introduces a proprietary hack or mod that breaks the otherwise working support of position fixed in the Android browser. This seems highly unlikely, regardless of the 3 above points.
The answer is actually simple: There is partial (buggy) support and your only solution is to use a javascript library that replaces or "fixes" the hole.