Re: nodejs for extensions ?

Enrico Weigelt, metux IT consult 2017 July 28 at 21:33 Hi folks, just curious: did anyone already try nodejs modules for (javascript-only) extensions ? There was some discussion of this in the dev-addons thread "Node and Web Extensions Experiment"

nodejs for extensions ?

Hi folks, just curious: did anyone already try nodejs modules for (javascript-only) extensions ? --mtx ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: ESlint rule 'no-arbitrary-setTimeout' enabled on xpcshell tests

Since this seems to only look for setTimeout, which is a relatively rare construct in xpcshell tests, should we be looking for do_timeout calls that use a non-zero argument as well? Cheers, Josh On 7/28/17 11:48 AM, Andrew Halberstadt wrote: As part of a larger effort to reduce oranges, we ar

Re: Heads up! Building Stylo in local developer builds

btw, there is a mach bootstrap bug on Windows if you had previously installed the i686 rustc toolchain instead of the x86_64 toolchain: Bug 1385241 - ./mach bootstrap: error: component 'rust-std' for target 'i686-pc-windows-msvc' is required for toolchain 'stable-i686-pc-windows-msvc' and cannot

Super-review - proposal to remove given lack of super-review-specific usage

(x-post platform + governance + bmo, please followup-to governance) Today I was asked for super-review. Although I've been around a while, I am not a super-reviewer. I can't remember the last time before today that I was asked (it's quite possibly: never). The person who asked me was mostly ju

Re: ESlint rule 'no-arbitrary-setTimeout' enabled on xpcshell tests

Ah, good to know! I'll file a follow-up to enable the eslint rule on browser/a11y/chrome. Maybe eventually we can just replace the requestFlakyTimeout mechanism with this eslint rule. I decided to punt on that as I'm not sure if eslint is running on 100% of mochitests yet. On Fri, Jul 28, 2017 at

Re: ESlint rule 'no-arbitrary-setTimeout' enabled on xpcshell tests

I'll note that requestFlakyTimeout is only enabled for mochitest-plain at the moment: http://searchfox.org/mozilla-central/source/testing/ mochitest/tests/SimpleTest/SimpleTest.js#666 So browser-chrome / a11y / chrome tests are still able to use non-0 timeouts. Cheers, Felipe On Fri, Jul 28, 2017

ESlint rule 'no-arbitrary-setTimeout' enabled on xpcshell tests

As part of a larger effort to reduce oranges, we are starting to lint our tests for common causes of intermittent failures. One low-hanging fruit is preventing setTimeout with an arbitrary value (aka non-zero) as opposed to waiting for an appropriate event. The mochitest harness already prevents th

new locking primitive: RecursiveMutex

Earlier this week, bug 1347963 landed, introducing a new mozilla::RecursiveMutex type. A RecursiveMutex instance may be acquired on the same thread while said thread is already holding the lock; such behavior with mozilla::Mutex would result in deadlocks. While we already have a recursively-acqui

Re: Heads up! Building Stylo in local developer builds

On Fri, Jul 28, 2017 at 01:04:21AM -0700, Chris Peterson wrote: > Stylo support (pref'd off) has been built in automation builds for a couple > weeks. Ralph Giles just landed bug 1384258 to also build Stylo support > (pref'd off) in local developer builds, too. You should rerun `mach > bootstrap` t

Heads up! Building Stylo in local developer builds

Stylo support (pref'd off) has been built in automation builds for a couple weeks. Ralph Giles just landed bug 1384258 to also build Stylo support (pref'd off) in local developer builds, too. You should rerun `mach bootstrap` to make sure you have the latest versions of the Stylo and Rust depen

Intent to remove: prerendering

There's an experimental framework to support behind a preference implemented last year [1]. We ceased to work on it after realizing it's unlikely to benefit users as Chromium team indicated the usage rate is low and Chromium was going to remove it [2]. We'll clean up the code after 57 release