LayoutAnimations: Fix out-of-order DELETE and REMOVE instruction generation

Summary:
In very marginal cases, it was possible to set up an animation of the following diffing instructions:

```
REMOVE X from parent Y
DELETE X
```

If your LayoutAnimation configuration had no "delete" config, the DELETE would be executed immediately; the REMOVE was erroneously being categorized as an "update" (now fixed)
which caused the REMOVE to be delayed, but then executed very shortly thereafter. So the order of instructions would become:

```
DELETE X
REMOVE X from parent Y
```

which would crash (or at least fail an assertion) when the REMOVE instruction was processed.

This fixes the issue by ensuring that REMOVEs have a corresponding "delete" config, or they are also executed immediately; unless followed by an INSERT (and any combination of `REMOVE, DELETE, INSERT` in the same frame is not possible).

Changelog: [Internal]

Reviewed By: sammy-SC

Differential Revision: D25292560

fbshipit-source-id: 7ffdd6cbcb43126de07a70c197dfaf1ebff83555
This commit is contained in:
Joshua Gross
2020-12-03 17:09:51 -08:00
committed by Facebook GitHub Bot
parent 7008ffb663
commit 50dde4b7b7
@@ -914,7 +914,9 @@ LayoutAnimationKeyFrameManager::pullTransaction(
}
auto const &mutationConfig =
(mutation.type == ShadowViewMutation::Type::Delete
(mutation.type == ShadowViewMutation::Type::Delete ||
(mutation.type == ShadowViewMutation::Type::Remove &&
!wasInsertedTagRemoved)
? layoutAnimationConfig.deleteConfig
: (mutation.type == ShadowViewMutation::Type::Insert &&
!wasInsertedTagRemoved