This issue is coming up as I'm working on Devtools Responsive Design Mode bugs, specifically Bug 1504659. This is one of several issues with our viewports and with innerWidth/innerHeight which have nothing to do with Devtools or RDM. Here are the issues I've found:

1. Getters and setters for innerWidth/innerHeight currently use the visual viewport (nsIPresShell::GetVisualViewportSize) if it's been overridden, but will use the layout viewport (nsPresContext::GetVisibleArea) if the visual viewport hasn't been overridden. The spec says we should consistently use the visual viewport.
2. innerwidth/innerHeight is spec'ed to be the visual viewport plus scrollbar extents, but our getters and setters both ignore the scrollbars. Our tests only pass because of issue #1 and because most of the time the two viewports are the same.

(In reply to Xidorn Quan [:xidorn] UTC+11 from comment #0)

Should the viewport size be 16x5 or 17x6?

The visual viewport should be 16x5. innerWidth x innerHeight should be 17x6. Interestingly, there is no simple JS value for the visual viewport dimensions -- it's not documentElement.client{Width|Height} which is the layout viewport.

Because the fixes for this are layout-related, I'm going to take over this bug for these patches, and leave Bug 1504659 as an RDM-specific issue that is dependent on this bug.

(In reply to Brad Werth [:bradwerth] from comment #2)

The visual viewport should be 16x5. innerWidth x innerHeight should be 17x6. Interestingly, there is no simple JS value for the visual viewport dimensions -- it's not documentElement.client{Width|Height} which is the layout viewport.

Additionally, the layout viewport should be 17x6, and the vw and vh units should be based on that. We do this correctly today.

Bug 1514429 proposes that we match Blink behavior by making Window size properties like innerWidth and innerHeight based on layout viewport. If that happens, then our current behavior will be correct and this bug will only need to add tests for the vw / vh unit behavior with varying overflow values (which is currently correct for non-Responsive Design Mode cases).

(In reply to Brad Werth [:bradwerth] from comment #2)

1. Getters and setters for innerWidth/innerHeight currently use the visual viewport (nsIPresShell::GetVisualViewportSize) if it's been overridden, but will use the layout viewport (nsPresContext::GetVisibleArea) if the visual viewport hasn't been overridden. The spec says we should consistently use the visual viewport.

What spec are you referring to? As far as I'm aware, distinctions between the visual and layout viewport do not appear in any spec yet.

I'm only aware of this informal document that tries to describe the current practice, and which will hopefully form the basis of a future spec.

(In reply to Botond Ballo [:botond] from comment #5)

(In reply to Brad Werth [:bradwerth] from comment #2)

1. Getters and setters for innerWidth/innerHeight currently use the visual viewport (nsIPresShell::GetVisualViewportSize) if it's been overridden, but will use the layout viewport (nsPresContext::GetVisibleArea) if the visual viewport hasn't been overridden. The spec says we should consistently use the visual viewport.

What spec are you referring to? As far as I'm aware, distinctions between the visual and layout viewport do not appear in any spec yet.

I'm only aware of this informal document that tries to describe the current practice, and which will hopefully form the basis of a future spec.

You are correct. I was overstating the case. The spec refers only to the "viewport".

I'm not working in this area anymore. Taking myself off the bug to make it clear that somebody else can pick it up.