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: Canonical cinnabar repository

Myk Melez 2017 September 26 at 17:40 Kartikaya Gupta 2017 September 26 at 08:49 So from the discussion here it sounds like using a full (i.e. non-grafted) cinnabar repository "just works" for most people. It has the problem of missing CVS

Re: Change in the way e10s and multi are enabled on Nightly

On Wed, Oct 18, 2017 at 3:22 PM, Justin Dolske wrote: > On Wed, Oct 18, 2017 at 11:52 AM, Blake Kaplan wrote: > >> >> One more thing to point out: with the removal of e10srollout, I also >> removed the code that would disable e10s if we detected a >>

Re: Change in the way e10s and multi are enabled on Nightly

On Wed, Oct 18, 2017 at 11:52 AM, Blake Kaplan wrote: > > One more thing to point out: with the removal of e10srollout, I also > removed the code that would disable e10s if we detected a > non-multiprocessComptaible extension. We are entirely relying on the addon > manager to

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

Change in the way e10s and multi are enabled on Nightly

Hello everybody, I'm in the process of landing a change in bug 1406212 [1] that changes the way that we handle enabling or disabling of e10s and e10s-multi. This change will ride the trains, so Firefox 58 will be the first version with the simplified logic. To recap the current situation: we

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: Intent to ship: CSP directive worker-src

We do have `worker-src` tests, FWIW: https://github.com/w3c/web-platform-tests/tree/master/content-security-policy/worker-src/. We'll likely need to adjust things based on the fallback mechanism y'all are running with (and Chrome will need to drop the weird contortions we implemented for

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: Intent to Unship: stream decoder for BinHex format

On 10/17/2017 10:45 AM, Boris Zbarsky wrote: On 10/17/17 5:47 AM, Shih-Chiang Chien wrote: I intent to remove all the code that handling BinHex decoding, i.e. nsBinHex.cpp, from mozilla-central if no other project is using it. The code was originally added for mailnews.  See

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: Intent to ship: CSP directive worker-src

> On Oct 18, 2017, at 11:41 AM, James Graham wrote: > > On 18/10/17 10:35, Christoph Kerschbaumer wrote: >>> On Oct 18, 2017, at 11:25 AM, James Graham wrote: >>> >>> On 22/09/17 15:18, Christoph Kerschbaumer wrote: Hey Everyone,

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: Intent to ship: New default action, horizontal scroll, of wheel with Shift key (except Firefox for macOS)

On 10/18/2017 4:08 PM, Jet Villegas wrote: That is, do I owe you another steak? :-) Always welcome another steak :-D -- Masayuki Nakano Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org

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: Intent to ship: CSP directive worker-src

On 18/10/17 10:35, Christoph Kerschbaumer wrote: On Oct 18, 2017, at 11:25 AM, James Graham wrote: On 22/09/17 15:18, Christoph Kerschbaumer wrote: Hey Everyone, within CSP2 workers used to be governed by the child-src directive [0]. CSP3 introduces the worker-src

Re: Intent to ship: CSP directive worker-src

> On Oct 18, 2017, at 11:25 AM, James Graham wrote: > > On 22/09/17 15:18, Christoph Kerschbaumer wrote: >> Hey Everyone, >> within CSP2 workers used to be governed by the child-src directive [0]. CSP3 >> introduces the worker-src directive [1] wich governs Workers,

Re: Intent to ship: CSP directive worker-src

On 22/09/17 15:18, Christoph Kerschbaumer wrote: Hey Everyone, within CSP2 workers used to be governed by the child-src directive [0]. CSP3 introduces the worker-src directive [1] wich governs Workers, SharedWorkers as well as ServiceWorkers. Please note that the child-src directive has been

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

Re: Intent to ship: New default action, horizontal scroll, of wheel with Shift key (except Firefox for macOS)

On 10/18/2017 08:08 AM, Jet Villegas wrote: SGTM. BTW, bug 143038 was filed 16 years ago. Is that a bugzilla record for oldest fixed bug? whoohoo, didn't realize it was that old. One day I'll start reading the bugs I review ;) That is, do I owe you another steak? :-) On Wed, Oct 18, 2017

We need better canaries for JS code

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 during testing, as these things often are; 2/ basically impossible to diagnose in the

Re: Intent to ship: New default action, horizontal scroll, of wheel with Shift key (except Firefox for macOS)

SGTM. BTW, bug 143038 was filed 16 years ago. Is that a bugzilla record for oldest fixed bug? That is, do I owe you another steak? :-) On Wed, Oct 18, 2017 at 2:52 PM, Masayuki Nakano wrote: > From some users who use legacy mice which supports only vertical wheel, we >

Intent to ship: New default action, horizontal scroll, of wheel with Shift key (except Firefox for macOS)

From some users who use legacy mice which supports only vertical wheel, we have a request to support horizontal scroll with vertical wheel operation with a modifier. https://bugzilla.mozilla.org/show_bug.cgi?id=143038 Now, legacy add-ons have gone since 57 and it may be difficult to override