Open Bug 1209426 Opened 9 years ago Updated 2 years ago

Visual viewport should not include scrollbars, but innerWidth and innerHeight should

Categories

(Core :: Layout: Block and Inline, defect)

Product:
Core
Component:
Layout: Block and Inline
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox44 --- affected

People

(Reporter: xidorn, Unassigned)

References

Details

Attachments

(1 file)

testcase
(deleted), text/html
Details 
The question is, if we have a page like:

|<----- 16 ----->|1|
+----------------+-+ -
|                |^| ^
|                | | |
|                | | 5
|                | | |
|                |v| v
+----------------+-+ -
|<              >| | 1
+----------------+-+ -

Should the viewport size be 16x5 or 17x6? (The viewport size can be measured via the 'vw' and 'vh' units)

It's not quite clear to me which is correct. But it seems we have different behavior with other browsers anyway. Blink and Edge both use 17x6 for all cases. We use 17x6 when 'overflow' of :root is 'visible' or 'auto', but use 16x5 if 'overflow' is 'scroll'.

In addition to the interop issue above, if we dynamically change the 'overflow' value, the change to the viewport size won't take effect for us until the next resize reflow.
Attached file testcase (deleted) — 
This is a testcase for the reflow inconsistency issue.

The red border shows the viewport area derived from 'vw' 'vh' units. You can click the "Toggle Overflow" button, and then resize the window a bit to see the inconsistency.

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.

Assignee: nobody → bwerth
Summary: Viewport size sometimes does not count the viewport scrollbar area → Visual viewport should not include scrollbars, but innerWidth and innerHeight should

(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).

Depends on: 1514429

(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.

Assignee: bwerth → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: