We Keep Coding

Detecting VH on mobile in js and returning it's current value

My issue is a hack for a dubious mobile browser discrepancy between the 100vh and the area hidden behind the mobile browser bars. This is a problem for any page where a full screen effect is desired.
The hack detects the difference between the VH and the actual visible viewport. However the simple js in the first code example appears to be detecting it backwards. So if the browser bar is overlaid the value should be 75 but is instead 0 -- likewise when the the browser is large it should return 0 but instead returns -75.
This can be reproduced simply by testing an iPhone with the 'develop' tool in Safari on google.com and entering this in the console.
document.documentElement.clientHeight - window.innerHeight
This seems to compute the shorter browser height with the top offset to compensate for the browser bar as being offset by 0 and the tall browser height where the browser bar is no longer covering the top of the page at -75px. This, to me, appears to be very wrong and should be 75 and 0 respectively. The below example is how I think it should work to properly offset the body tag to position elements with absolute positioning.
function fixIt(){
var offset = (document.documentElement.clientHeight - window.innerHeight);
document.body.style.marginTop = offset;
}
fixIt(); // run on resize
My extra super hacky solution it to offset the body by 75px by default and to assign the old value on vertical resize. (so when the browser bars hide, instead of 75px offset, use previous offset of 0 and save the 75px offset for the next resize). The works in Mobile Chrome and Mobile Safari, but for instance, if the link is opened in facebook where there is no browser bar and no resize events, it is offset by 75px permanently. This code is obviously insane and should be banished into the nothing.
var offset;
var oldOffset = 75px;
function fixIt(oldOffset){
offset = (document.documentElement.clientHeight - window.innerHeight);
document.body.style.marginTop = oldOffset;
oldOffset = offset;
return oldOffset;
}
fixIt(oldOffset); // run on resize
As an aside, or for further reading, here's a big complaint blog on the issue. https://nicolas-hoizey.com/2015/02/viewport-height-is-taller-than-the-visible-part-of-the-document-in-some-mobile-browsers.html I agree with the browser vendors that VH should be constant (because the reflow would be obnoxious for everything besides the actual body height) but for the top level elements like body and html tags on mobile this behavior appears to be wrong and it makes no semantic sense, plus these computed numbers appear backwards, further making this issue headache inducing.
What other solutions are out there?

Get Android Chrome Browser Address bar height in JS

How do I get the height of the address bar in JavaScript in the Chrome browser for Android (marked by red rectangle in left picture)? I need to know that as it disappears while scrolling down and I need to react to that because the viewport height is different then.
One solution I already figured out:
Get viewport height at initial state:
var height = Math.max(document.documentElement.clientHeight, window.innerHeight || 0);
Get viewport height when the address bar has disappeared
Compute difference between both values
Problem is that you have to be in the second state to know that.

Because 100vh will be larger than the visible height when the URL bar is shown. According to this.
You can calculate the height of the URL bar by creating a 0-width element with 100vh height.
<div id="control-height"></div>
#control-height {
height: 100vh;
width: 0;
position: absolute;
}
Then using javascript compare window.innerHeight with the height of this element.
const actualHeight = window.innerHeight;
const elementHeight = document.querySelector('#control-height').clientHeight;
const barHeight = elementHeight - actualHeight;

The thing you're are looking for is url bar resizing. Since Android's chrome v56, it's recommended by David Bokan to use vh unit on mobile. There is a demo in that article, clicks the link to get more informations and how to use it on mobile.
When the user is scrolling down the page, a window.resize event is throwed.
You could update your page by catching this event with an event listener.
More informations : mobile chrome fires resize event on scroll

Best approach for me was to have something like that:
$(document).ready(function(){
var viewportHeight = Math.max(document.documentElement.clientHeight, window.innerHeight || 0);
var viewportWidth = Math.max(document.documentElement.clientWidth, window.innerWidth || 0);
var isPortrait = viewportHeight > viewportWidth;
$( window ).resize(onresize);
function onresize() {
var newViewportHeight = Math.max(document.documentElement.clientHeight, window.innerHeight || 0);
var newViewportWidth = Math.max(document.documentElement.clientWidth, window.innerWidth || 0);
var hasOrientationChanged = (newViewportHeight > newViewportWidth) != isPortrait;
var addressbarHeight = 130;
if (!hasOrientationChanged && (newViewportHeight != viewportHeight)) {
addressbarHeight = Math.abs(newViewportHeight - viewportHeight);
if (newViewportHeight < viewportHeight) {
// Android Chrome address bar has appeared
} else {
// Android Chrome address bar has disappeared
}
} else if(hasOrientationChanged) {
// Orientation change
}
viewportHeight = newViewportHeight;
viewportWidth = newViewportWidth;
isPortrait = viewportHeight > viewportWidth;
}
});

Had the same issue today, turns out there is no easy way to figure out the height of the url bar directly. As far as I know, none of the directly accessible variables in javascript can tell you how much the size of "100vh" really is.
On mobile browsers, 100vh may or may not include the height of the url bar, which leaves us in a tricky situation, if we want to size a div to the exact height of the visible content area of the browser during load.
I figured out a workaround though that worked pretty neat for me, here's what I did:
add a dummy property on your html root element with a size of 100vh. In my case, i used the "perspective" attribute, which worked for me
then you can get the address bar size with the following code:
var addressBarSize = parseFloat(getComputedStyle(document.documentElement).perspective) - document.documentElement.clientHeight

I had a container with dynamic content that had to always have at least viewport's full height (and be scrollable if the content doesnt fit on the screen).
So if you need a fixed height, just replace "min-height" with "height" in my solution.
That's how I dealt with it.
// calculate min-height on init
$(".content-container").css("min-height", `${window.innerHeight}px`);
// recalculate the min-height everytime the bar appears or disappears
$(window).resize(() => {
$(".content-container").css("min-height", `${window.innerHeight}px`);
});
It works for android's address bar and also safari's bars (in safari mobile there can be top and the bottom bar aswell).
Then to make the transition smooth, you can apply a css rule:
.content-container{
transition: min-height 500ms ease;
}

Whether element is behind inner nested scroll

How to detect if an element inside a scrollable block is visible to user (i.e. is in the visible area of the scrollable parent)?
Is there a universal solution, not involving iterating over all parent nodes that have scroll?
P.S. One idea I had was getElementAtPoint, however it gives me headaches when I need to determine if at least 50% of the element is visible. So ideally the solution must involve collision detection between two rectangles: the element rectangle and the window.
P.P.S. Another idea I've come up with is to use scrollIntoView on the element in question, determine the difference in its position, and then scroll it back to original position. It appears scrollIntoView always does the right thing – scrolls both window and the inner scrollable blocks!

I'm afraid this can't be done without iterating, and even less cross-browser, with some simple code.
Here's an example, how this can be done in IE. Unfortenately other browsers seem to return different values from body/html.getBoundingClientRect(). Also margins are treated differently, (IE ignores, others take them account).
getVisibilityPercent = function () {
var target = document.getElementById('target'),
height = target.offsetHeight,
parent = target.parentElement,
targetRect = target.getBoundingClientRect(),
tLim, bLim,
percent = 1;
while (parent) {
parentRect = parent.getBoundingClientRect();
tLim = Math.max(targetRect.top, parentRect.top);
bLim = Math.min(targetRect.bottom, parentRect.bottom);
percent *= (bLim - tLim) / height;
percent = (percent < 0) ? 0 : percent;
parent = parent.parentElement;
}
return +((percent * 100).toFixed(2));
};

Get screen coordinates of DOM element

Can I somehow get precise screen coordinates (relative to top left corner of the screen) of a DOM object. Through NPAPI\FireBreath or JavaScript. (Need this for plugin, that I'm writing
with FireBreath)

P.S.: I know I made this question long ago, but I want to summarize what I got at the end.
element.offsetLeft\Top doesn't work truly the way it meant to be in question.
From the HTML you can get coords, relative to top-left corner of page's space, not the user screen itself.
And from plugin, by GetWindowRect() winAPI function you can get coordinates of top-left corner of the browser window, relative to user screen, and by GetClientRect() you can get coords of the top left corner of Client rectangle.
BUT, it isn't the same point as top-left of page, there is always something between corner of page's space, and client rect, or window rect. It includes top browser bars and other stuff.
What you can do? It seems that there is no easy 100% controllable way:
You can try to consider those browser bars and calculate the space between Client rect and page's rectangle, but those browser bars not constant from user to user, one can have more of them, that another, and you will get all your coordinate system screwed up. Then, you can somehow register the amount of installed bars and additions to browser, and according to that calculate amount of space, that will be consumed by them, but bars and additions not the same, and again you got way too much variables to consider.
There is a bit easier way, you can go not from top, but from the bottom - get the coord's of bottom point of rect and through some calculations with HTML's element.offset - bind your coordinate system to bottom-left point of the window.
You got no user browser bars at the bottom, and therefore can be a little more confident in space between page and window corner, but some browsers got pop-up bars there with download information e.t.c, and here we got everything screwed up again.
Another option is to use modal window's - i.e. open the page in modal window through window.open() from your JavaScript, you can control amount of browser controls and bars in those windows, you can get rid of all those userbars and make a clear window only with address bar and the page. Now you got much more control, and can almost be sure, that this space between corners will be the same for all your users... almost.
There is two things need to be mentioned:
1)Some browsers (for example google chrome, as I remember) got those custom browser additions (Firebug for example) to appear as small icons near address bar, and they are still appearing near the address bar of the modal window.
What the difference you can ask - the difference is, that, for some reason, top of the browser window will became around 5 pixels fatter, if there's even one of those icons.(again you can try to register, are there any of those installed on user browser, or not)
And if, anyway, those 5px not crucial for you - it can be a way to go.. if you're ok with the next thing.
2)Obvious one - that fun with modal windows can be uncomfortable for end-user, cos it cuts some browser controls and mechanics that browser users get used to.

