Should window.scrollTo() preserve visualViewport.offset{Left,Top}? about visual-viewport

[bokand]

Making window.scrollTo affect only the layout viewport was intentional, see crbug.com/489206 for more details.

The basic problem is this: it's quite common on the web to use window.scrollX|Y in combination with Element.getBoundingClientRect. We saw a long tail of bugs of pages not working correctly when pinch-zoomed because the latter was relative to the layout viewport but window.scrollX|Y were (initially) visual-relative (e.g. popup menus on Facebook would be mispositioned). We decided to make the window APIs also layout-relative to solve these kinds of issues and make the platform consistent (and introduced visualViewport for cases that explicitly wanted it).

This was a bit of a scary/controversial change but IMHO it went smoother than expected. I expected it to fix more bugs than it introduced but I haven't seen any real bugs caused by it and, in retrospect, I think it was the right decision.

Regarding window.scrollTo, it'd be really strange/surprising if it didn't match scrollX|Y. I think Element.scrollIntoView is different because it's an explicit signal that the page wants to bring something into view; scrollTo is a bit more ambiguous.

[theres-waldo]

To be clear, window.scrollX|Y already reports the layout viewport offset in Firefox (since Firefox 63), and window.scrollTo()'s primary effect is to move the layout viewport as well.

However, window.scrollTo() has to do something with the visual viewport offset as well -- it can't leave it alone in general, since it needs to obey the constraint that the visual viewport is contained within the layout viewport. (So, if the layout and visual viewport offsets are initially (0,0) (in absolute / page-relative terms), and you do window.scrollTo(1000, 1000), and the layout viewport size is (200, 200), the call can't leave the visual viewport offset at (0, 0)).

My question is, why is preserving the relative offset between the two viewports the right / intuitive behaviour, as opposed to a different choice, such as changing the visual viewport offset by the minimum possible amount to still obey the constraint, or collapsing the relative offset to zero (as Firefox currently does)?

[bokand]

Ah, I see what you mean.

The short answer is this is probably a bias of our implementation that these viewports are effectively implemented as nested scrollers so you'd have to do extra work to not preserve the relative offset.

I think "minimum possible amount to still obey the constraint" would be bad UX because short scrolls that don't clamp the visual viewport wouldn't be seen at all which would be quite surprising. The visible effect of a scroll would depend on where the visual viewport started.

The "collapse to zero" choice seems reasonable. It has the advantage of always putting the user where the author intended the layout viewport to go (assuming they're scrolling the target to the top-left though and not, e.g., centering it).

OTOH, it could lead to annoying scenarios: imagine a user zooms in on a narrow column of text in the middle of the page. Any scrollTo now will reset the location off the column. Or if a page tries to lock the scroll offset by repeatedly calling scrollTo (I've seen this), the user can't zoom in and pan around.

But, TBH, I don't think we gave it a ton of thought. We just did the simple and unsurprising (to us) thing. The mental model here is that the visual viewport is just a magnifying glass taken the to user's screen; anything that happens on the screen shouldn't affect the magnifying glass. User can always zoom out and recenter if the page went to an unexpected place.

If there's compelling reasons we could consider changing it but it hasn't been an issue and it's worked quite well in my mind.

[theres-waldo]

Thanks!

Do I understand correctly then that Chrome's behaviour is that window.scrollTo() preserves the relative offset in general? (I ask because the comment quoted in the issue description makes it sound like this may be conditional on something.)

[bokand]

Yeah, that's correct, scrollTo never changes the relative offset. The comment could be clearer. *From: *Botond Ballo <[email protected]> *Date: *Fri, May 10, 2019, 2:28 PM *To: *WICG/visual-viewport *Cc: *David Bokan, Mention Thanks!

…

Do I understand correctly then that Chrome's behaviour is that window.scrollTo() preserves the relative offset in general? (I ask because the comment quoted in the issue description makes it sound like this may be conditional on something.) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#61 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC2KWAKNDTXK7E3ZHWSZ6PDPUW5DVANCNFSM4HLWBEOQ> .

[theres-waldo]

Ok, thanks for clarifying!

I agree that this is a reasonable behaviour, and I will explore getting Firefox to do the same. Historically this has been a tricky area to fiddle with, but we can give it a try!

[theres-waldo]

Forgot to close the loop here: the behaviour of preserving the relative offset has been implemented and shipping since Firefox 81, and we haven't noticed any compat issues from it.