Bug 285400 – [view-transitions] ::view-transition-group() animations are not using the Snapshot Containing Block

• Component: Layout and Rendering
• Status: NEW

[Bramus]

Created attachment 473780 [details]
iOS Simulator Screenshot

When inspecting the keyframes generated for ::view-transition-group() pseudos, it seems like they are not using the Snapshot Containing Block.

See the attached screenshot where Safari is set to Single Tab mode. The top position of the box (`24px`, derived from the `matrix` property) is measured against the Viewport, not the [Snapshot Containing Block](https://drafts.csswg.org/css-view-transitions-1/#snapshot-containing-block-concept).

The demo used is https://cdpn.io/pen/debug/NPKgvMY, which dumps the keyframes.

(Note that the `from` keyframe is entirely wrong. This is tracked in https://bugs.webkit.org/show_bug.cgi?id=285277)

[Bramus]

Or does WebKit compute the x,y against the Snapshot Containing Block and then converts them to values relative to the (new) Viewport?

[Bramus]

Here’s a demo that makes it easier to verify/reproduce: https://cdpn.io/pen/debug/ByBJVwp

It animates the box to the top-left corner and back to the center upon tapping, instead of randomly setting the alignments.

Steps to reproduce:

0. **Make sure Safari is set to Single Tab mode**

1. Open https://cdpn.io/pen/debug/ByBJVwp in Safari on iOS
2. Tap the document to animate the box to the top-left corner
3. Note the `ty` value used in the `transform` from the logged `toKeyframe`

4. Open https://cdpn.io/pen/debug/ByBJVwp in Safari on iOS
5. Scroll down
6. Tap the document to animate the box to the top-left corner
7. Note the `ty` value used in the `transform` from the logged `toKeyframe`

Expected Results:
- The values noted in steps 3 and 7 should **not** be the same.

Actual Results:
- The logged values are the same

[Tim Nguyen (:ntim)]

We don't currently implement the snapshot containing block, I hadn't prioritized it, given the default on iOS is the bottom navigation bar, where it makes less difference.


It does make more difference in single-tab mode and Android though where there is a collapsible navigation bar on top of the screen, so we should definitely address this at some point.

[Bramus]

Thanks for confirming. Here’s another demo – this time MPA – that might help while implementing things: https://cdpn.io/pen/debug/ZYzvjZb.
You click the link shown at the top right to navigate to the next page, upon which the box moves using a View Transition.

When having scrolled down first – even in Tab Bar Mode – you can see that the start position of the `::view-transition-group(box)` is off.

(For reference: Chrome on Android re-shows the address bar before starting the transition, circumventing this situation altogether)

[Bramus]

Created attachment 473824 [details]
Recording of https://cdpn.io/pen/debug/ZYzvjZb

[Radar WebKit Bug Importer]

<rdar://problem/142774967>

[Matt Woodrow]

I'm doing some preparation work for this in bug 292970, which introduces the snapshot containing block conceptually.

The work in this bug will be to detect the cases where the size/position of this is different from the view, and use those.

[Matt Woodrow]

Pull request: https://github.com/WebKit/WebKit/pull/46108

[Matt Woodrow]

Thanks for all the detailed test cases!

PR seems to fix all the reported issues as far as I can tell with manual testing.

[Bramus]

I see the mentioned PR is still open. Is there an update on this?