Shipping Headless Firefox on Linux

[Brendan Dahl]

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 with the project, the main goal of headless browsing
is to make web developer workflow and testing with Firefox easier. There
are currently two ways to interact with headless Firefox by using either
SlimerJS or Marionette (WebDriver/Selenium).



Testing:

The Marionette test suite is now run in headless mode alongside the normal
mode as a tier 2 test on try. There are also some basic xpcshell tests that
use a simple headless browser. If the Marionette tests remain reliable, I
intend to bump them up to tier 1 in a few weeks [1].



In the near future, I'll also be enabling headless mode on Windows and then
will start work on macOS. We also are going to investigate some possible
performance improvements for headless mode.



If you run into any issues please file a bug in the new headless component
[2].



More info:



Meta bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1338004

Linux support: https://bugzilla.mozilla.org/show_bug.cgi?id=1356681

Windows support: https://bugzilla.mozilla.org/show_bug.cgi?id=1355150

MacOS support: https://bugzilla.mozilla.org/show_bug.cgi?id=1355147

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1373029

[2]:
https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox=Headless
.



Previous blog post on SlimerJS support:
https://adriftwith.me/coding/2017/04/21/headless-slimerjs-with-firefox/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal for informing Developers and Sheriffs about new Testsuites

[Nicholas Alexander]

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 Testsuite is that Sheriffs are in a lot of cases not
> informed about that new testsuite (so we need to find out who to contact
> etc) and also it affects Developers because they might be confused why
> their try run is showing a orange result they don't even know of (and waste
> time in finding out if that test is red/orange because of their change).
>
> So i propose:
>
> People should email with an intent to implement when adding a new
> platform/suite, and that email should contain links to docs/wiki/... and
> the persons (in a super optimal case more than one just for timezone
> coverage if sheriffs have question) we can contact in case of questions.
>
> this would benefit in :
>
> 1) sheriffs will know who to speak to if it's failing or needs to be
> hidden - so we can assign bugs or even ping people directly on irc
> 2) developers know what this new test is when they break it on their try
> push and so save time and resources if the failure is known and sheriffs or
> others can point to a bug/newsgroup mail
> 3) discussions can be had about any overlap the new tests have with other
> suites or say deciding what platforms it should run on etc
>
> I guess this would help Sheriffs and Developers. I initially was thinking
> about about a changelog on treeherder for such changes but that have the
> disadvantage that this would not include all the information we need to
> contact someone etc
>

> I hope that this proposal make sense.
>

There are requirements for the tiers already laid out that have not been
linked in this thread:

https://wiki.mozilla.org/Sheriffing/Job_Visibility_Policy

I found the requirements clear but onerous.

I am actively pushing a set of testsuites across the tier 2 to tier 1
boundary as we speak (for those interested in what's involved, see [1]).  I
was planning to get a sheriff's review of all the various pieces
(documentation, failure messages, etc) by flagging an individual sheriff,
but it would be better to have an intent-to-change-tier email for broader
discussion.

Nick

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1372075 and especially
https://bugzilla.mozilla.org/show_bug.cgi?id=1370539#c3
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal for informing Developers and Sheriffs about new Testsuites

[bdahl]

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 Problem on new Testsuite is that Sheriffs are in a lot of cases not
> informed about that new testsuite (so we need to find out who to contact
> etc) and also it affects Developers because they might be confused why
> their try run is showing a orange result they don't even know of (and waste
> time in finding out if that test is red/orange because of their change).
> 
> So i propose:
> 
> People should email with an intent to implement when adding a new
> platform/suite, and that email should contain links to docs/wiki/... and
> the persons (in a super optimal case more than one just for timezone
> coverage if sheriffs have question) we can contact in case of questions.
> 
> this would benefit in :
> 
> 1) sheriffs will know who to speak to if it's failing or needs to be hidden
> - so we can assign bugs or even ping people directly on irc
> 2) developers know what this new test is when they break it on their try
> push and so save time and resources if the failure is known and sheriffs or
> others can point to a bug/newsgroup mail
> 3) discussions can be had about any overlap the new tests have with other
> suites or say deciding what platforms it should run on etc
> 
> I guess this would help Sheriffs and Developers. I initially was thinking
> about about a changelog on treeherder for such changes but that have the
> disadvantage that this would not include all the information we need to
> contact someone etc
> 
> I hope that this proposal make sense.
> 
> Cheers,
> - Tomcat

