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....
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.
- 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...
- 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... -Boris _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
