Intent to remove intl.uidirection pref

In Bug 1676137 I'm planning to remove the intl.uidirection pref. This pref was introduced in Bug 1312049 to make it easier to test right-to-left (RTL) locales, but since that time, pseudolocale support has been added to Firefox. For testing purposes, setting the intl.l10n.pseudo preference to

Adding a linter for Fluent files

In Bug 1416149, hopefully landing soon, I'm adding a linter for Fluent files. It checks for invalid strings, as is currently done by the browser_misused_characters_in_strings.js test, and adds a new check to enforce lowercase characters and hyphens in Fluent identifiers. Since this is a newly

In-tree version of webrtc.org build switching from gyp to gn

Our in-tree version of the webrtc.org code is currently built using gyp. Support for gyp was removed from upstream over a year ago and was replaced with gn, requiring us to maintain our own copy of the gyp files in order to do updates. Chris Manchester worked on build system support for gn, which

Re: Intent to restrict to secure contexts: navigator.geolocation

On Tue, Oct 25, 2016 at 3:30 PM, Eric Rescorla wrote: > On Wed, Oct 26, 2016 at 6:17 AM, Chris Peterson > wrote: > > > On 10/25/2016 11:43 AM, Eric Rescorla wrote: > > > >> Setting aside the policy question, the location API for mobile devices > >>

Intent to implement and ship: ConstantSourceNode

*Summary*: This adds a new source node that produces a constant value. It's currently possible to simulate this using other node types (for instance using an AudioBufferSourceNode containing a single value that has been set to loop) but it would be easier for developers to have a node type

Intent to implement and ship: RTCDTMFSender

Summary: DTMF allows for WebRTC to interact with traditional telephone networks by generating phone keypad tones over an audio channel. It will be implemented as an additional interface on the RTPRtcSender object associated with a peer connection. DTMF is currently supported in Chrome, although

Re: Intent to implement and ship: IIRFilterNode

On Wed, Apr 27, 2016 at 6:35 PM, Karl Tomlinson <mozn...@karlt.net> wrote: > Daniel Minor writes: > > > Summary: This provides an alternative to using BiquadFilterNode when > > odd-order filters are required or automation is not needed. It is part of > > the

Intent to implement and ship: IIRFilterNode

Summary: This provides an alternative to using BiquadFilterNode when odd-order filters are required or automation is not needed. It is part of the Web Audio spec and is already implemented in Blink. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1265408 Link to standard:

Re: MozReview/Autoland in degraded state

And autoland to inbound is now enabled as well. On Tue, Feb 9, 2016 at 11:40 AM, Daniel Minor <dmi...@mozilla.com> wrote: > Try integration is now restored. > > Autoland to inbound will be available pending some further testing. > > On Fri, Feb 5, 2016 at 5:34 PM, Gregory Sz

Re: MozReview/Autoland in degraded state

Try integration is now restored. Autoland to inbound will be available pending some further testing. On Fri, Feb 5, 2016 at 5:34 PM, Gregory Szorc wrote: > r+ carry forward/"status" column is now working again. > > Autoland / Try integration is still offline. > > On Fri, Feb

Requiring a try job prior to autolanding to inbound

One of our goals for autoland is to replace the "checkin-needed" process that is currently done manually by the sheriffs. We still have a few bugs to fix before this is ready, for instance, approval for autolanding is not carried forward for some users if they amend their patch. Another

Re: Requiring a try job prior to autolanding to inbound

On Fri, Jan 22, 2016 at 8:00 AM, Andreas Tolfsen wrote: > Overall I think this idea makes sense. Is it your intention that the > try run should be 100% complete, or just that one exists and is > associated with the review? In some cases I find myself invoking > Autoland when

Re: Removing 'jit-tests' from make check

| to mach check-spidermonkey. It sounds like you've got it under control, but please ping me if you want input. Cheers, Terrence On 04/04/2014 05:44 AM, Daniel Minor wrote: Hi Nicolas, This change only affects running the jit-test test suite as part of make check. This doesn't affect

Removing 'jit-tests' from make check

Hello, Just a heads up that very soon we'll be removing jit-tests from the make check target[1]. The tests have been split out into a separate test job on TBPL[2] (labelled Jit), have been running on Cedar for several months, and have been recently turned on for other trees. We've added a mach

Re: Removing 'jit-tests' from make check

. Thanks, Dan - Original Message - From: Nicolas B. Pierron nicolas.b.pier...@mozilla.com To: dev-platform@lists.mozilla.org Sent: Friday, April 4, 2014 8:31:32 AM Subject: Re: Removing 'jit-tests' from make check On 04/04/2014 03:39 AM, Daniel Minor wrote: Just a heads up that very soon

Re: Removing 'jit-tests' from make check

Hi Ehsan, You might be interested in Bug 992323, where we're planning to move the rest of the useful bits of 'make check' (that aren't build system tests) elsewhere. Thanks, Dan - Original Message - From: Ehsan Akhgari ehsan.akhg...@gmail.com To: Daniel Minor dmi...@mozilla.com, dev

Re: CPP_UNIT_TESTS being removed from make check

As far as I know this has not be set up, but it is definitely a good idea. I filed bug 961707. Cheers, Dan - Original Message - From: Chris Pearce cpea...@mozilla.com To: dev-platform@lists.mozilla.org Sent: Sunday, January 19, 2014 11:11:47 PM Subject: Re: CPP_UNIT_TESTS being removed