Could new test suites default to tier 3? If so, then sheriffs would know of 
changes when bugs are opened to raise the tier. Seems much more reliable then 
expecting everyone to remember to email the sheriffs.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[Nathan Froyd]

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 course we can't/don't expect reviewers to be aware
> of every small experiment that is out there.  And again, we've communicated
> to extension developers that they cannot rely on stable internal
> interface.  And finally, I agree with sfink and nfroyd that the only way to
> really be able to depend on experiments at a larger scale is to get them
> into automation.  I personally pledge not to complain about any changes
> that break out-of-tree code until then... :)

Thank you for clarifying this!

-Nathan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: The future of commit access policy for core Firefox

[Randell Jesup]

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 majority
>of landings occurring via autoland (via Conduit via MozReview/Bugzilla).
>This reduces our attack surface area (less exposure to compromised SSH
>keys),

Reducing our attack surface is (on the surface) good... but...

>establishes better auditing (history of change will be on
>Bugzilla/MozReview and not on a random local machine),

I presume you mean rebases and nit-handling. I see this as unimportant.

>eliminates potential
>for bugs or variance with incorrect rebasing done on local machines,

Ok, but I don't see this as critical, and rarely if ever see issues with this.

>and allows us to do extra things as part of the landing/rebase, such as
>automatically reformat code to match unified code styles,

Oh, that is something that would be a *massive* annoyance and likely
involve destroying a bunch of history info (or rather hiding it from
easy access).  

>do binding generation, etc. They say all problems in computer science
>can be solved by another level of indirection.

"Can be" and "Is a good idea" are two very separate things... :-) :-)

>Deferred landing (autoland) is such an
>indirection and it solves a lot of problems.

"A lot of problems" - please, this needs very concrete enumeration and
discussion.  I do see one (SSH key compromise), though this isn't the
only way to deal with that.  The rest listed above I don't see as
compelling when weighed against the costs (direct and indirect) of this
proposal.  I also agree with a lot of when Ehsan said.

Also, the SSH issue - compromised SSH keys are certainly an avenue for
compromise of our binaries, but there are a whole bunch more ways that
could still happen, ways that don't leave the forensic trails checkins
would (as ekr mentioned).  How many times (that we know of) has SSH
compromise led to a rogue checkin that got to release? (feel free to
answer that privately, for anyone who knows.)

>It will be happening. Most of
>us will lose access to push directly to the Firefox repos. We won't be
>losing ability to initiate a push, however. For the record, I'm not in
>favor of making this change until the tooling is such that it won't be a
>significant workflow/productivity regression. This is a reason why it
>hasn't been made yet.

I don't see how this proposal will achieve the goal you state as a
blocker.  (E.g. ehsan's and other's comments.)

>A handful have commented on whether a rebase invalidates a previous r+.
>This is a difficult topic. Strictly speaking, a rebase invalidates
>everything because a change in a commit being rebased over could invalidate
>assumptions. Same goes for a merge commit. In reality, most rebases are
>harmless and we shouldn't be concerned with their existence.

This speaks against some of the benefits mentioned above.

>In the cases where it does matter, we can help prevent things from
>falling through the cracks by having the review tool detect when
>in-flight reviews touch the same files / topics and route them to the
>same reviewer(s) and/or notify the different reviewer(s) so people are
>aware of potential for conflict.  This feature was conceived before
>MozReview launched but (sadly) hasn't been implemented.

I can't imagine how this will work (and be effective) in practice.

>There have been a few comments on interdiffs when rebases are in play. I
>want to explicitly state that there is no single "correct" way to display a
>diff much less an interdiff much less an interdiff when a rebase is
>involved. This is why tools like Git have multiple diffing algorithms
>(minimal, patience, histogram, Myers). This is why there are different ways
>of rendering a diff (unified, side-by-side, 3-way). Rendering a simple diff
>is hard. Rendering an interdiff is harder. Unfortunately, central review
>tools force a specific rendering on users. ReviewBoard does allow some
>tweaking of diff behavior (such as ignore whitespace). But no matter what
>options you use, someone will be unhappy with it. An example is MozReview's
>handling of interdiffs. It used to hide lines changed by a rebase that
>weren't changed in the commit up for review. But that was slightly buggy in
>some situations and some people wanted to actually see those changes, so
>the behavior was changed to show all file changes in the interdiff. This
>made a different set of people unhappy because the changes were spurious
>and contributed noise. In summary, you can't please all the people all the
>time. So you have to pick a reasonable default then debate about adding
>complexity to placate the long tail or handle corner cases. Standard
>product design challenges. On top of that, technical users are the 1% and
>are a very difficult crowd to please.

I've dealt with these 

Re: JSBC: JavaScript Start-up Bytecode Cache

[Kris Maglione]

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

[Justin Wood]

 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
context for work that could be bitrotted easily. And to help share work
among multiple developers without needing a patchset that continuously gets
rebased.)

On Wed, Jun 14, 2017 at 2:14 PM, Bill McCloskey 
wrote:

> 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 don't require changes to the buildbot-config repo, is there any reason
> to enable a test suite if it's not already green? It seems like you can
> just do custom try pushes until it's green.
>
> -Bill
>
>
> On Wed, Jun 14, 2017 at 8:01 AM, William Lachance 
> wrote:
>
>> 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, 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 template somewhere as well.

 ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
> ___
> Sheriffs mailing list
> sheri...@mozilla.org
> https://mail.mozilla.org/listinfo/sheriffs
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[Kris Maglione]

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 they would be, unless we have something like dxr for 
the relevant code.


As a concrete example, how would a necko peer know that some 
webextension experiment uses or doesn't use various necko interfaces?


Currently, we don't allow experiments on release builds. Or, to 
be technically accurate, we allow them on release builds as of 
55 if they're signed by AMO, but AMO does not currently support 
signing them.


When we've talked about allowing them on release builds in the 
past, the consensus has always been that they'd need to be 
reviewed by appropriate Firefox or Platform peers before being 
published, and we would have the appropriate ownership to update 
them as necessary to maintain compatibility.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[Andrew Swan]

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 see how they would be, unless we have something like dxr for the
> relevant code.
>
> As a concrete example, how would a necko peer know that some webextension
> experiment uses or doesn't use various necko interfaces?


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 course we can't/don't expect reviewers to be aware
of every small experiment that is out there.  And again, we've communicated
to extension developers that they cannot rely on stable internal
interface.  And finally, I agree with sfink and nfroyd that the only way to
really be able to depend on experiments at a larger scale is to get them
into automation.  I personally pledge not to complain about any changes
that break out-of-tree code until then... :)

-Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal for informing Developers and Sheriffs about new Testsuites

[Bill McCloskey]

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
don't require changes to the buildbot-config repo, is there any reason to
enable a test suite if it's not already green? It seems like you can just
do custom try pushes until it's green.

-Bill


On Wed, Jun 14, 2017 at 8:01 AM, William Lachance 
wrote:

> 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, 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 template somewhere as well.
>>>
>>> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[Boris Zbarsky]

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 code.


As a concrete example, how would a necko peer know that some 
webextension experiment uses or doesn't use various necko interfaces?


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[Steve Fink]

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 > wrote:
> Whoa. Experiments aren't tested in automation?

Whoa.  We're going to still have to think about interface compat with
external clients in a post-57 world?  This is the first I've heard of
this.

> Can they be, please? At least snapshotted versions.

+1  Almost anything automation-related would be better than "hope
peers think hard about this".


I'm not sure what you mean by "they".  We have support in the browser 
for loading experiments, but we don't have a way to sign them for 
running in release.  So some individuals have created experiments that 
they have used locally but there is no centralized list of them and 
none of them are widely used.  Making experiments more usable by 
creating a process for getting experiments reviewed and signed is 
something we'd like to do and a testing strategy certainly needs to be 
part of that.  But realistically that is not going to happen until 57 
is out the door.


Ok, fair enough. I just sort of assumed that Experiments were a more 
actively used thing already, but didn't actually look at current usage. 
Hopefully it'll grow into something more, and we'll have a good story 
for ensuring that they don't continually break. Knowing the current 
state, I guess that addresses my concern. (Well, not the concern that we 
don't have a great story for deeper extensions yet, but at least I 
understand now why CI testing isn't really where we are yet.)


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[Steve Fink]

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 the answer to "yeah, you can't do stuff like that anymore in 
Firefox".)


I don't want to hold up an always broken solution as our defense against 
the claim that we've completely nerfed our extension capabilities. If 
it's the most realistic path forward for any addon that extends in 
currently unsupported places, then it would behoove us to make it truly 
realistic. (If, instead, we decided to tell people wanting additional 
extension points that they need to land them directly in gecko, then 
fine, but my understanding is that Experiments is there to provide a 
gentler path.)


It's ok if they break, even, as long as we *know* what's broken and 
aren't in a state where developers have no trust in Experiments actually 
working. "Try it and see, but you'll probably have to fix it before you 
can use it" is not where we want to be.


On 06/14/2017 10:25 AM, Andrew McKay wrote:

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 proposes
pushing out an experiment to release, the usual release process for
that team will take place.

There is no need to think about interface compatibility in the future
with external clients.



On 14 June 2017 at 10:07, 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 reviewing
changes that might affect them but of course changing IDL bindings is only
one of a number of ways that a change to central could break an existing
experiment.  This is one of the drawbacks of having out-of-tree code, I
think its up to us (the webextensions maintainers) to either deal with
this
or get experiments worked into automation if this becomes a real problem
in
practice.

Whoa. Experiments aren't tested in automation?

Whoa.  We're going to still have to think about interface compat with
external clients in a post-57 world?  This is the first I've heard of
this.


Can they be, please? At least snapshotted versions.

+1  Almost anything automation-related would be better than "hope
peers think hard about this".

-Nathan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[Andrew Swan]

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
> reviewing
> >> changes that might affect them but of course changing IDL bindings is
> only
> >> one of a number of ways that a change to central could break an existing
> >> experiment.  This is one of the drawbacks of having out-of-tree code, I
> >> think its up to us (the webextensions maintainers) to either deal with
> >> this
> >> or get experiments worked into automation if this becomes a real problem
> >> in
> >> practice.
> >
> > Whoa. Experiments aren't tested in automation?
>
> Whoa.  We're going to still have to think about interface compat with
> external clients in a post-57 world?  This is the first I've heard of
> this.
>
> > Can they be, please? At least snapshotted versions.
>
> +1  Almost anything automation-related would be better than "hope
> peers think hard about this".
>

I'm not sure what you mean by "they".  We have support in the browser for
loading experiments, but we don't have a way to sign them for running in
release.  So some individuals have created experiments that they have used
locally but there is no centralized list of them and none of them are
widely used.  Making experiments more usable by creating a process for
getting experiments reviewed and signed is something we'd like to do and a
testing strategy certainly needs to be part of that.  But realistically
that is not going to happen until 57 is out the door.

More generally, I think the principle that we can't complain about internal
changes that break out-of-tree code if nothing breaks in automation is fair
(speaking from the webextensions perspective, not for devtools, test pilot,
etc) and we're not asking for any exception from that rule.  Or, as a more
direct answer to nfroyd: no, you don't need to think about compatibility
with out-of-tree code post-57 (at least as far as extensions are concerned).

-Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[Andrew McKay]

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 proposes
pushing out an experiment to release, the usual release process for
that team will take place.

There is no need to think about interface compatibility in the future
with external clients.



On 14 June 2017 at 10:07, 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 reviewing
>>> changes that might affect them but of course changing IDL bindings is only
>>> one of a number of ways that a change to central could break an existing
>>> experiment.  This is one of the drawbacks of having out-of-tree code, I
>>> think its up to us (the webextensions maintainers) to either deal with
>>> this
>>> or get experiments worked into automation if this becomes a real problem
>>> in
>>> practice.
>>
>> Whoa. Experiments aren't tested in automation?
>
> Whoa.  We're going to still have to think about interface compat with
> external clients in a post-57 world?  This is the first I've heard of
> this.
>
>> Can they be, please? At least snapshotted versions.
>
> +1  Almost anything automation-related would be better than "hope
> peers think hard about this".
>
> -Nathan
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[Nathan Froyd]

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 changing IDL bindings is only
>> one of a number of ways that a change to central could break an existing
>> experiment.  This is one of the drawbacks of having out-of-tree code, I
>> think its up to us (the webextensions maintainers) to either deal with
>> this
>> or get experiments worked into automation if this becomes a real problem
>> in
>> practice.
>
> Whoa. Experiments aren't tested in automation?

Whoa.  We're going to still have to think about interface compat with
external clients in a post-57 world?  This is the first I've heard of
this.

> Can they be, please? At least snapshotted versions.

+1  Almost anything automation-related would be better than "hope
peers think hard about this".

-Nathan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[Steve Fink]

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 won't be making any efforts to keep internal
interfaces stable for addons so they shouldn't be surprised when interfaces
change.  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 changing IDL bindings is only
one of a number of ways that a change to central could break an existing
experiment.  This is one of the drawbacks of having out-of-tree code, I
think its up to us (the webextensions maintainers) to either deal with this
or get experiments worked into automation if this becomes a real problem in
practice.



Whoa. Experiments aren't tested in automation?

Can they be, please? At least snapshotted versions.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[Andrew Swan]

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 call on which APIs we'd want to retain for
> those WebExtensions and which APIs we'd want to freely modify/remove after
> 57.


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 won't be making any efforts to keep internal
interfaces stable for addons so they shouldn't be surprised when interfaces
change.  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 changing IDL bindings is only
one of a number of ways that a change to central could break an existing
experiment.  This is one of the drawbacks of having out-of-tree code, I
think its up to us (the webextensions maintainers) to either deal with this
or get experiments worked into automation if this becomes a real problem in
practice.

-Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal for informing Developers and Sheriffs about new Testsuites

[William Lachance]

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, 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 template somewhere as well.


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal for informing Developers and Sheriffs about new Testsuites

[Carsten Book]

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 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 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 new testsuite (so we need to find out who to contact
> > etc) and also it affects Developers because they might be confused why
> > their try run is showing a orange result they don't even know of (and
> waste
> > time in finding out if that test is red/orange because of their change).
> >
> > So i propose:
> >
> > People should email with an intent to implement when adding a new
> > platform/suite, and that email should contain links to docs/wiki/... and
> > the persons (in a super optimal case more than one just for timezone
> > coverage if sheriffs have question) we can contact in case of questions.
> >
> > this would benefit in :
> >
> > 1) sheriffs will know who to speak to if it's failing or needs to be
> hidden
> > - so we can assign bugs or even ping people directly on irc
> > 2) developers know what this new test is when they break it on their try
> > push and so save time and resources if the failure is known and sheriffs
> or
> > others can point to a bug/newsgroup mail
> > 3) discussions can be had about any overlap the new tests have with other
> > suites or say deciding what platforms it should run on etc
> >
> > I guess this would help Sheriffs and Developers. I initially was thinking
> > about about a changelog on treeherder for such changes but that have the
> > disadvantage that this would not include all the information we need to
> > contact someone etc
> >
> > I hope that this proposal make sense.
> >
> > Cheers,
> > - Tomcat
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal for informing Developers and Sheriffs about new Testsuites

[Kartikaya Gupta]

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 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 new testsuite (so we need to find out who to contact
> etc) and also it affects Developers because they might be confused why
> their try run is showing a orange result they don't even know of (and waste
> time in finding out if that test is red/orange because of their change).
>
> So i propose:
>
> People should email with an intent to implement when adding a new
> platform/suite, and that email should contain links to docs/wiki/... and
> the persons (in a super optimal case more than one just for timezone
> coverage if sheriffs have question) we can contact in case of questions.
>
> this would benefit in :
>
> 1) sheriffs will know who to speak to if it's failing or needs to be hidden
> - so we can assign bugs or even ping people directly on irc
> 2) developers know what this new test is when they break it on their try
> push and so save time and resources if the failure is known and sheriffs or
> others can point to a bug/newsgroup mail
> 3) discussions can be had about any overlap the new tests have with other
> suites or say deciding what platforms it should run on etc
>
> I guess this would help Sheriffs and Developers. I initially was thinking
> about about a changelog on treeherder for such changes but that have the
> disadvantage that this would not include all the information we need to
> contact someone etc
>
> I hope that this proposal make sense.
>
> Cheers,
> - Tomcat
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[Ehsan Akhgari]

On 06/14/2017 09:02 AM, Benjamin Smedberg wrote:

On Tue, Jun 13, 2017 at 8:40 PM, Nicholas Nethercote . I'm not 
sure who's going to make the call on which APIs we'd want to retain for 
those WebExtensions and which APIs we'd want to freely modify/remove 
after 57.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[Benjamin Smedberg]

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 riskier and may require outreach or an addon validation step. So
it's a question of risk/reward tradeoff.

Given that old-style addons are going away for 57, if it's possible to
delay addon-breaking IDL changes by one release until 57 that's probably
the easiest way to deal with this. We're already causing the addon
community a lot of churn.


>
> (4) Does Thunderbird use it? This is no longer a hard constraint, but is
> something to consider.
>

In general our policy is that we should spend only minimal time worrying
about this. A courtesy note to tbird devs is nice.


> (Although, if DevTools are moved its their own repository, that repo will
> have to be
> checked as well?)
>

I've been trying to find out some technical details about the devtools
plan, but my initial understanding is that they are trying to target stable
web/webextensions/debugger API surfaces, and so they *shouldn't* be
affected by gecko internals changes. But I'd be a lot more comfortable if
that were in writing as part of the devtools plan.

--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Randi Schell]

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 notify someone in the #taskcluster irc channel

Please let me know if you have any questions.
Thanks,
RS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: JSBC: JavaScript Start-up Bytecode Cache

[Nicolas B. Pierron]

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
documents, including their scripts) for 15+ years now, no?


I don't remember what fastload was keeping around, but startupcache
stores pre-parsed JS, but I'm not sure of the details, whether that's
some AST or something else. Storing bytecode instead could still be a
win.


Looking at the implementation of nsXULPrototypeScript::Deserialize, we use 
the same methods (XDR) as used by JSBC, i-e we encode/decode the bytecode.


--
Nicolas B. Pierron
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: JSBC: JavaScript Start-up Bytecode Cache

[Nicolas B. Pierron]

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]), should we throw away the first page 
load time or continue to average it with the subsequent page load times?


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=900784#c72


These results [1] were with the eager encoding of the bytecode, while 
running locally.


Since, I added an intuition-based heuristics which by luck end-up keeping 
the encoding time as part of the ignored set, as we encode as part of the 
5th visit.  Thus giving the following results on tp5 [2].


Depending on how the heuristics are tuned based on telemetry results [3], we 
should either split tp5 results in 2/3 sets, or increase the ignore set size.


If this is not already the case, we should change tp5 benchmark harness to 
wait for the idle-callback before moving to the next page. Otherwise, we 
might repeatedly attempt to encode the bytecode of one page, but never stay 
long enough on the page to save it.


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=900784#c72
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=900784#c113
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1362114

--
Nicolas B. Pierron
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Proposal for informing Developers and Sheriffs about new Testsuites

[Carsten Book]

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 new testsuite (so we need to find out who to contact
etc) and also it affects Developers because they might be confused why
their try run is showing a orange result they don't even know of (and waste
time in finding out if that test is red/orange because of their change).

So i propose:

People should email with an intent to implement when adding a new
platform/suite, and that email should contain links to docs/wiki/... and
the persons (in a super optimal case more than one just for timezone
coverage if sheriffs have question) we can contact in case of questions.

this would benefit in :

1) sheriffs will know who to speak to if it's failing or needs to be hidden
- so we can assign bugs or even ping people directly on irc
2) developers know what this new test is when they break it on their try
push and so save time and resources if the failure is known and sheriffs or
others can point to a bug/newsgroup mail
3) discussions can be had about any overlap the new tests have with other
suites or say deciding what platforms it should run on etc

I guess this would help Sheriffs and Developers. I initially was thinking
about about a changelog on treeherder for such changes but that have the
disadvantage that this would not include all the information we need to
contact someone etc

I hope that this proposal make sense.

Cheers,
- Tomcat
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform