Leaving templateUrl empty in $routeProvider.when() crashes the browser

AngularJS 1.4.0
Firefox 38.0.5 (Privacy Mode)

When setting up routing (ngRoute) in the module's .config(), using an empty string as the templateUrl will force the browser into either an infinite loop or a crash.

$routeProvider.when('/custom/route' {templateUrl:'', controller:'', controllerAs:''}) will crash. Replacing templateUrl with a string (even a non-existing file) does not cause the crash.

Can you elaborate on "crash"? If the browser crashes, that's a Firefox bug you should report on bugzilla.mozilla.org. If you just mean it throws, that seems expected

If we're doing some string processing that blocks the browser, then we should fix that, though.

When I first noticed the problem (by clicking on a link whose routing was set to a templateUrl:'', the entire browser (not just the tab) became unresponsive for about 10 seconds and my CPU usage rose to 100%, then a Firefox alert told me that a script on the page was taking too long and gave me the option to let the script run, or to stop the script. I chose to let it run and eventually the browser crashed (meaning it force-closed and the Mozilla Crash Reporter opened)

In subsequent tests, I can replicate the unresponsiveness and high CPU usage every time, but I no longer get the option to stop the script; the browser just crashes and the Crash Reporter opens.

This only happens when templateUrl is an empty string. I chose to report it here because I suspected either an infinite loop in AngularJS or perhaps a lack of input validation for the function that uses the templateUrl setting to setup the route.

Thanks for the details. And you're sure you can't replicate this on another browser? If we're blocking in an infinite loop somewhere you ought to be able to. I'll take a look when I can unless someone else gets to it first, or if it's been fixed already in 1.4.1

I have not tried it on another browser

Do you think you could put together a simple reproduction? I've gotten it started at http://plnkr.co/edit/W9ES8v50DFHh3LWUa9N8?p=preview but so far haven't been able to break any browsers I've tried it with

Nevermind, I've repro'ed it =)

http://plnkr.co/edit/iBeXT1Y5I71jEdOB3D4w?p=preview this will break in all browsers --- so we never emit $routeChangeError in this case, but it looks like we should be taking that path since we get the 404 for the empty template string.

This is not a regression, it's been broken since at least v1.2.0

As already mentioned, the problem I can see is that using templateUrl: '' will load the page itself again, which (obviously) contains an ngView and tries to load a view (because of the ngView directive) and we have a nice infinite loop.

The cause of the problem (afaict) is not related to routing, but to nested ngView's creating infinite loops. IMO, this is what we should fix.

@caitp

BTW, here is a quick-and-dirty fix (decorating the ngView directives), that "fixes" the issue (as a POC).
The same decoration "fixes" @caitp's demo as well (updated plnkr).

@gkalpak

Indeed, the update() function inside the ngView directive is called infinitely when the templateUrl is empty.

This could be fixed by adding a check before attaching the content view to the DOM inside the update() function. Hence, the $transclude() function will not be triggered in this case.

@gkalpak, what do you think?

@gdangelo

@gdangelo, imo the issue should be caught and prevented before reaching the update() function (to avoid the unnecessary overhead of other operations and listeners).

That said, it is pretty difficult to have a reliable solution (taking into account corner-cases such as multiple apps on the page and ng-non-bindable regions).

I ran into this issue as well. The following code reproduces this problem reliably in all browsers (but not in codepen or plunkr). It is clearly an infinite loop issue as can be seen by repeated "Title" on page and repeated 'in modalCtrl' in console.

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <meta name="fragment" content="!">
    <base href="/">
</head>

<body ng-app="Angular">

<h1>Title</h1>
<ng-view class="app-content"></ng-view>

<script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.4.5/angular.min.js"></script>
<script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.4.5/angular-route.min.js"></script>
<script>
    angular.module('g.modal', [
        'ngRoute',
    ]).controller('modalCtrl', [function() {
        console.log('in modalCtrl');
    }]);

    angular.module('Angular', [
        'ngRoute',
        'g.modal',
    ]).config(['$routeProvider', '$locationProvider', function($routeProvider, $locationProvider) {
        $routeProvider.when('/', {templateUrl: '',  controller: 'modalCtrl'});
        $locationProvider.html5Mode(true);
        $locationProvider.hashPrefix('!');
    }]);

</script>

</body>
</html>

In what circumstances is an empty string a valid templateUrl? Surely that is a programming error in the application and Angular should throw an error, right?

@petebacondarwin

@petebacondarwin, yes it's due to programming bug - something that costed me more than 2 days to figure out. The same symptom occurs if the templateUrl points to a non-existent template.

Not sure if throwing errors would be BC at this stage? But I guess if we know it would always infinitely loop then it doesn't matter. The question is whether that is always the case?

I guess you could have a setup where an interceptor changes the url into something else? In that case an empty string would be okay.

Navigation Menu

Repository navigation

Leaving templateUrl empty in $routeProvider.when() crashes the browser #12176

7 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Leaving templateUrl empty in $routeProvider.when() crashes the browser #12176

Description

Activity

caitp commented on Jun 20, 2015

caitp commented on Jun 20, 2015

RoxKilly commented on Jun 20, 2015

caitp commented on Jun 20, 2015

RoxKilly commented on Jun 20, 2015

caitp commented on Jun 20, 2015

caitp commented on Jun 20, 2015

caitp commented on Jun 20, 2015

7 remaining items

gkalpak commented on Jun 26, 2015

gkalpak commented on Jun 26, 2015

gdangelo commented on Jun 26, 2015

gkalpak commented on Jun 29, 2015

vinkaga commented on Sep 4, 2015

petebacondarwin commented on Sep 8, 2015

vinkaga commented on Sep 8, 2015

petebacondarwin commented on May 14, 2018

Narretz commented on May 14, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions