2014986 - Regression in view-transition element capture

Status: VERIFIED FIXED

(Core :: CSS Transitions and Animations, defect, P3)

Description

[Jake Archibald [:jakea]]

Attachment: Demo of issue

https://deploy-preview-25--wordle-analyzer.netlify.app/ - this is a version of https://wordle-analyzer.com/ with the transitions 100x slower.

Enter two words, eg "soare" and "crane", and hit "analyze".

In nightly, the timing of the capture seems incorrect, and it means the coloured versions of the squares isn't being captured along with their outlined versions.

Sorry, that description sucks. See the video.

Comment 1

[Emilio Cobos Álvarez [:emilio]]

With mozregression --good 147 -a https://wordle-analyzer.com/ I get: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=f0508bdfdcef4a7f203806f510d1fa084224aedb&tochange=4dc50e8367a1d9082bc8f8fa8296481ec97a2ba4

I tested with the "fast" site so I'd appreciate a double-check. But it's not impossible if we were not reconstructing before and now we are, somehow.

Comment 2

[Jake Archibald [:jakea]]

https://github.com/jakearchibald/wordle-analyzer/blob/main/src/client/App/lazy-app/transitions.ts here's the code for the transition. I've also disabled minification on https://deploy-preview-25--wordle-analyzer.netlify.app/.

Comment 3

[Jake Archibald [:jakea]]

I got the same commit with mozregression.

Comment 4

[Emilio Cobos Álvarez [:emilio]]

Yeah, I can confirm it's caused by that patch. Here's what's going on if you're curious. You have the following DOM:

div@0x7f7be5912ca0 data-index="0" class="_cell_19dwp_10 _correct_19dwp_30 _has-char_19dwp_26" style="grid-column: 1; view-transition-name: guess-cell-0-0;" state=[100820000] flags=[00002000] selectorflags=[00000000] primaryframe=0x7f7be5abd288 refcount=9<
  Text@0x7f7be5906800 flags=[00030000] primaryframe=0x7f7be5ad2230 refcount=3<a>
  span@0x7f7be5920670 class="_sr_6gixq_1" state=[100820000] flags=[00000000] selectorflags=[00000000] primaryframe=(nil) refcount=6<
    Text@0x7f7be5906a80 flags=[00000000] primaryframe=(nil) refcount=2<(>
    Text@0x7f7be5906b00 flags=[00000000] primaryframe=(nil) refcount=2<correct>
    Text@0x7f7be5906b80 flags=[00000000] primaryframe=(nil) refcount=2<)>
  >
>

Where the <span> is display: none and gets dynamically switched to display: block (or something block-outside at least).

The issue is that the "a" text node is wrapped into an anonymous flex item. Before my patch, we computed the insertion point as the parent grid container, which in this case is right. Now we compute it as the child's anon block, and end up reconstructing the whole cell, which loses the capture...

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 2008148

Comment 6

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 2014986 - Improve prev sibling computation for flex / grid containers. r=#layout!

The situation this patch deals with is when you have the following frame
tree structure:

ns{Flex,Grid}ContainerFrame
::-moz-anonymous-item
Some text

And you append something after "Some text".

Before the regressing bug, we ended up in different codepaths for
insertion and append: Append always ended with the grid container as a
parent (and the anonymous item as a prev sibling), while insert ended
with the current nightly behavior of choosing the text frame as a
sibling, and the anonymous item as a parent.

WipeContainingBlock has code to deal with the wrong choice, but that
forces the container to be reconstructed, which is inefficient and in
cases like this one has correctness implications (because we store the
"view transition live capture bit" on the frame). I filed bug 2015007
for that since that's technically wrong too.

This is the relatively-minimal upliftable fix to minimize reframes in
both cases, which of course fixes the regression. I think it might be
worth looking into whether we can make the right decision later in the
pipeline (e.g., making WipeContainingBlock override the insertion parent
rather than bailing out). But that seems riskier.

Add a test for the different cases here.

Comment 7

[Emilio Cobos Álvarez [:emilio]]

[Tracking Requested - why for this release]: regression that would be nice not to ship

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/222f8d185a7f
https://hg.mozilla.org/integration/autoland/rev/725cc2f52fec
Improve prev sibling computation for flex / grid containers. r=jwatt

Comment 9

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/725cc2f52fec

Comment 10

[Donal Meehan [:dmeehan]]

:emilio, please add a beta uplift request when you have a moment

Comment 11

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined: Regression which would be nice not to ship.
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: comment 0
• Risk associated with taking this patch: low
• Explanation of risk level: Targetted fix
• String changes made/needed: none
• Is Android affected?: yes

Comment 12

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 2014986 - Improve prev sibling computation for flex / grid containers.

The situation this patch deals with is when you have the following frame
tree structure:

ns{Flex,Grid}ContainerFrame
::-moz-anonymous-item
Some text

And you append something after "Some text".

Before the regressing bug, we ended up in different codepaths for
insertion and append: Append always ended with the grid container as a
parent (and the anonymous item as a prev sibling), while insert ended
with the current nightly behavior of choosing the text frame as a
sibling, and the anonymous item as a parent.

WipeContainingBlock has code to deal with the wrong choice, but that
forces the container to be reconstructed, which is inefficient and in
cases like this one has correctness implications (because we store the
"view transition live capture bit" on the frame). I filed bug 2015007
for that since that's technically wrong too.

This is the relatively-minimal upliftable fix to minimize reframes in
both cases, which of course fixes the regression. I think it might be
worth looking into whether we can make the right decision later in the
pipeline (e.g., making WipeContainingBlock override the insertion parent
rather than bailing out). But that seems riskier.

Add a test for the different cases here.

Original Revision: https://phabricator.services.mozilla.com/D282161

Comment 13

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/bf7a235a8ec9
https://hg.mozilla.org/releases/mozilla-beta/rev/922decb19c5b

Comment 14

[Ina Popescu, Desktop QA]

I was able to reproduce the issue in Nightly 149.0a1 (2026-02-06) on macOS 15. Verified as fixed in the latest Nightly 149.0a1 (2026-02-09) and in Firefox 148.0b13 on macOS 15, Ubuntu 22.04 and Windows 10 where the issue is no longer present. Updating the flags accordingly.