Skip to content
This repository has been archived by the owner on Feb 22, 2018. It is now read-only.

domRead() and domWrite() callbacks are getting called even if the scope was destroyed #1161

Closed
isoos opened this issue Jun 17, 2014 · 3 comments

Comments

@isoos
Copy link

isoos commented Jun 17, 2014

If the component registers domRead and domWrite callbacks, yet a parent ng-if will wipe out the scope, the callbacks may find an inconsistent state. There are two outcomes here:

  • calling the callbacks may cause exceptions due to the unexpected state
  • not calling the callbacks may leave something else in a hanging state

I'd vote for the not calling (as potentially hanging state seems to be less frequent thing, and it is easy to handle it on a scope destroy at the first place).

@mvuksano
Copy link
Contributor

I think, when destroying the scope, we should destroy it only after everything that is scheduled is executed.

@vsavkin vsavkin self-assigned this Jul 25, 2014
@vsavkin
Copy link
Contributor

vsavkin commented Jul 25, 2014

@istvan-soos Misko asked me to work on it. Hopefully will be done in a few weeks.

@vsavkin
Copy link
Contributor

vsavkin commented Aug 11, 2014

PR #1341 closes this issue. Now it is possible to use any scope (not just the root) to schedule a dom write/read. So the component should use its scope. If that scope gets destroyed, none of the DOM operations scheduled on that scope gets executed.

vsavkin added a commit to vsavkin/angular.dart that referenced this issue Aug 12, 2014
vsavkin added a commit to vsavkin/angular.dart that referenced this issue Aug 27, 2014
vsavkin added a commit to vsavkin/angular.dart that referenced this issue Aug 27, 2014
@vsavkin vsavkin closed this as completed in c18a8f3 Sep 3, 2014
vsavkin added a commit to vsavkin/angular.dart that referenced this issue Sep 10, 2014
jbdeboer pushed a commit to jbdeboer/angular.dart that referenced this issue Sep 11, 2014
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

Successfully merging a pull request may close this issue.

3 participants