Dear Steve,
Thank you for the feedback.
Also I would like to thank other people whose e-mails
also give an glimpse of the depth of the problem.
On 2014/10/03 4:49, Steve Fink wrote:
On 10/02/2014 11:59 AM, ISHIKAWA,chiaki wrote:
Hi,
I was looking at a large number of JavaScript (strict)
I'm in the process of doing that for uncaught rejections, fwiw.
On 03/10/14 03:34, Boris Zbarsky wrote:
On 10/2/14, 4:53 PM, Jeff Gilbert wrote:
If you want to guarantee it, don't warn, assert.
Note that mochitest-plain tests will go orange on unexpected uncaught
exceptions. Not least
We should most likely assert when we have strict violations in chrome JS.
We should *definitely* assert when we have JS errors in chrome JS.
I don't see how there should be any excuse for either of these cases.
We certainly can't assert on non-browser JS errors, but we should keep our own
On 10/02/2014 11:59 AM, ISHIKAWA,chiaki wrote:
Hi,
I was looking at a large number of JavaScript (strict) warnings, and
errors from the recording of |make mozmill| test run of locall-built
DEBUG BUILD of TB last several days after a refresh of C-C source tree.
The number of such has
See bug 807862 - Use strict mode for all builtin JS
Note that some of those warnings are from SpiderMonkey's non-standard
extra warnings mode, not ES5 strict mode. To confuse matters, extra
warnings were called strict warnings before ES5 and are controlled by
the javascript.options.strict
On 02/10/14 12:52, Chris Peterson wrote:
SpiderMonkey already forces ES5 strict mode and extra warnings mode
for all self-hosted JS: bug 784295.
The problem is that this only generates an exception, not a test
failure, so if the error is in code that isn't depended upon (also a
problem),
Thanks for bringing this up!
So ever since extra super awesome strict warning were turned on we indeed have
to endure longer tail logs during test runs and when running debug builds. Just
like I get the information telling me which video card my computer has for
about the 1000th time.
All in
1:05:44 PM
Subject: Re: JavaScript (strict) Warning from FF mochitest-plain test.
On 02/10/14 12:52, Chris Peterson wrote:
SpiderMonkey already forces ES5 strict mode and extra warnings mode
for all self-hosted JS: bug 784295.
The problem is that this only generates an exception, not a test
On 2014-10-02, 4:40 PM, Mike de Boer wrote:
Thanks for bringing this up!
So ever since extra super awesome strict warning were turned on we indeed have
to endure longer tail logs during test runs and when running debug builds. Just
like I get the information telling me which video card my
Are we going to spend the time to fix these, however?
I’d be up for that, certainly!
For context, for as long as I remember, if you kept the browser console open
and used the browser, we'd occasionally report an unhandled chrome JS errors
(for example when attempting to access properties
On 10/2/14, 4:53 PM, Jeff Gilbert wrote:
If you want to guarantee it, don't warn, assert.
Note that mochitest-plain tests will go orange on unexpected uncaught
exceptions. Not least because we added that pretty early on in their
evolution.
We're nowhere close to doing that with
11 matches
Mail list logo
