Shipping Headless Firefox on Linux

Hello All, As of Firefox 55 I intend to ship headless Linux support (Firefox without a GUI and X11 server connection). Headless mode is enabled via the --headless command line flag for Firefox and does not affect Firefox when running in normal mode or on Windows and macOS For those unfamiliar

Re: Proposal for informing Developers and Sheriffs about new Testsuites

On Wed, Jun 14, 2017 at 1:58 AM, Carsten Book wrote: > Hi, > > we had the case that a new testsuite was enabled and one test of that > suite resulted in a new perma orange failure. Its a tier-2 testsuite but of > course also tier 2 cause additional work for sheriffs. > > The Problem on new Testsu

Re: Proposal for informing Developers and Sheriffs about new Testsuites

On Wednesday, June 14, 2017 at 1:58:39 AM UTC-7, Carsten Book wrote: > Hi, > > we had the case that a new testsuite was enabled and one test of that suite > resulted in a new perma orange failure. Its a tier-2 testsuite but of > course also tier 2 cause additional work for sheriffs. > > The Probl

Re: Changing .idl files

On Wed, Jun 14, 2017 at 2:14 PM, Andrew Swan wrote: > Sorry, this was misleading, I meant this as a narrow comment about the > (still hypothetical!) scenario where something is prototyped as an > experiment but we're in the process of landing it in m-c along with all the > other built-in apis. Of

Re: The future of commit access policy for core Firefox

Responding to an old thread... (had saved as draft but didn't realize I hadn't sent). Only replying to .platform here since last time I cross-post-replied it didn't show up. >I want to explicitly state that we're moving towards >N=~10 people having raw push access to the Firefox repos with the ma

Re: JSBC: JavaScript Start-up Bytecode Cache

On Tue, Jun 13, 2017 at 11:54:17PM -0400, Boris Zbarsky wrote: On 6/13/17 5:23 PM, Kris Maglione wrote: For

Re: [Sheriffs] Proposal for informing Developers and Sheriffs about new Testsuites

Or if you must enable it in tree for try ahead of it being ready, enable it as *tier 3* that way, those of you who *do* care can look at results, while the rest of the dev audience can be ignorant to it, and happily so. (Some reasons for enable in tree ahead of ready, could be to help keep co

Re: Changing .idl files

On Wed, Jun 14, 2017 at 01:49:28PM -0400, Boris Zbarsky wrote: On 6/14/17 12:23 PM, Andrew Swan wrote: I would hope that if we have promising or widely used webextension experiments, that the relevant peers would be aware of them when reviewing changes that might affect them I don't see how th

Re: Changing .idl files

On Wed, Jun 14, 2017 at 10:49 AM, Boris Zbarsky wrote: > On 6/14/17 12:23 PM, Andrew Swan wrote: > >> I would hope that if we have promising or widely used webextension >> experiments, that the relevant peers would be aware of them when reviewing >> changes that might affect them >> > > I don't s

Re: Proposal for informing Developers and Sheriffs about new Testsuites

Related to this, I would like to ask that people not enabled test suites on try if they're orange. I've wasted a lot of time myself trying to understand failures that were not my fault, and I know other people have too. Since new tests suites are presumably being enabled through TaskCluster and do

Re: Changing .idl files

On 6/14/17 12:23 PM, Andrew Swan wrote: I would hope that if we have promising or widely used webextension experiments, that the relevant peers would be aware of them when reviewing changes that might affect them I don't see how they would be, unless we have something like dxr for the relevant

Re: Changing .idl files

On 06/14/2017 10:35 AM, Andrew Swan wrote: On Wed, Jun 14, 2017 at 10:07 AM, Nathan Froyd > wrote: On Wed, Jun 14, 2017 at 12:54 PM, Steve Fink mailto:sf...@mozilla.com>> wrote: > Whoa. Experiments aren't tested in automation? Whoa. We're going to still

Re: Changing .idl files

Right. But in my mind, "not tested in automation" ~= "always broken". And if I understand the whole addon picture correctly (unlikely), then WebExtension Experiments is basically our only answer to the mountain of legacy extensions that we're breaking. (Not that it fixes them, just that it's th

Re: Changing .idl files

On Wed, Jun 14, 2017 at 10:07 AM, Nathan Froyd wrote: > On Wed, Jun 14, 2017 at 12:54 PM, Steve Fink wrote: > > On 06/14/2017 09:23 AM, Andrew Swan wrote: > >> I would hope that if we have promising or widely used webextension > >> experiments, that the relevant peers would be aware of them when

Re: Changing .idl files

WebExtension Experiments are a way to write WebExtension APIs without having to write an API in mozilla-central. There are no WebExtension Experiments enabled on release. They have been enabled on release in Firefox 55 for a restricted set of users *only*. Basically, Test Pilot. When that team pr

Re: Changing .idl files

On Wed, Jun 14, 2017 at 12:54 PM, Steve Fink wrote: > On 06/14/2017 09:23 AM, Andrew Swan wrote: >> I would hope that if we have promising or widely used webextension >> experiments, that the relevant peers would be aware of them when reviewing >> changes that might affect them but of course chang

Re: Changing .idl files

On 06/14/2017 09:23 AM, Andrew Swan wrote: I don't think this will be a big deal. Note that users will also be able to run legacy addons (which can access xpcom) in Nightly with a preference flipped. We've tried to be clear in communication to extension developers that once 57 comes around, we

Re: Changing .idl files

On Wed, Jun 14, 2017 at 7:09 AM, Ehsan Akhgari wrote: > [6] Note that it's not clear yet how we will be able to remove XPCOM APIs > post-57 due to the existence of WebExtensions Experiments < > https://webextensions-experiments.readthedocs.io/en/latest/>. I'm not > sure who's going to make the ca

Re: Proposal for informing Developers and Sheriffs about new Testsuites

Isn't this the sort of thing m.d.tree-management is for? I would say that + sheriffs@ should be enough. Will On 2017-06-14 10:37 AM, Carsten Book wrote: i guess sheriffs list (sheriffs @ m.o ) and newsgroup dev.platform, fx -dev but i'm also open for suggetions from others :) - tomcat On Wed

Re: Proposal for informing Developers and Sheriffs about new Testsuites

i guess sheriffs list (sheriffs @ m.o ) and newsgroup dev.platform, fx -dev but i'm also open for suggetions from others :) - tomcat On Wed, Jun 14, 2017 at 4:12 PM, Kartikaya Gupta wrote: > This sounds good to me. What mailing lists should the intent email be > sent to? It might help to have a

Re: Proposal for informing Developers and Sheriffs about new Testsuites

This sounds good to me. What mailing lists should the intent email be sent to? It might help to have a template somewhere as well. On Wed, Jun 14, 2017 at 4:58 AM, Carsten Book wrote: > Hi, > > we had the case that a new testsuite was enabled and one test of that suite > resulted in a new perma o

Re: Changing .idl files

On 06/14/2017 09:02 AM, Benjamin Smedberg wrote: On Tue, Jun 13, 2017 at 8:40 PM, Nicholas Nethercote wrote: (3) Do extensions use it? If so, changing it probably isn't possible. This can be imperfectly determined by searching through addons/ in DXR. There is no rule that we can't break old-

Re: Changing .idl files

On Tue, Jun 13, 2017 at 8:40 PM, Nicholas Nethercote wrote: > > (3) Do extensions use it? If so, changing it probably isn't possible. This > can > be imperfectly determined by searching through addons/ in DXR. > There is no rule that we can't break old-style addons: it just makes the change risk

Fwd: Advisory Communication: TaskCluster MAC OSX Test Migration Activity Scheduled

Hi Team, Please be advised that we are in the process of migrating OS X continuous integration tests from Buildbot to TaskCluster. This work is being tracked in Bug 1372229 and will take place from June 13th to 15th. There should be no developer impact, but if you experience any problems, please n

Re: JSBC: JavaScript Start-up Bytecode Cache

On 06/13/2017 09:38 PM, Mike Hommey wrote: On Tue, Jun 13, 2017 at 12:10:58PM -0400, Boris Zbarsky wrote: On 6/13/17 11:00 AM, Dirkjan Ochtman wrote: Has anyone thought about doing similar things for chrome JS? We've been doing fastload for chrome JS (and indeed for entire chrome XUL document

Re: JSBC: JavaScript Start-up Bytecode Cache

On 06/13/2017 08:36 PM, Chris Peterson wrote: Nicolas, when JSBC is enabled by default, should we change our test procedure for our various page load tests (Talos and Softvision's manual testing)? Since the first page load will be slower than subsequent page loads (as you noted in the bug [1]),

Proposal for informing Developers and Sheriffs about new Testsuites

Hi, we had the case that a new testsuite was enabled and one test of that suite resulted in a new perma orange failure. Its a tier-2 testsuite but of course also tier 2 cause additional work for sheriffs. The Problem on new Testsuite is that Sheriffs are in a lot of cases not informed about that