"Script error" regression

[tj]

cc @c4milo

possibly due to the new IE stuff, taking a look

[c4milo]

great, thanks

[tj]

This issue has been inactive for over 1 month so I'm closing it. If you think it's still an issue re-open. - tjbot

[nilbus]

This issue as described in chaijs/chai#4 still occurs and should be re-opened.

[boneskull]

@nilbus Can you provide a very simple spec to reproduce this?

[nilbus]

yes, I'll try

[nilbus]

I created a small repo that reproduces this problem: nilbus/script-error

It basically boils down to this:

describe('script-error', function() {
  it('occurs in Chrome when an assertion fails in an async callback', function(done) {
    setTimeout(function() {
      expect(1).to.eql(2);
      done();
    }, 0)
  });
});

My particular setup uses bdd style and chai expect. I don't expect this to be relevant, though I haven't tested other combinations.

[nilbus]

Browser specifics:

• Fails in OSX Chrome 36
• No issue in OSX Safari 7.0.5

[nilbus]

Why the Windows tag? This was tested in OSX.

[boneskull]

my bad, just saw TJ mention IE

[boneskull]

I looked into this some.

I can reproduce it fine when loading your "script-error" repo via a file:// url. I cannot reproduce it when run via a web server.

I believe this is a security measure by Chrome/Chromium to disallow access by file:// URLs to certain information, but I'm not familiar enough with Chromium to tell you why.

[boneskull]

(that being said, I don't think we can do anything about it)

[nilbus]

Good observation. Thank you.

[nilbus]

Would you say that running via file:// is extremely common? Perhaps we
should detect the error and wrap it with a more meaningful error that
suggests avoiding file://. I suppose this may not be the only cause of a
"script error", possibly generating false positives, but have you ever seen
that?

[boneskull]

@nilbus Guess that depends on the test runner. Are there any that use file://? I use Karma personally, and that runs its own server. If no common ones do, then I don't want to assume, but to hazard a guess I'd say it'd be rare?

I do recall getting quite a few "Script Error"'s out of IE for various reasons. That may have changed in newer versions though. Other than this I've never seen Chrome throw one, so we could potentially sniff for Chrome and say "hey, don't use a file:// URL if you want reasonable uncaught exceptions in your async code" but, meh, we could also just add a line to the docs that says "if using in browser, for best results, use with a server."

[boneskull]

It may be that certain extensions, when allowed access to file system resources, can cause this error in a server context (not sure). In order for this to happen, you have to explicitly give the extension the permission; I don't think extensions are allowed to even ask you. Someone should check. An example of this type of extension would be Tampermonkey. But again if you are doing stuff like that, you get what's coming to you. 😄

[nilbus]

Maybe​ I'm alone in just opening the HTML file as my test runner? :-)

[tad-lispy]

I think it's related to Same Origin Policy.

I was running my tests in Chromium version 39.0.2171.65 Ubuntu 14.04 64-bit. Everything was served from localhost (by simple express server) over HTTP, except Chai which was served from CDN. I had same symptoms. Accessing Chai via HTTP or HTTPS made no difference. Downloading it and serving from localhost server fixed the problem.

[nilbus]

Perhaps that applies differently to http://localhost and file://.

[tad-lispy]

I'm not an expert, but it seems that sometimes browsers treat two files loaded via file: scheme as having different origin. For Firefox it's discussed here: Same-origin policy for file: URIs. There's also this StackOverflow answer which quotes HTML5 spec, but provided link is broken, so I'm not sure if it's up to date.

@nilbus It's very easy to serve local files with ad hoc server though. Check out this Big list of http static server one-liners. That might be the easiest workaround for you.