Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(drawer): infinite loop when two-way opened binding is toggled mid-animation #8872

Merged
merged 1 commit into from
Dec 13, 2017

Conversation

crisbeto
Copy link
Member

@crisbeto crisbeto commented Dec 7, 2017

As of 004e0fe the drawer supports a two-way binding on the opened property, however because the openedChange emits at the end of the animation and two-way bindings invoke their setter which then trigger an animation which in turn invokes openedChange, there is the potential for an infinite loop if the user changes the opened state mid-animation. These changes avoid the issue by turning the openedChanged into an async stream and emitting the current value at the end of the animation, rather than determining the value based on the animation state.

Fixes #8869.

@googlebot googlebot added the cla: yes PR author has agreed to Google's Contributor License Agreement label Dec 7, 2017
@@ -195,7 +195,7 @@ export class MatDrawer implements AfterContentInit, AfterContentChecked, OnDestr
_animationState: 'open-instant' | 'open' | 'void' = 'void';

/** Event emitted when the drawer open state is changed. */
@Output() openedChange: EventEmitter<boolean> = new EventEmitter<boolean>();
@Output() openedChange: EventEmitter<boolean> = new EventEmitter<boolean>(true);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

...(/* isAsync */ true) since it kind of looks like initializing open to true

…-animation

As of angular@004e0fe the drawer supports a two-way binding on the `opened` property, however because the `openedChange` emits at the end of the animation and two-way bindings invoke their setter which then trigger an animation which in turn invokes `openedChange`, there is the potential for an infinite loop if the user changes the `opened` state mid-animation. These changes avoid the issue by turning the `openedChanged` into an async stream and emitting the current value at the end of the animation, rather than determining the value based on the animation state.

Fixes angular#8869.
@crisbeto crisbeto added action: merge The PR is ready for merge by the caretaker merge: caretaker note Alert the caretaker performing the merge to check the PR for an out of normal action needed or note target: patch This PR is targeted for the next patch release labels Dec 7, 2017
@crisbeto
Copy link
Member Author

crisbeto commented Dec 7, 2017

Caretaker note: this might cause some fakeAsync tests to throw X timer(s) still in queue. errors. Based on the amount of failures, we should decide whether this goes into a patch release.

@andrewseguin andrewseguin merged commit 7c84490 into angular:master Dec 13, 2017
andrewseguin pushed a commit that referenced this pull request Dec 19, 2017
…-animation (#8872)

As of 004e0fe the drawer supports a two-way binding on the `opened` property, however because the `openedChange` emits at the end of the animation and two-way bindings invoke their setter which then trigger an animation which in turn invokes `openedChange`, there is the potential for an infinite loop if the user changes the `opened` state mid-animation. These changes avoid the issue by turning the `openedChanged` into an async stream and emitting the current value at the end of the animation, rather than determining the value based on the animation state.

Fixes #8869.
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 7, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
action: merge The PR is ready for merge by the caretaker cla: yes PR author has agreed to Google's Contributor License Agreement merge: caretaker note Alert the caretaker performing the merge to check the PR for an out of normal action needed or note target: patch This PR is targeted for the next patch release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Infinite loop when toggle sidenav during animation
4 participants