WICG / navigation-api

The new navigation API provides a new interface for navigations and session history, with a focus on single-page application navigations.
https://html.spec.whatwg.org/multipage/nav-history-apis.html#navigation-api
484 stars 30 forks source link

Visual viewport handling (pinch-zoom) #244

Open jakearchibald opened 2 years ago

jakearchibald commented 2 years ago

With MPA cross-document push/replace, Chrome (at least) seems to reset pinch-zoom, which seems to make sense as it could otherwise leave the user looking at something incomplete/confusing.

Should the Navigation API do the same with default scroll handling?

In Chrome (at least), reloads preserve pinch-zooming. It seems like it tries to preserve pinch-zoom on traversal. It works well with bfcache traversals, but for cross-document traversals it seems buggy (the zoom level seems the same but the viewport is in the wrong place).

I guess whether the Navigation API should restore pinch-zoom would depend on whether it should be spec'd for regular navigations.

tbondwilkinson commented 2 years ago

If the scroll is being reset, I think it makes sense for the pinch-zoom to be reset as well.

Should this be just tied to scroll or are you thinking of proposing another option to the API to control pinch-zoom reset separately?

jakearchibald commented 2 years ago

Tying it to scroll would be my preference. I'm not sure when you'd want one but not the other.

domenic commented 2 years ago

It looks like the spec concept is https://wicg.github.io/visual-viewport/#definition-of-the-visual-viewport . Indeed it's not specced how this interacts with navigations. But I think it's quite observable, given the existence of the visual viewport API or just some of the stuff mentioned in https://wicg.github.io/visual-viewport/#intro about scrollLeft vs. clientWidth. I guess it's not really web-platform-testable though, sadly.

We should probably file a Chrome bug to make Chrome change this as part of scroll soon-ish, so that changing it later isn't a breaking change. And maybe we should throw something non-normative into the navigation API spec discussing this so that others can interoperably follow. Then we can work on the larger project of speccing the interaction of visual viewport with navigations.

bokand commented 2 years ago

Tying it to scroll would be my preference. I'm not sure when you'd want one but not the other.

+1

It looks like the spec concept is https://wicg.github.io/visual-viewport/#definition-of-the-visual-viewport

Just FYI this recently got moved into CSSOM-View so references and changes should target that going forward.

I guess it's not really web-platform-testable though, sadly.

I think it should be? (mostly). The missing piece is reliably changing the page scale from a web platform test - Chrome's test driver implementation does allow pinch-zooming in a WPT by simulating a pinch using two touch pointers. I've used this in a few recents WPTs (example)

Sadly this doesn't work in Safari (which doesn't support touch on desktop) or Firefox (which doesn't implement touch pointers, bug)

domenic commented 2 years ago

Heh, I see, that uses testdriver to actually literally pinch-zooms. Seems pretty good then, I think!