-
Notifications
You must be signed in to change notification settings - Fork 27.5k
$locationChangeStart handler called outside of $apply/$digest #5118
Comments
Is this a duplicate of #5089 |
So, since this is assigned to me, it should be pretty trivial to fix. However, it's not necessarily trivial to test the fix in an automated test. Ignoring the fact that you'd have to use private API to do it, is there any reason you wouldn't want to just call $scope.$apply() as needed on $locationChangeStart if you're updating models? I'll submit a pull-request but again I'm not totally sure how to test this currently (although it would be good to learn!), so... yeah. |
I'm not totally convinced this is a necessary change (see comments on angular#5118). However, feedback valuable. I'll amend this message if it becomes clear that it's a worthwhile change.
I'm not totally convinced this is a necessary change (see comments on angular#5118). However, feedback valuable. I'll amend this message if it becomes clear that it's a worthwhile change.
My current workaround in my $locationChangeStart handler is:
Let's see if I can put together a fiddle/plunkr showing why a simple $apply didn't work. |
that workaround should have no effect on anything. if you do see some issue it's likely due to something else. please take a look at this plunker and see how the counter is updated correctly after each change (even when you use the back button: http://plnkr.co/edit/R7Jdmd?p=preview As Pete mentioned, this report if at all valid is a duplicate of #5089 the reason why you get phase == null in your tests is that we use $digest instead of $apply in the $location code. this is not ideal, but is no reason for panic as $digest will behave as $apply in this case. |
@IgorMinar it is a related bug, not quite a duplicate as they refer to different symptoms of the same thing --- however looking at the fix in 5089 there are some changes in there which are sort of questionable. I'm not sure it's right to put the $locationChangeStart event in evalAsync. Tests are passing, but that doesn't seem right.. but then again I suppose if a digest were already in progress, then it would have the same effect as other cases, so maybe it's not a big deal. |
…is triggered by the browser Fixed inconsistency in $location.path() behaviour on the $locationChangeStart event when using back/forward buttons in the browser or manually changing the url in the address bar. $location.path() now returns the target url in these cases. Closes #4989 Closes #5089 Closes #5118 Closes #5580
…is triggered by the browser Fixed inconsistency in $location.path() behaviour on the $locationChangeStart event when using back/forward buttons in the browser or manually changing the url in the address bar. $location.path() now returns the target url in these cases. Closes angular#4989 Closes angular#5089 Closes angular#5118 Closes angular#5580
…is triggered by the browser Fixed inconsistency in $location.path() behaviour on the $locationChangeStart event when using back/forward buttons in the browser or manually changing the url in the address bar. $location.path() now returns the target url in these cases. Closes angular#4989 Closes angular#5089 Closes angular#5118 Closes angular#5580
I just upgraded to 1.0.8 and noticed that $locationChangeStart is now broadcast when the user hits the back button.
However, the behavior is inconsistent with normal location changes wrt $apply/$digest. Normally, the event handler for $locationChangeStart is called within $apply/$digest, but that's not the case when the user hits the back button.
Demonstration of the problem:
http://plnkr.co/edit/EiZVMK?p=preview
The text was updated successfully, but these errors were encountered: