ngMock breaks on Webkit browsers, gives meaningless error messages in testing

[wizardwerdna]

A recent regression, probably in Webkit, has broken certain error messages in Webkit browsers using angularJS with angular.mock. This example:

 1 'use strict';
 2 describe('failure in ng-mocks', function(){
 3   beforeEach(inject(function($compile, $rootScope){
 4     $compile(
 5       '<div ng-include="\'nofilehere\'"></div>'
 6     )($rootScope);
 7     $rootScope.$digest();
 8   }));
 9   it('displayed by example', function(){
10     console.log('hello, world');
11   });
12 });

Properly fails because "nofilehere" does not exist and has not been inserted into the template cache. We get a very meaningful message when driving this with karma under Chrome (and it worked until recently on most browsers):

Error: Unexpected request: GET nofilehere
(stack trace)

At this time, however, PhantomJS and Chrome instead give the following incomprehensible message with angularJS v1.2.0 and v1.2.1:

TypeError: Attempted to assign to readonly property.
    at workFn (/Users/werdna/errors/app/bower_components/angular-mocks/angular-mocks.js:2122)

This occurs because the error is at caught at line 2122 in the following angular-mocks code:

2116       for(var i = 0, ii = blockFns.length; i < ii; i++) {
2117         try {
2118           /* jshint -W040 *//* Jasmine explicitly provides a `this` object when calling functions */
2119           injector.invoke(blockFns[i] || angular.noop, this);
2120           /* jshint +W040 */
2121         } catch (e) {
2122           if(e.stack && errorForStack) e.stack +=  '\n' + errorForStack.stack;
2123           throw e;
2124         } finally {
2125           errorForStack = null;
2126         }
2127       }

and some recent versions of Webkit Error messages have read-only 'stack' properties. Thus, line 2122 fails, and the new TypeError is thrown, losing the stack. Unfortunately, I couldn't think of any other way to rethrow an Error instance with a modified stack string, and was unable to come up with a meaningful pull request.

Clearly, changes derive from the now-false assumption that Error instances were mutable -- at least for Webkit, now, they are not.

Any thoughts?

[yngvark]

Why was this issue closed? I suffer from the same problem, and had to comment out line 2122 in order to see originating error (or use console.log(e)).

[wizardwerdna]

I closed the issue because I inadvertently entered it twice. The original post is still standing, and a pull request fixes the issue without losing the inject-level stack messages.