Develop Reference

Detect if the viewport width is bigger than the visible width on Mobile Safari using javascript

I have an element with position fixed (pinned to any corner) on a page (which I do not necessarily have control over the meta viewport tag - it is an embedded widget for third party sites). On Mobile Safari when the user pinch zooms the page at a certain point the viewport becomes larger than the visible area. At that point the fixed position element stays attached to the viewport and is not necessarily in the visible area.
I would like to compare two widths: the width of the visible area and the width of the viewport. I believe the size of the visible area is window.innerWidth. I am not sure how to measure the viewport.
I have been trying to see the relationships between:
document.documentElement.clientWidth
screen.width
window.innerWidth
window.outerWidth
...But have not been able to see anything obvious.

This is butt ugly but it does show some code that almost works (view on iOS to see it working. Use a desktop and click edit at top right of page to see or edit code):
https://jsbin.com/jopamu (iOS only)
The trick with the "overzoom" calculation is nasty but it does compensate somewhat for the multiple viewport zooms. It is a complex problem to solve because there are competing issues:
pinch-zoom
zoom due to input focus
the "position:fixed" zoom
potentially the OS (accessibility) zoom
The possible solutions I have found are:
Position the menu using the calculations above and position:absolute - updating the left/top in onscroll event. Has ugly juddering (can improve a little by hiding and only showing when zooming/scrolling finishes).
Position the menu using position:fixed but change the left/top to correct the menu position as zooming/scrolling occurs. Much less judder but I couldn't quite get it 100% reliable (some race condition).
Not suitable for your case (and highly unrecommended due to risk of breaking things): you can prevent pinch zooming and iOS10 double-click zooming by cancelling default on touchstart. Difficult because it needs many other workarounds so normal touch works, and needs synthetic scrolling and zooming (but has ugly side effects such as preventing scrolling working sometimes and also interferes with accessability e.g. if voice accessability turned on etc etc).
If you just want to see the widths then use the older version:https://output.jsbin.com/jopamu/6

Reset browser zoom level when a page change

I have a mobile site that loads pages with ajax. One of the features I would like to add is to reset the zoom level when a page changes.
Is there a good method to detect if a user zoomed the view while viewing a page?
Until now I've managed to do the check for pinch zoom. But sometimes there is double tap zooming too ..

You can get the users zoom level by comparing the innerWidth and document width. Document width is the width of the device in pixels, inner width is the pixels which are on screen when zoomed (in relation to what the document width initially was). I have tested this on android (ICS and Jellybean), and iOS (5 and 6) and it seems to work. Note, I do not have my viewport set to device width or height
ratio = document.width / window.innerWidth
if ratio > 1 then zommed else notZoomed
Then you can do this check whenever a user makes a double tap or a pinch.

you can set the contents of the [meta name="viewport"] tag using javascript to set the zoom level, unfortunately i haven't found a way to detect what the current zoom level is

Document width calculated via Javascript is different in Firefox compared to other browsers

I have a problem with retrieving the current page document width from Mozilla Firefox. While the rest of the browsers report the correct width of the document, Firefox reports a smaller one (example: at screen resolution of 1920x1080 IE, Chrome and Safari reports 1920 while Firefox reports 1903).
I use document width in $(document).ready(function() { ... }); to reposition a div element. Funny this is that after using alert() inside this function, the element reposition correctly, though the document size is still smaller than other browsers.

As Salman already noted in the comments, this difference comes from the scroll bar. Depending on the browser (and probably also on whether quirks mode is enabled), the scrollbar might be considered "outside" the document (in which case its width won't be added to the document width) or part of the <html> element (then its width will be added to the document width). So document.documentElement.offsetWidth will return inconsistent results - sometimes with the scrollbar, sometimes without it. document.body.offsetWidth on the other hand seems consistent across browsers - scrollbar width isn't included.
If what you want to learn is viewport width, regardless of the contents, then window.innerWidth might be a better choice. I tested in Firefox, Chrome and MSIE 9.0 - it returns the full screen width for maximized windows in all of them.

Determining the bounding rectangle of Mozilla 4's content region

In versions of Firefox prior to 4, the web content was contained in a window of class "MozillaContentWindowClass". In the newer versions, the entire window is content-based, including toolbars, etc. Can anyone suggest the necessary Javascript code to determine the bounding rectangle (or at the very least the vertical offset) of the web content?

getBrowser().selectedBrowser.getBoundingClientRect()

window.innerHeight will give you the height of the viewport including the horizontal scrollbar (if any).

Javascript Window.Open Dimensions

I'm opening a new window from javascript using this code
window.open('index.htm', 'myWindow', 'width=1020,height=400');
However the window seems to be opening 10px too wide when measuring from outter border to outer border, I've only tested this on IE7 and IE8 so far. Does anyone know what could be causing this?

See the IE Blog for details on how Microsoft changed their window dimensions in IE7 (and beyond)
IE Blog: Why Does IE Resize My Dialogs?
Quotes:
IE6 gives web developers control over the frame size of dialogs (also known as the ‘chrome’). The frame includes visual elements such as the title bar, status bar, borders, etc. This is a problem for web developers because the dialog’s frame size varies according to whatever windows theme is applied (this is bad)...
In Windows XP Service Pack 2, IE’s security improvements added window restrictions that forced the status bar onto windows and dialogs (in certain security zones); developers adapted by subtracting the height of the status bar from their dialogs...
Before the guesswork for sizing the content area gets any worse for developers, we felt it was time to set things right by focusing on delivering HTML content area instead of total frame size.
Here’s how we changed it. In IE7, the meaning of window.dialogHeight and dialogWidth now refers to the content area. Essentially, the area (height/width) that you specify is what we try to deliver in the content area of the dialog (barring window restrictions on scriptable minimum sizes: 250px wide x 150px high*). It will no longer be necessary to calculate the area lost by components of a dialog’s frame.
Figure 3

window.onload=setTimeout(function(){window.open('http://www.w3schools.com', 'myWindow', 'width=920,height=400');},1000);