visual viewport behavior underdefined for detached windows and non-active documents about visual-viewport

[bzbarsky]

Also, is the viewport state really associated with the browsing context, as opposed to the window? That's pretty counterintuitive to me. Does the zoom state persist across navigations?

[bokand]

Hey - sorry for the delay - was on vacation and missed this when catching up.

Yeah, the confusion is a result of my very basic understanding of the relevant specs.

But in the spec windows don't have a browsing context set at all.

Rereading the spec, you're right, this isn't well formed. I think what I meant was rather: "If the window is currently in a Browsing Context's WindowProxy object's [[Window]] internal slot, return the object associated with it. Otherwise, return null". Does that make sense?

what happens if a script takes a reference to a VisualViewport and then the browsing context involved gets discarded?

The intent is that if the window isn't in a document that's currently being presented in a browsing context, as in this case, the visualViewport should return null.

what happens if there is no browsing context discarding, but the document of the Window the VisualViewport comes from stops being active

Chrome returns 0 for all values in that case which I think makes sense but is unspecified. I'll fix that.

Also, is the viewport state really associated with the browsing context, as opposed to the window? That's pretty counterintuitive to me. Does the zoom state persist across navigations?

Zoom does not persist across navigations so the state is associated with a window. I think the confusion here comes from the fact that the values only make sense for a visualViewport whose window is associated with an active document (one currently being presented).

Thanks for bringing up the issues. I'll make the relevant fixes in the spec.

[bzbarsky]

Does that make sense?

Yes, it does.

the visualViewport should return null

I think you misunderstood the question. The question is what happens if script asks a Window that is in a browsing context for its VisualViewport and then after that the window stops being in a browsing context. What is the behavior of the VisualViewport the script is already holding? Note that there are two sub-cases here: either the browsing context still exists but the window in question is no longer the one the WindowProxy is referencing, or the browsing context may have gotten discarded altogether.

Chrome returns 0 for all values in that case

OK. So the VisualViewport is really attached to the Window, not the browsing context, sounds like. Would be good to make that clearer.

[bokand]

The question is what happens if script asks a Window that is in a browsing context for its VisualViewport and then after that the window stops being in a browsing context.

Oops, yeah I did misunderstand. In both cases -- the window is not the one referenced by WindowProxy, or the browsing context is discarded -- the visualViewport object should return 0 for all values.

[bokand]

Put up a PR, mind looking it over for correctness?

[bzbarsky]

I can do that, but probably not until I get back from vacation at the end of the month, at this point.

[bokand]

No worries - I'll find someone else (or wait if I can't)

[theres-waldo]

There is one thing I'm still a bit unclear about. The algorithm specified for scale is:

1. If the window's associated Document is not fully active, return 0 and abort these steps.

2. If there is no output device, return 1 and abort these steps.

...

What steps can trigger the outcome from step 2 ("return 1 and abort these steps") of this algorithm?

[bokand]

I cargo-culted that line from the definition of devicePixelRatio so I'm not certain. My guess would be a headless mode that doesn't actually produce output?