I know you didn't mention jQuery, but you can use http://api.jquery.com/offset/ as an example. It combines the offsetLeft/top of all the parents and accounts for scrolling, giving you an accurate x,y (in relation to the body) for nested nodes.
Note that if you're handling events, the event object always tells you where the event happened using http://api.jquery.com/event.pageX/ and http://api.jquery.com/event.pageY/
Again, mentioning jQuery is for inspiration only if you don't want to use it.
Here's how jQuery does it
$.fn.offset = function (options) {
var elem = this[0],
doc = elem && elem.ownerDocument;
if (!doc) {
return null;
}
if (elem === doc.body) {
return jQuery.offset.bodyOffset(elem);
}
return getOffset(elem, doc, doc.documentElement);
}
function getOffset(elem, doc, docElem, box) {
try {
box = elem.getBoundingClientRect();
} catch(e) {}
// Make sure we're not dealing with a disconnected DOM node
if (!box || !jQuery.contains(docElem, elem)) {
return box ? {
top: box.top,
left: box.left
} : {
top: 0,
left: 0
};
}
var body = doc.body,
win = getWindow(doc),
clientTop = docElem.clientTop || body.clientTop || 0,
clientLeft = docElem.clientLeft || body.clientLeft || 0,
scrollTop = win.pageYOffset || jQuery.support.boxModel && docElem.scrollTop || body.scrollTop,
scrollLeft = win.pageXOffset || jQuery.support.boxModel && docElem.scrollLeft || body.scrollLeft,
top = box.top + scrollTop - clientTop,
left = box.left + scrollLeft - clientLeft;
return {
top: top,
left: left
};
}

you move cursor to somewhere of the page ,and make a click event.(find the window,then GetWindowRect ,caculate a sutable position) then you can catch the event,record clientX and clientY. By this ,you build a bridge between two different coordinate system.

How to find (in javascript) the current "scroll" offset in mobile safari / iphone

I'd like to know the x/y offset of the how far the user has "scrolled" within the viewport in mobile safari on the iphone.
Put another way, if I (through javascript) reloaded the current page, I'd like to find the values I'd need to pass into window.scrollTo(...) in order to reposition the document/viewport as it is currently.
window.pageXOffset always reports 0
jquery's $('body').scrollTop() always reports 0
events have a pageX, but this won't account for the scrolling of the page that happens after you release your finger if your gesture was to "flick" the page up/down. Namely, it'll give me a point when the finger leaves the screen, but that doesn't always match where the page will be after it's finished scrolling.
Any pointers?

window.pageYOffset should give you the current scroll offset. There's window.pageXOffset if you need it too.

I had the same problem... this did the trick:
var scrollX = window.pageXOffset; var scrollY = window.pageYOffset;
Got it from this question: Get current position of the viewport in Mobile (iPhone) Safari

This will indeed work:
var scrollX = window.pageXOffset;
var scrollY = window.pageYOffset;
If you are viewing content in an iFrame (which is common in WebViews for instance), then you will need to add parent:
var scrollX = parent.window.pageXOffset;
Also note that these values are not writeable. So to change the scroll position, you will need to use window.scrollTo method:
var scrollX = window.pageXOffset;
var scrollY = window.pageYOffset;
window.scrollTo(scrollX -100, scrollY -100);

Have you tried the pure js way?
document.body.scrollTop

Here is a simple code to find if the device is iphone and also to change the scroll position to specific position based on some action. I had an issue with iphone only when I click and open an image as a popup, because vertical scroll goes down than where I wanted to be. So I wrote this code and it solved the issue.
if((navigator.userAgent.match(/iPhone|iPad|iPod/i))){
('#tutorial-landlord').click(function(){
window.scroll(100, 1500); // x, y (horizontal, vertical position)
});
}
To find the scroll position. Just go to console in chrome and write
window.scrollY for vertical and see how the position changes so note that number and give it in place of x and y

I had the same issue on iPad. Just desactivate the console. The viewport height changes when the console is open in Safari.

If for whatever reason pageXOffset and pageYOffset fail, the solution is straightforward, but rather silly:
// force an element to top left of the page
var topLeftMarker = document.createElement("span");
topLeftMarker.style.position = "absolute";
topLeftMarker.style.left = "0";
topLeftMarker.style.top = "0";
document.body.appendChild(topLeftMarker)
function scrollOffset() {
// getBoundingClientRect() returns the rectangle of the element in viewport space,
// which *is* scrollLeft and scrollTop
const rect = topLeftMarker.getBoundingClientRect();
return { x: rect.left, y: rect.top }
}