Infamous height:100% issue on chrome for android - address bar - android

I have created an angular app where the sidebar is height: 100%. However when viewing the webapp in Chrome for Android, when scrolling the document:
The chrome address bar slides up gently
The 100% real size remains the same until you TouchEnd
The darkgrey sidebar is height: calc(100% - 55px) so the top bar should normally always remain visible, and always fill the remaining space between the top bar and the very bottom.
I've already tried several things to get this fixed. The footer has bottom: 0 and this one is in fact always rendered correctly. So this made me try to use top: 55px; bottom: 0 instead of height: calc(100% - 55px). But from the moment you're setting both top and bottom, the result is the same as setting the height.
Does anybody know a way to make the viewport adjust its height while the address bar is appearing/disappearing?

I was able to solve this issue by
Creating a css variable (variables.scss)
:root {
--viewport-height: 100%;
}
Instead of using 100% use var(--viewport-height)
height: calc(100% - 55px);
becomes
height: calc(var(--viewport-height) - 55px);
Then binding to the visualViewport.resize event (MUST use addEventListener here)
if (!serverSide) {
visualViewport.addEventListener('resize', () => {
document.documentElement.style.setProperty('--viewport-height', `${visualViewport.height}px`);
});
}
Make sure there is no transition set for the height property.
CSS variables are supported by all major browsers.
VisualViewport docs
Linked-from-docs Demo with source code
Commit reference

Related

Mozilla Android AddressBar Conflict with Sticky Button on Bottom

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.

Bootstrap modal position in WebView UI

Using Bootstrap 4.3.1
On my site, modals work perfectly, in responsive mode too.
I also have an Android app, that among other functions, contains my site in WebView. When I trigger a modal within WebView in the App, on a long page - it opens at the top of the page (not vertically centered) and if you happen to be half scrolled down the page, you will not see it, as the position is fixed to the top, and you now need to scroll UP to see it (if you even know it opened).
Again, in a log web-page, in mobile form - the issue does not exist - only in WebView.
Has anyone run into this?
This is Bootstrap's position for the modal.
.modal {
position: fixed;
top: 0;
right: 0;
z-index: 1050;
display: none;
width: 100%;
height: 100%;
overflow: hidden;
outline: 0;
}
It seems that in WebView, the position: fixed; is ignored - as it's relative to the window, so if it scrolls down, the modals goes up with the page.
Tests for this are tricky, as to test properly, you need to test within an app, within a WebView Container (as I mentioned, in Chrome responsive on mobile, this issue does not exist).
Check this below styles are overwriting from some other styles,
position: fixed;
top: 0;
right: 0;
bottom: 0;
left: 0;
looks like a style rendering issue,
I hope it will work for you.
Put it in html javascript tag.
$('#here_put_modal_id').on('shown.bs.modal', function (e) {
// here are code
document.documentElement.scrollTop = 0
})
I want to post an update and close this question with an update for anyone who runs into this issue in the future.
It turned out that there was a bug in the app, and the "pull to refresh" module was interfering with the location of the popups. As soon as that was fixed, the modal opened in its correct position, based on the bootstrap existing code.
Thanks to all those who tried to help.
.edit-wrap
z-index 999
position fixed
left 0
right 0
top 0
bottom 0
overflow hidden
background rgba(0, 0, 0, 0.6)
display flex
.edit-container
background #d1cdb7
padding 1em 2em 1em 2em
margin auto
This stylus demo works on my webview

Resizing page and nav bar

My nav bar works as i want it to on normal sized pages/screens. How ever on phones or smaller screens it cuts off the black background of the nav bar and keeps the list contents. making them invisible, and a horizontal scroll bar appearing for what looks like nothing.
Preview of error:
My code in html is just a list, in css basic styling and position is
margin: 0;
width: 1920px;
Ive tried setting it to 100%,but it just forces the nav bar text over the image, without extending the black bar. I just used 100% max width for the picture and it works fine.
All the tutorials i can find use boot strap, im not using boost strap as this is a practice school assignment and bootstrap isnt allowed in the final
nav{
position: absolute;
top:0;
width: 100%;
}
#serv{
width:100%;
margin-top: THE HEIGHT OF NAV;
}
Push this to nav and #serv.
i think u haven't used navbar class in your navbar and refer my plunker and it is mobile responsive.
refer this Plunker.
use ul<>tag and li<>tag
[https://plnkr.co/edit/5gvJYTgRcp6WzrN9cIOd?p=preview][1]

Ignore virtual keyboard when positioning views (Appcelerator Android)

I have a view in appcelerator, here is the styling in the TSS file:
"#addTelephoneNumber" : {
bottom: "10dp",
height: "60dp",
width: "100%",
backgroundColor: "#FBB450",
borderRadius: 10
}
I want it to be at the bottom of the screen, however when the keyboard shows, the view moves up. See screenshots below:
Can the keyboard be ignored and overlap the 'Add number' button? I have tried using top and setting it to 90% however same problem. Setting fixed values in dp fixes the issue, however it does not scale correctly on different mobile devices.
There's two properties to configure this behaviour:
Ti.UI.Window.windowSoftInputMode to determine when the soft keyboard shows as well as how the content adjusts to make room.
Ti.UI.View.softKeyboardOnFocus to override the when per (input) view.

Fixed elements (HTML) break after android keyboard dissapears?

I am trying to place a text input at the bottom of the viewport/screen. It works fine, it even "sticks" to the top of the keyboard after the onfocus event.
When the keyboard is closed, however, there is lag between the changed position (top of keyboard) and the original position (bottom of viewport).
My css for the element is :
.fixed {
position: absolute;
z-index: 1000;
height: 50px;
display: block;
bottom: 0px;
width: 100%;
}
EDIT:
This behavior doesn't depend on fixed/absolute positioning only. Also inputs with position:relative or position:static have the same issue. It seems like the softkeyboard disappears much faster than the screen/browser view can update itself. Seems like a memory issue or a deep bug within Android's default browser (kill me now).
Here are some screenshots.
On focus :
http://i.cubeupload.com/AQS7h8.png
On blur (note the blue screen ± is that a mem issue?):
http://i.cubeupload.com/nV3kMh.png
Had the similar case with android keyboard ruining layout, the following code should work for you.
We are getting current position from top, setting the top style value, and resetting bottom value.
var fixed = document.querySelector(".fixed"),
distanceFromTop = fixed.getBoundingClientRect().top;
fixed.style.top = distanceFromTop + 'px';
fixed.style.bottom = 'auto';

Categories

Resources