Re: We need better canaries for JS code

I am for stricter checks and crashing the test when some of the errors discussed here are detected. I have been puzzled when some attributes are undefined as such when I ran tests for Thunderbird in the past. The bugs are found non-Thunderbird-specific code often times. Crashing the tests

Re: We need better canaries for JS code

Hi David, On 2017-10-18 1:28 AM, David Teller wrote: If I understand correctly, this triggered the usual "undefined is not a function", which was 1/ uncaught during testing, as these things often are; That's only because this code doesn't have any tests. That was filed as bug 1409913. 2/

Re: We need better canaries for JS code

On Thu, Oct 19, 2017, at 03:19 PM, Mark Banner wrote: > The only thing that might help (that has been discussed) is something > along the lines of flow - an analyser that could work out that 'spice()' > didn't exist, but Dave Townsend mentioned these don't seem to be viable > for us. > >

Re: We need better canaries for JS code

On 19/10/2017 14:02, Ted Mielczarek wrote: On Wed, Oct 18, 2017, at 07:51 AM, Mark Banner wrote: Looping in firefox-dev as well, as I thin this is an important discussion. On 18/10/2017 09:28, David Teller wrote: Hi everyone, Yesterday, Nightly was broken on Linux and MacOS

Re: We need better canaries for JS code

Dave, how would you feel about deciding on one of those and allowing modules to opt-in to using them, perhaps just as an experiment. Presumably most existing modules wouldn't, but new ones being written might. Dan 2017-10-18 9:06 GMT-07:00 Dave Townsend : > On Wed, Oct

Re: We need better canaries for JS code

Could we do this on a per-module opt-in basis to allow for gradual migration? That is to say, assuming there's enough information in the stack to tell where it was thrown from (I'm guessing that's the case most of the time), by default, ignore these errors unless they're from code in an opted-in

Re: We need better canaries for JS code

On Wed, Oct 18, 2017, at 07:51 AM, Mark Banner wrote: > Looping in firefox-dev as well, as I thin this is an important > discussion. > > On 18/10/2017 09:28, David Teller wrote: > > Hi everyone, > > > >Yesterday, Nightly was broken on Linux and MacOS because of a typo in > > JS code [1].

Re: We need better canaries for JS code

Btw, I believe that there is already support for reporting uncaught errors and that it is blocked by the lack of test harness support. Cheers, David On 18/10/17 19:37, Steve Fink wrote: > My gut feeling is that you'd only want uncaught errors, and > AutoJSAPI::ReportException is a better place

Re: We need better canaries for JS code

On 19/10/2017 03:29, Kris Maglione wrote: On Wed, Oct 18, 2017 at 07:22:09PM -0700, Daniel Veditz wrote: On Wed, Oct 18, 2017 at 4:51 AM, Mark Banner wrote: I did an experiment, and the only way I got an error out was to have "javascript.options.strict" on and Why

Re: We need better canaries for JS code

This should be feasible. Opening bug 1409852 for the low-level support. On 18/10/17 22:22, Dan Mosedale wrote: > Could we do this on a per-module opt-in basis to allow for gradual > migration?  That is to say, assuming there's enough information in the > stack to tell where it was thrown from

Re: We need better canaries for JS code

On Wed, Oct 18, 2017 at 07:22:09PM -0700, Daniel Veditz wrote: On Wed, Oct 18, 2017 at 4:51 AM, Mark Banner wrote: I did an experiment, and the only way I got an error out was to have "javascript.options.strict" on and Why isn't it a code-style/review requirement that

Re: We need better canaries for JS code

On Wed, Oct 18, 2017 at 4:51 AM, Mark Banner wrote: > I did an experiment, and the only way I got an error out was to have > "javascript.options.strict" on and > ​Why isn't it a code-style/review requirement that our own internal JS include "use strict"? As a quick check I

Re: We need better canaries for JS code

I'm wary when it comes to code that lives in tree as it's both an added thing for contributors to learn and an added build step for that code. Also by doing it only within a module you end up missing out on a bunch of benefits. For system add-ons that live elsewhere though I think that is up to

Re: We need better canaries for JS code

On 10/18/17 2:37 PM, Steve Fink wrote: Is there any way to detect if a finalized Promise swallowed an exception without "handling" it in some way or other, even if very heuristically? We used to have such a way. It requires doing things during finalization, which is not great. But we can

Re: We need better canaries for JS code

Note that we also have bug 920191 on file for making JS exceptions fatal in the harness. One of the big blockers to that has always been cleaning up the existing set of problems, but maybe it would be helpful for some of these issues if/when we could drive that into happening. -Ryan On Wed, Oct

Re: We need better canaries for JS code

On 2017-10-18 4:51 AM, Mark Banner wrote: I expect that this will find a number of lurking errorsy, so we may want to migrate code progressively, using a directive, say "use strict moz-platform" and static analysis to help encourage using this directive. It would definitely be interesting to

Re: We need better canaries for JS code

On 10/18/17 10:28 AM, Boris Zbarsky wrote: On 10/18/17 11:54 AM, David Teller wrote: Mmmh... I was looking at setPendingException at http://searchfox.org/mozilla-central/source/js/src/jscntxtinlines.h#435 That will allow you to hook all exceptions, sure, including ones caught by try/catch.

Re: We need better canaries for JS code

On 10/18/17 11:54 AM, David Teller wrote: Mmmh... I was looking at setPendingException at http://searchfox.org/mozilla-central/source/js/src/jscntxtinlines.h#435 That will allow you to hook all exceptions, sure, including ones caught by try/catch. My idea would be to do it even on caught

Re: We need better canaries for JS code

This may not be what you want here, but just so you are aware of the option... You can use `Services.console.registerListener`[1] in a test harness, etc. to hear messages logged to the console. The harness could count messages of a certain type (like script errors) and fail the test if there's an

Re: We need better canaries for JS code

On Wed, Oct 18, 2017 at 4:51 AM Mark Banner wrote: > I remember that we had bugs of this kind lurking for years in our > codebase, in code that was triggered daily and that everybody believed > to be tested. > > I'd like to think that there is a better way to handle these

Re: We need better canaries for JS code

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

Re: We need better canaries for JS code

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

Re: We need better canaries for JS code

Looping in firefox-dev as well, as I thin this is an important discussion. On 18/10/2017 09:28, David Teller wrote: Hi everyone, Yesterday, Nightly was broken on Linux and MacOS because of a typo in JS code [1]. If I understand correctly, this triggered the usual "undefined is not a

Re: We need better canaries for JS code

> I'm not sure changing behavior of the JS VM is the proper layer to > accomplish this. I think reporting messages from the JS console is a > better place to start. We could change the test harnesses to fail tests > if certain errors (like SyntaxError or TypeError) are raised. If there > is a

Re: We need better canaries for JS code

On 18/10/17 10:45, Gregory Szorc wrote: > I agree that errors like this should have better visibility in order to > help catch bugs. > > I'm not sure changing behavior of the JS VM is the proper layer to > accomplish this. I think reporting messages from the JS console is a > better place to

Re: We need better canaries for JS code

On Wed, Oct 18, 2017 at 10:28 AM, David Teller wrote: > Hi everyone, > > Yesterday, Nightly was broken on Linux and MacOS because of a typo in > JS code [1]. If I understand correctly, this triggered the usual > "undefined is not a function", which was > > 1/ uncaught

Re: We need better canaries for JS code

On 18/10/2017 10:28, David Teller wrote: > I have one proposal. Could we change the behavior of the JS VM as follows? > > - The changes affect only Nightly. > - The changes affect only mozilla chrome code (including system add-ons > but not user add-ons or test code). > - Any programmer error