fix($rootScope): remove history event handler when app is torn down

[randombk]

Remember the popstate and hashchange handler registered with window
when the application bootstraps, and remove it when the application
is torn down

Closes #9897

[mary-poppins]

I'm sorry, but I wasn't able to verify your Contributor License Agreement (CLA) signature. CLA signature is required for any code contributions to AngularJS.

Please sign our CLA and ensure that the CLA signature email address and the email address in this PR's commits match.

If you signed the CLA as a corporation, please let us know the company's name.

Thanks a bunch!

PS: If you signed the CLA in the past then most likely the email addresses don't match. Please sign the CLA again or update the email address in the commit of this PR.
PS2: If you are a Googler, please sign the CLA as well to simplify the CLA verification process.

[randombk]

Fixed.

[caitp]

revert

[lgalfaso]

this is somehow a duplicate of #8005

[randombk]

You're right - the $shutdown service looks like a cleaner way to do this. Why was work on it stopped?

[caitp]

it's not really much cleaner, it's much harder to land something like $shutdown because it's way more complicated.

This patch is pretty simple, it's a good way to go.

[caitp]

private API, don't use doc annotations for this --- just a comment explaining what it does

[lgalfaso]

I agree with @caitp that the shutdown idea is more complex than this patch (with all that this implies). The only thing in favor is that it takes care of cleaning up $timeout, $interval and provides a mechanism for third party modules to perform some tasks when shutting down an angular app

[randombk]

@lgalfaso I guess modules can just listen to the $destroy event on $rootScope for that

[randombk]

Is there still an issue with the CLA? I notice that this is still tagged cla:no

[caitp]

@randombk the robot is having some issues with auto CLA updates lately :( I thought it was supposed to be resolved by now, but I guess not...

[caitp]

I don't think we're going to get this in for this release, but it seems like a reasonable approach to me, so we can probably do this next time.

I'm half expecting to hear complaints from people that their app no longer "works" because of this, though :(

[jbedard]

off should probably be used instead of the legacy unbind. Could also make it one line doing jqLite(window).off('popstate hashchange', cacheStateAndFireUrlChange);

[googlebot]

CLAs look good, thanks!

[petebacondarwin]

I would rather see this event removal closer to where it is added, in $browser. Can't we put it in a $rootScope.$on('$destroy', function() { ... }) instead, which could be created in the $browser.onUrlChange() method?

[Narretz]

@petebacondarwin I can open a new PR with this change. Depends on #11241 though.

[randombk]

@petebacondarwin is $rootScope available from $browser.onUrlChange()? $browser is injected into $rootScope.

[petebacondarwin]

How about putting the $rootScope.$on('$destroy', function() { ... }) inside the $location, which is where $browser.onUrlChange() is called?

For example, if onUrlChange returned a method that could be called to unbind itself then we could easily do that with little coupling there.

[randombk]

I can move the removal method call to where you suggest, but I think we should still keep $browser.$$applicationDestroyed(). $browser.onUrlChange() currently returns the registered handler, which makes sense. I know this is an internal api, but making it return a function that removes a different handler is fairly non-intuitive.

[petebacondarwin]

Added some tests and merged. Thanks