Firefox 6.0.2 silently leaves execution of printStackTrace() prematurely #27

Closed
skarmats opened this Issue Sep 20, 2011 · 13 comments

5 participants

@skarmats

In Firefox 6 and a recent check-out of javascript-stacktrace, Firefox silently leaves execution of printStackTrace() prematurely

Here is a reduced code snippet that exhibits the described behavior:

// Somewhere error gets thrown
throw 'An error occured';

window.onerror = function (errorMsg, url, lineNumber) {
  alert(errorMsg + url + lineNumber);
  // Previous line gets executed
  var trace;
  try {
    // Firefox enters printStackTrace. Leaves silently somewhere in there
    trace = printStackTrace().join('\n\n\t');
    // Execution does not arrive here (as evidenced in debugger)
  }
  catch (e) {
    // nothing gets thrown/caught in Firefox
    // error console empty (the original uncaught exception is logged)
  }
  // Execution does not arrive here 
  // (as evidenced in debugger and actual browser window)
  alert(trace);

  return true;
}
@eriwen eriwen was assigned Sep 20, 2011
@eriwen
stacktrace.js member

I'm assigned myself to check out what's going on. I suspect it is because you are throwing a String object instead of an Error object, but I'll create a test and keep you posted.

@cmq

I'm actually experiencing something similar, although I don't think it has to do with what skarmats is throwing... it has to do with using printStackTrace() inside window.onerror()

Here is some code showing a way to test this:

<html><head>
<script src="stacktrace.js"></script>
<script>
window.onerror = function(msg, file, line) {
    alert(printStackTrace().join('\n\n'));
}
function test() {
    x += 1;
}
</script>
</head>
<body onload="test();"></body>
</html>

If you put this code in a file and run it, you will see an alert when the page loads with the stack trace. However, if you then go into your FireBug console and run test() again manually, you won't get the alert. Instead, the javascript console handles the error ('ReferenceError: x is not defined') as normal, but the alert I'm expecting doesn't happen.

The interesting thing is if you add a breakpoint to the line containing the alert inside of window.onerror(), you will not hit that breakpoint the second time, when you execute test() manually. You'll hit it the first time the page loads, but if you play through it and run test() again, you won't even hit it.

This happens to me on Windows Vista using Chrome 14, FireFox 7, and IE9. Something in printStackTrace must somehow be missing with window.onerror or something. I'd love to hear if you find a solution for this, as this seems like a very useful utility.

@ebdrup

I'm seeing this in FF7 too, The Firebug console actually bubbles the this.undef() provoked error in printStackTrace up to the browser, even with onerror set, when printStackTrace is called from onerror.

@victor-homyakov

This happens only for local files (opened from local media, file:/// protocol), version of Firefox does not matter (from 3.6 and maybe earlier up to latest 7.X):

getSource failed with url: file:///home/user/stacktrace/stacktrace.js, exception: [Exception... "Access to restricted URI denied" code: "1012" nsresult: "0x805303f4 (NS_ERROR_DOM_BAD_URI)" location: "file:///home/user/stacktrace/stacktrace.js Line: 218"]()@file:///home/user/stacktrace/stacktrace.js:42

in method ajax() at line

req.open('GET', url, false); 
@victor-homyakov

We just need to wrap ajax in try-catch block - look at the gist #1337071 https://gist.github.com/1337071

@eriwen
stacktrace.js member

@victor-homyakov Sounds great! Would you mind making this change quick?

@victor-homyakov

If it is OK, i'll make it tomorrow.

@victor-homyakov victor-homyakov added a commit that referenced this issue Nov 4, 2011
@victor-homyakov victor-homyakov Temporary fix for #27 (exception in ajax() while in window.onerror ca…
…uses bad behavior of Firefox). However, the cause of ajax() exception is not clear.
59f60d2
@eriwen
stacktrace.js member

@cmq and @Muscula: Is this effectively working for you now?

@cmq
cmq commented Nov 7, 2011

The behavior I described in my post on 9/30/11 is still the same with this new javascript file -- subsequent executions of my intentionally-broken "test()" function will not produce the stacktrace. Thanks for looking into this!

@victor-homyakov

@skarmats: I've tested the fixed version - executes, debugger breakpoints are reached (both as local page file:// and served from local HTTP server http://)
@cmq: I think this issue is a bit different than issue of topic starter

@victor-homyakov

@skarmats: look at https://developer.mozilla.org/en/Same-origin_policy_for_file%3a_URIs - by default Firefox (built on Gecko 1.9+) considers js files to be same-origin with html page only if they are placed in same directory or subdirectories, e.g. for html file dir1/dir2/page.html js files dir1/dir2/script1.js, dir1/dir2/subdir/script2.js are considered same-origin, but dir1/script.js not.

In our test case stacktrace/stacktrace.js cannot be loaded via ajax from stacktrace/test/functional/testcase1.html.

This behavior can be disabled - on about:config page set security.fileuri.strict_origin_policy to false.

@victor-homyakov

Executing test() from test/issues/27-2.html in FireBug effectively crashes my Firefox 10.0.2 :)

@victor-homyakov

@cmq
Re-checked test/issues/27-2.html in Firefox 11 and Chrome 18 - works fine, browser shows message both from onload and button. I think behaviour you noticed may depend on Firebug/Web Inspector settings (they may catch uncaught exceptions).

Feel free to reopen or create new issue if you find something new about this problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment