How to handle changes in visual viewport between states

[jakearchibald]

For pinch-zoom differences, our options are:

• Abandon transition if zoom levels are different. Feels like this would drop too many transitions unexpectedly.
• Transition elements in visual viewport space. I think this would create some really weird transitions the developer wouldn't expect.
• Transition the visual viewport as part of the transition. I think this is my preferred option.

For differences caused by browser UI (scrollbars, URL bar, keyboard), I think our conclusion is to make the root image sizes match by extending the smaller dimensions with transparent pixels. This wouldn't impact shared elements, which may be a different size on either side of the transition due to UI differences. This seems like a good solution to me.

Related: #133

[khushalsagar]

Transition the visual viewport as part of the transition. I think this is my preferred option.

+1. Though we'll need to sort out the timing for this animation. For pinch-zoom we should animate the visual viewport likely once we're on the incoming page. As a step before running the SET animations. This is because the final page scale value is known only when the incoming page has loaded.

For the OS keyboard though, I'm not sure how dismissing the keyboard is timed with the navigation to the next page. It's also not clear whether this state is restored similar to page scale or a new navigation always dismisses the keyboard. In which case we could simply hide the keyboard before initiating the navigation.

In either case, I'm hoping we can start with making the change in visual viewport immediate instead of animating it. Since visual viewport bounds don't affect what we capture or how the SET animation is set up. It should be a separate animation orchestrated by the browser.