Our animations seem to be rather fragile when there's any sort of user action that cancels them or changes them in flight. In the case of the context appbar, the triggering of the "MozAppbarDismissing" event does not actually indicate that we've moved to a hidden state. It just means that somewhere a dismiss action was started and a transitionend event got fired. If we cancel or change an animation in flight, the event listener will still fire when the next transition ends (along with whatever next ones are still attached). In the near term, we should look at doing more state checks in our transitionend event handlers. Over the longer term, we may consider having some sort of animation state manager that triggers events/handlers when we specifically reach a particular state, rather than when transitions end.
Summary: Defect - Cancelled/swapped transitions still trigger transitionend handler at end of a later animation on the same element → Defect - Interface fragile when animations/transitions are cancelled or changed in-flight
Whiteboard: [preview-triage] feature=defect c=tbd u=tbd p=0
This bug is about improving our interactions with css transitions. Not blocking on it though per the triage meeting.
Whiteboard: [preview-triage] feature=defect c=tbd u=tbd p=0 → feature=defect c=tbd u=tbd p=0
Summary: Defect - Interface fragile when animations/transitions are cancelled or changed in-flight → Interface fragile when animations/transitions are cancelled or changed in-flight
Whiteboard: feature=defect c=tbd u=tbd p=0 → [defect] p=0
Mass close of bugs in obsolete product https://bugzilla.mozilla.org/show_bug.cgi?id=1350354
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.