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

Infinite loop when toggle sidenav during animation #8869

Closed
iget-master opened this issue Dec 7, 2017 · 2 comments · Fixed by #8872
Closed

Infinite loop when toggle sidenav during animation #8869

iget-master opened this issue Dec 7, 2017 · 2 comments · Fixed by #8872
Assignees
Labels
P2 The issue is important to a large percentage of users, with a workaround

Comments

@iget-master
Copy link

iget-master commented Dec 7, 2017

Bug, feature request, or proposal:

Toggling the sidenav menu during animation causes a infinite loop that crashes the browser.

What is the expected behavior?

It's expected that the toggle never crash the browser.

What is the current behavior?

Toggling sidenav too fast (or during the animation) will cause an infinite loop.

What are the steps to reproduce?

It's easy to reproduce, you can use the example given by Material Docs:
https://stackblitz.com/angular/yjjyldrpyyej

Just click it fast, and you will notice that the browser crashes, and throw infinite error messages on console:

SidenavOpenCloseExample.ngfactory.js:20 ERROR Error: ExpressionChangedAfterItHasBeenCheckedError: Expression has changed after it was checked. Previous value: 'true'. Current value: 'false'.
at viewDebugError (core.umd.js:9845)
at expressionChangedAfterItHasBeenCheckedError (core.umd.js:9823)
at checkBindingNoChanges (core.umd.js:9992)
at checkNoChangesNodeInline (core.umd.js:14044)
at checkNoChangesNode (core.umd.js:14016)
at debugCheckNoChangesNode (core.umd.js:14845)
at debugCheckDirectivesFn (core.umd.js:14747)
at Object.eval [as updateDirectives] (SidenavOpenCloseExample.ngfactory.js:118)
at Object.debugUpdateDirectives [as updateDirectives] (core.umd.js:14729)
at checkNoChangesView (core.umd.js:13854)

Removing the two way binding for sidenav ([(opened)]="menuOpen") workaround the issue, but isn't the fix.

Which versions of Angular, Material, OS, TypeScript, browsers are affected?

The latest versions available for everything, I've just installed following documentation.

The browser version is "Versão 62.0.3202.62 (Versão oficial) beta 64 bits"

@crisbeto crisbeto self-assigned this Dec 7, 2017
@crisbeto crisbeto added has pr P2 The issue is important to a large percentage of users, with a workaround labels Dec 7, 2017
crisbeto added a commit to crisbeto/material2 that referenced this issue Dec 7, 2017
…-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
Copy link
Member

crisbeto commented Dec 7, 2017

Thanks for the report @iget-master, there's a pending fix, but until it gets in you can work around it by changing the two-way binding on opened to a one-way binding ([(opened)] -> [opened]).

crisbeto added a commit to crisbeto/material2 that referenced this issue Dec 7, 2017
…-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 added a commit to crisbeto/material2 that referenced this issue Dec 7, 2017
…-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.
andrewseguin pushed a commit that referenced this issue Dec 13, 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.
andrewseguin pushed a commit that referenced this issue 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
P2 The issue is important to a large percentage of users, with a workaround
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants