On 18/10/17 14:16, Boris Zbarsky wrote: > On 10/18/17 4:28 AM, David Teller wrote: >> 2/ basically impossible to diagnose in the wild, because there was no >> error message of any kind. > > That's odd. Was the exception caught or something? If not, it should > have shown up in the browser console, at least....
In this case, the browser console couldn't be opened. Also, as suggested by gps, we can probably reuse the same (kind of) mechanism to report stacks of programming errors in the wild. > >> I have one proposal. Could we change the behavior of the JS VM as >> follows? > > Fwiw, the JS VM doesn't really do exception handling anymore; we handle > all that in dom/xpconnect code. Mmmh... I was looking at setPendingException at http://searchfox.org/mozilla-central/source/js/src/jscntxtinlines.h#435 . Can you think of a better place to handle this? >> - The changes affect only Nightly. >> - The changes affect only mozilla chrome code (including system add-ons >> but not user add-ons or test code). > > What about test chrome code? The browser and chrome mochitests are > pretty hard to tell apart from "normal" chrome code... Good question. I'm not sure yet. I actually don't know how the tests are loaded, but I hope that there is a way. Also, we need to test: it is possible that the code of tests might not be a (big) problem. >> - Any programmer error (e.g. SyntaxError) causes a crash a crash that >> displays (and attaches to the CrashReporter) both the JS stack in and >> the native stack. > > We would have to be a little careful to only include the chrome frames > in the JS stack. > > But the more important question is this: should this only apply to > _uncaught_ errors, or also to ones inside try/catch? Doing the former > is pretty straightforward, actually. Just hook into > AutoJSAPI::ReportException and have it do whatever work you want. It > already has a concept of "chrome" (though it may not match the > definition above; it basically goes by "system principal or not?") and > should be the bottleneck for all uncaught exceptions, except: > > * Toplevel evaluation errors (including syntax errors) in worker scripts. > * "uncaught" promise rejections of various sorts > > Doing this might be a good idea. It's _definitely_ a good experiment... My idea would be to do it even on caught errors. It is too easy to catch errors accidentally, in particular in Promise. Cheers, David _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
