Re: Intent to ship: Retained Display Lists

[Ben Kelly]

On Oct 26, 2017 12:15 AM,  wrote:

On Monday, October 9, 2017 at 1:22:55 PM UTC+13, Matt Woodrow wrote:
> We're planning on landing the code for retaining display lists in 58,
> behind the pref layout.display.list.retain.
>

This has now landed in Nightly, and looks to be working really well.

We'd really appreciate some early feedback, so feel free to set
layout.display-list.retain=true and give it a try!


Anecdotely this pref seems to make twitter much less janky on fennec on my
Nexus 5x.

What's the plan for enabling by default?

Thanks!

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

Re: De-XBL Plans

[Bobby Holley]

As one of the lonely few peers for our XBL implementation, I am thrilled
that this is finally happening. My deepest gratitude to everyone involved!

bholley


On Tue, Oct 31, 2017 at 3:06 PM, Dave Townsend 
wrote:

> Having not heard any show-stopping concerns with the plan we will start to
> proceed with it. In Q4 we intend to:
>
> - Migrate a few bindings and update the plan based on what we learn
> - Land XUL support for Custom Elements
> - Create tooling to make converting bindings easier
> - Begin a bug breakdown for individual bindings
>
> You can follow this work at the meta bug 1397874. Bgrins has made a
> public blog post about our plans[1], please reach out to him if you’re
> interested in contributing.
>
> [1] https://briangrinstead.com/blog/xbl-in-firefox/
>
> On Fri, Oct 20, 2017 at 10:47 AM Dave Townsend 
> wrote:
>
> > For some time now we've been talking about moving away from XUL and XBL.
> > The browser architecture team has been hard at work figuring out how to
> > go about doing that and we're ready to share the first of our proposals
> > more widely. We have developed a plan to remove XBL from Firefox. It's
> been
> > through a successful design review with some of the key engineers and now
> > is the time for more comments if you have them. We're planning to start
> some
> > of the work this quarter with it really ramping up next quarter.
> >
> > Take a look at the plan
> >  text/0007-xbl-design-review-packet.html>
> > and let us know what you think. There are a couple of areas where we are
> > still investigating concerns:
> >
> > Performance is of key interest, so we're actively doing experiments to
> > validate that Custom Elements can be as performant as XBL
> > .
> > The plan relies on being able to use Custom Elements in XUL, so we're
> > working on getting a patch
> > for that landed
> > .
> > We have a list of  elements in the product and we're evaluating
> what
> > the future is for them.
> >
> > Are there any other concerns that we're missing?
> >
> ___
> 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: Mapping source files to Bugzilla components

[Gregory Szorc]

On Tue, Oct 24, 2017 at 11:59 AM, Gregory Szorc  wrote:

> Freshly landed in bug 1411343, CI now produces JSON files containing info
> about how source files map to Bugzilla components.
>
> You'll notice a new "Bugzilla" task in Treeherder. It will write some
> artifacts to the "source/source-bugzilla-info" TC Index route. e.g.
> https://tools.taskcluster.net/index/artifacts/gecko.v2.autol
> and.pushlog-id.53952.source/source-bugzilla-info.
>
> Available artifacts include:
>
> * A JSON and gzipped JSON file mapping source files to Bugzilla
> components. e.g. https://index.taskcluster.net/
> v1/task/gecko.v2.autoland.pushlog-id.53952.source.source-
> bugzilla-info/artifacts/public/components.json
> * A JSON and gzipped JSON file listing source files without Bugzilla
> components. e.g. https://public-artifacts.taskc
> luster.net/c2fvXmqEQLy12DsWpXyKyg/0/public/missing.json
>
> The task basically runs various `mach file-info` sub-commands with
> --format=json (a new feature). This is all powered by moz.build Files()
> metadata, which jmaher and others have been curating for the past several
> months.
>
> The JSON files can be a bit large. So I'm not sure if it makes sense to
> actively query them for lookups. But it would certainly be possible to
> import the JSON files into other services, local SQLite databases, to
> facilitate querying.
>
> Given how difficult it is to run the moz.build evaluation feature on
> hg.mozilla.org (https://mozilla-version-control-tools.readthedocs.io/en/
> latest/hgmo/mozbuildinfo.html), I'm really tempted to deprecate that
> service or have it powered by these new JSON files. If you are using this
> service or need to obtain metadata from source files, let me know so I can
> figure out a path forward.
>

Quick update...

The CI task now fails if a file under source control does not have a bug
component defined in moz.build metadata. This could potentially bite people
adding new files to the repo or moving files around. But this is a good
thing: we want every file in the repo to be associated with a bug component
so we know where to file bugs. Add missing metadata is simple: just search
for BUG_COMPONENT in moz.build files for examples.

Also, we now produce a smaller "components-normalized.json" file in
addition to the original "components.json" file. e.g.
https://public-artifacts.taskcluster.net/JDLSmj2XQwmfgRpHUUKFTg/0/public/components-normalized.json.
This /might/ be fast/small enough to load on demand.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Default Rust optimization level decreased from 2 to 1

[Boris Zbarsky]

On 10/31/17 3:21 PM, Gregory Szorc wrote:

It is "wrong" for the set of "people performing profiling."


Just to be clear, that set is "everyone".

Now the set of "people performing profiling on builds they create 
themselves" is a separate question


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

Re: nsAutoConfig

[Nicholas Nethercote]

Thank you for the info! I will leave that code alone :)

Nick

On Wed, Nov 1, 2017 at 2:22 AM,  wrote:

> On Tuesday, October 31, 2017 at 12:10:21 AM UTC-5, Nicholas Nethercote
> wrote:
> > Hi,
> >
> > I was just looking at the extensions/pref/autoconfig/ directory and
> trying
> > to understand what it does.
> >
> > As far as I can tell, the code is there to allow custom deployments with
> > particular prefs set, as described at
> > https://developer.mozilla.org/en-US/Firefox/Enterprise_
> deployment#Configuration
> >
> > It's initialized by modules/libpref/Preferences.cpp if a
> > "general.config.filename" pref is found:
> > http://searchfox.org/mozilla-central/rev/1ebd2eff44617df3b82eea7d2f3ca1
> b60cc591a0/modules/libpref/Preferences.cpp#3907-3920
> >
> > There is also some MozHarness code relating to it here:
> > http://searchfox.org/mozilla-central/source/testing/
> mozharness/mozharness/mozilla/firefox/autoconfig.py
> >
> > Just to check: is this still supported functionality?
> >
> > Thanks.
> >
> > Nick
>
> Yes, this is very much supported functionality. It is our primary means of
> enterprise customization right now.
>
> The reason there are very few tests is because when it was first
> developed, it wasn't possible to write tests that involved putting down
> files before startup. There are some tests now:
>
> http://searchfox.org/mozilla-central/source/extensions/
> pref/autoconfig/test/unit
>
> Mike Kaply
> ___
> 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: PSA: Retiring Bugzilla Socorro Lens

[Anthony Hughes]

Due to an unrelated infrastructure issue the push has been delayed.
Apologies for the delay.

On 30 October 2017 at 13:27, Anthony Hughes  wrote:

> This is a heads up that I am shutting down further development of my
> Bugzilla Socorro Lens add-on. If you're currently using the add-on I
> recommend that you uninstall it and please file issues at
> https://github.com/ashughes1/bmo-bsl.
>
> Over the past few weeks I've been working to integrate the functionality
> it provides natively with bugzilla.mozilla.org. These changes should be
> live as of Tuesday, October 31, 2017. You can read more about this at
> https://ashughes.com/?p=453.
>
> Thank you
>
> --
> Anthony Hughes
> Senior Quality Engineer
> Mozilla Corporation
>



-- 
Anthony Hughes
Senior Quality Engineer
Mozilla Corporation
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Default Rust optimization level decreased from 2 to 1

[Kris Maglione]

On Tue, Oct 31, 2017 at 03:39:39PM -0400, Jeff Muizelaar wrote:

On Tue, Oct 31, 2017 at 3:21 PM, Gregory Szorc  wrote:

It is "wrong" for the set of "people performing profiling." This set is
different from "people compiling Gecko." Which is different from "people who
actually need to compile Gecko." What I'm trying is the new default is "not
wrong" for a large set of people who aren't "people performing profiling."


I say this a bit tongue-in-cheek, but given our big performance push,
hopefully the set of people who aren't profiling is not that large.


I profile when I need to profile (which, if I had to guess, is probably 
more often than the majority of our engineers), but I don't need to 
profile the vast majority of my builds. And for the ones that I do 
profile, the performance of our Rust code is usually not what's 
interesting to me. I expect that the story is different for people who 
mostly work in layout code, but that is a very small minority of us.


What matters more most of the time is that my builds finish quickly. 
Even if I have to occasionally do a clobber build with a different 
configuration, the time and energy saved by most of my builds being 
significantly faster easily pays for it.

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

Re: Default Rust optimization level decreased from 2 to 1

[Ben Kelly]

Would it be possible to have our profiling tools warn if about:compiler
optimization flags are not in about:buildconfig?

On Tue, Oct 31, 2017 at 3:39 PM, Jeff Muizelaar 
wrote:

> On Tue, Oct 31, 2017 at 3:21 PM, Gregory Szorc  wrote:
> > On Tue, Oct 31, 2017 at 12:02 PM, Jeff Muizelaar  >
> > wrote:
> >>
> >> As another piece of evidence in support opt-level=1 being the wrong
> >> default, Glenn also got bitten profiling with the wrong options.
> >> https://github.com/servo/webrender/issues/1817#issuecomment-340553613
> >
> >
> > It is "wrong" for the set of "people performing profiling." This set is
> > different from "people compiling Gecko." Which is different from "people
> who
> > actually need to compile Gecko." What I'm trying is the new default is
> "not
> > wrong" for a large set of people who aren't "people performing
> profiling."
>
> I say this a bit tongue-in-cheek, but given our big performance push,
> hopefully the set of people who aren't profiling is not that large.
>
> -Jeff
> ___
> 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: Default Rust optimization level decreased from 2 to 1

[Jeff Muizelaar]

On Tue, Oct 31, 2017 at 3:21 PM, Gregory Szorc  wrote:
> On Tue, Oct 31, 2017 at 12:02 PM, Jeff Muizelaar 
> wrote:
>>
>> As another piece of evidence in support opt-level=1 being the wrong
>> default, Glenn also got bitten profiling with the wrong options.
>> https://github.com/servo/webrender/issues/1817#issuecomment-340553613
>
>
> It is "wrong" for the set of "people performing profiling." This set is
> different from "people compiling Gecko." Which is different from "people who
> actually need to compile Gecko." What I'm trying is the new default is "not
> wrong" for a large set of people who aren't "people performing profiling."

I say this a bit tongue-in-cheek, but given our big performance push,
hopefully the set of people who aren't profiling is not that large.

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

Re: Default Rust optimization level decreased from 2 to 1

[Kris Maglione]

On Tue, Oct 31, 2017 at 12:21:42PM -0700, Gregory Szorc wrote:

On Tue, Oct 31, 2017 at 12:02 PM, Jeff Muizelaar 
wrote:


As another piece of evidence in support opt-level=1 being the wrong
default, Glenn also got bitten profiling with the wrong options.
https://github.com/servo/webrender/issues/1817#issuecomment-340553613


It is "wrong" for the set of "people performing profiling." This set is
different from "people compiling Gecko." Which is different from "people
who actually need to compile Gecko." What I'm trying is the new default is
"not wrong" for a large set of people who aren't "people performing
profiling."


I'll second this. For months I've had Servo and WebRender disabled in 
most of my builds because they made my compiles so much slower. I tried 
re-enabling them a few weeks ago when I got a new workstation, but gave 
up after most of the compile finished in 7 minutes, and then cargo spent 
another 8 minutes compiling on a single core. I tried some hacks to bump 
the codegen-units setting, but it was heinously difficult, and didn't 
help enough, so I gave up.


I suspect I'm not in the minority here.

After this change, I'm considering re-enabling Servo for my development 
builds.



I'll also second the notion that we need better build system support for 
helping people select the right configuration for the task that they're 
working on, but I think this is a better default for the general case.



My opinion is that this class of failure is a UX failure revolving around
the question of "am I building the thing that should be used for X?" The
build workflow does a horrible job of asking this critical question. The
closest we have is `mach bootstrap` asking if you are building {Firefox,
Fennec} {with, without} artifact builds. And we don't do a good job of
transitioning between `mach bootstrap` or forcing people to run it at all.
So we essentially have nothing forcing people to answer a question that has
critical implications for their ability to adequately develop Firefox.

I have ideas for solving this problem. But to do it in a way that results
in fewer people falling through "my build configuration is sub-optimal and
I didn't know it" cracks, we need to eliminate the concept of a "default
build configuration" and require people to specify a build configuration
(by creating a mozconfig file, etc). This is because the reality is that
there is no single "default build configuration" that is ideal for
everyone. There are more details and some discussion in bug 1410262. I'd
rather we morph that bug as needed than discuss on this mailing list. I'm
happy to discuss on this mailing list eventually: I just want it to be
after we have general agreement on a concrete proposal.





On Thu, Oct 26, 2017 at 2:51 PM, Jeff Muizelaar 
wrote:
> FWIW, WebRender becomes unusable opt-level=1. It also looks like style
> performance takes quite a hit as well which means that our default
> developer builds become unusable for performance work. I worry that
> people will forget this and end up rediscovering only when they look
> at profiles (as mstange just did). What's the use case for a
> --enable-optimize, opt-level=1 build?
>
> -Jeff
>
> On Wed, Oct 25, 2017 at 1:34 PM, Gregory Szorc  wrote:
>> Compiling Rust code with optimizations is significantly slower than
>> compiling without optimizations. As was measured in bug 1411081, the
>> difference between rustc's -Copt-level 1 and 2 on an i7-6700K (4+4
cores)
>> for a recent revision of mozilla-central was 325s/802s wall/CPU versus
>> 625s/1282s. This made Rust compilation during Firefox builds stand out
as a
>> long pole and significantly slowed down builds.
>>
>> Because we couldn't justify the benefits of level 2 for the build time
>> overhead it added, we've changed the build system default so Rust is
>> compiled with -Copt-level=1 (instead of 2).
>>
>> Adding --enable-release to your mozconfig (the configuration for builds
we
>> ship to users) enables -Copt-level=2. (i.e. we didn't change
optimization
>> settings for builds we ship to users.)
>>
>> Adding --disable-optimize sets to -Copt-level=0. (This behavior is
>> unchanged.)
>>
>> If you want explicit control over -Copt-level, you can `export
>> RUSTC_OPT_LEVEL=` in your mozconfig and that value will always be
>> used. --enable-release implies a number of other changes. So if you just
>> want to restore the old build system behavior, set this variable in your
>> mozconfig.
>>
>> Also, due to ongoing work around Rust integration in the build system,
it
>> is dangerous to rely on manual `cargo` invocations to compile Rust
because
>> bypassing the build system (not using `mach build`) may not use the same
>> set of RUSTFLAGS that direct `cargo` invocations do. Things were mostly
in
>> sync before. But this change and anticipated future changes will cause
more
>> drift. If you want the correct behavior, use `mach`.
>> 

Re: Default Rust optimization level decreased from 2 to 1

[Gregory Szorc]

On Tue, Oct 31, 2017 at 12:02 PM, Jeff Muizelaar 
wrote:

> As another piece of evidence in support opt-level=1 being the wrong
> default, Glenn also got bitten profiling with the wrong options.
> https://github.com/servo/webrender/issues/1817#issuecomment-340553613


It is "wrong" for the set of "people performing profiling." This set is
different from "people compiling Gecko." Which is different from "people
who actually need to compile Gecko." What I'm trying is the new default is
"not wrong" for a large set of people who aren't "people performing
profiling."

My opinion is that this class of failure is a UX failure revolving around
the question of "am I building the thing that should be used for X?" The
build workflow does a horrible job of asking this critical question. The
closest we have is `mach bootstrap` asking if you are building {Firefox,
Fennec} {with, without} artifact builds. And we don't do a good job of
transitioning between `mach bootstrap` or forcing people to run it at all.
So we essentially have nothing forcing people to answer a question that has
critical implications for their ability to adequately develop Firefox.

I have ideas for solving this problem. But to do it in a way that results
in fewer people falling through "my build configuration is sub-optimal and
I didn't know it" cracks, we need to eliminate the concept of a "default
build configuration" and require people to specify a build configuration
(by creating a mozconfig file, etc). This is because the reality is that
there is no single "default build configuration" that is ideal for
everyone. There are more details and some discussion in bug 1410262. I'd
rather we morph that bug as needed than discuss on this mailing list. I'm
happy to discuss on this mailing list eventually: I just want it to be
after we have general agreement on a concrete proposal.


>
>
> On Thu, Oct 26, 2017 at 2:51 PM, Jeff Muizelaar 
> wrote:
> > FWIW, WebRender becomes unusable opt-level=1. It also looks like style
> > performance takes quite a hit as well which means that our default
> > developer builds become unusable for performance work. I worry that
> > people will forget this and end up rediscovering only when they look
> > at profiles (as mstange just did). What's the use case for a
> > --enable-optimize, opt-level=1 build?
> >
> > -Jeff
> >
> > On Wed, Oct 25, 2017 at 1:34 PM, Gregory Szorc  wrote:
> >> Compiling Rust code with optimizations is significantly slower than
> >> compiling without optimizations. As was measured in bug 1411081, the
> >> difference between rustc's -Copt-level 1 and 2 on an i7-6700K (4+4
> cores)
> >> for a recent revision of mozilla-central was 325s/802s wall/CPU versus
> >> 625s/1282s. This made Rust compilation during Firefox builds stand out
> as a
> >> long pole and significantly slowed down builds.
> >>
> >> Because we couldn't justify the benefits of level 2 for the build time
> >> overhead it added, we've changed the build system default so Rust is
> >> compiled with -Copt-level=1 (instead of 2).
> >>
> >> Adding --enable-release to your mozconfig (the configuration for builds
> we
> >> ship to users) enables -Copt-level=2. (i.e. we didn't change
> optimization
> >> settings for builds we ship to users.)
> >>
> >> Adding --disable-optimize sets to -Copt-level=0. (This behavior is
> >> unchanged.)
> >>
> >> If you want explicit control over -Copt-level, you can `export
> >> RUSTC_OPT_LEVEL=` in your mozconfig and that value will always be
> >> used. --enable-release implies a number of other changes. So if you just
> >> want to restore the old build system behavior, set this variable in your
> >> mozconfig.
> >>
> >> Also, due to ongoing work around Rust integration in the build system,
> it
> >> is dangerous to rely on manual `cargo` invocations to compile Rust
> because
> >> bypassing the build system (not using `mach build`) may not use the same
> >> set of RUSTFLAGS that direct `cargo` invocations do. Things were mostly
> in
> >> sync before. But this change and anticipated future changes will cause
> more
> >> drift. If you want the correct behavior, use `mach`.
> >> ___
> >> 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: Default Rust optimization level decreased from 2 to 1

[Simon Sapin]

On 31/10/17 19:30, Randell Jesup wrote:

Note that this means that profiles taken with local builds will be "off"
compared to Nightly/etc, unless you rebuild with extra options.  How
much off?  probably not a lot unless you're super-focused on Rust code,
but that's just a guess.


This was also the case before this change if you did not use 
--enable-release. LTO can make a significant difference. (I’ve seen -10% 
time in some microbenchmarks.)


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

Re: Default Rust optimization level decreased from 2 to 1

[Jeff Muizelaar]

As another piece of evidence in support opt-level=1 being the wrong
default, Glenn also got bitten profiling with the wrong options.
https://github.com/servo/webrender/issues/1817#issuecomment-340553613

-Jeff

On Thu, Oct 26, 2017 at 2:51 PM, Jeff Muizelaar  wrote:
> FWIW, WebRender becomes unusable opt-level=1. It also looks like style
> performance takes quite a hit as well which means that our default
> developer builds become unusable for performance work. I worry that
> people will forget this and end up rediscovering only when they look
> at profiles (as mstange just did). What's the use case for a
> --enable-optimize, opt-level=1 build?
>
> -Jeff
>
> On Wed, Oct 25, 2017 at 1:34 PM, Gregory Szorc  wrote:
>> Compiling Rust code with optimizations is significantly slower than
>> compiling without optimizations. As was measured in bug 1411081, the
>> difference between rustc's -Copt-level 1 and 2 on an i7-6700K (4+4 cores)
>> for a recent revision of mozilla-central was 325s/802s wall/CPU versus
>> 625s/1282s. This made Rust compilation during Firefox builds stand out as a
>> long pole and significantly slowed down builds.
>>
>> Because we couldn't justify the benefits of level 2 for the build time
>> overhead it added, we've changed the build system default so Rust is
>> compiled with -Copt-level=1 (instead of 2).
>>
>> Adding --enable-release to your mozconfig (the configuration for builds we
>> ship to users) enables -Copt-level=2. (i.e. we didn't change optimization
>> settings for builds we ship to users.)
>>
>> Adding --disable-optimize sets to -Copt-level=0. (This behavior is
>> unchanged.)
>>
>> If you want explicit control over -Copt-level, you can `export
>> RUSTC_OPT_LEVEL=` in your mozconfig and that value will always be
>> used. --enable-release implies a number of other changes. So if you just
>> want to restore the old build system behavior, set this variable in your
>> mozconfig.
>>
>> Also, due to ongoing work around Rust integration in the build system, it
>> is dangerous to rely on manual `cargo` invocations to compile Rust because
>> bypassing the build system (not using `mach build`) may not use the same
>> set of RUSTFLAGS that direct `cargo` invocations do. Things were mostly in
>> sync before. But this change and anticipated future changes will cause more
>> drift. If you want the correct behavior, use `mach`.
>> ___
>> 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: Default Rust optimization level decreased from 2 to 1

[Randell Jesup]

>On 2017-10-25 1:34 PM, Gregory Szorc wrote:
>> Adding --enable-release to your mozconfig (the configuration for builds we
>> ship to users) enables -Copt-level=2. (i.e. we didn't change optimization
>> settings for builds we ship to users.)
>
>I've added a note about this to our benchmarking instructions at
>https://developer.mozilla.org/en-US/docs/Mozilla/Benchmarking#Rust_optimization_level

Note that this means that profiles taken with local builds will be "off"
compared to Nightly/etc, unless you rebuild with extra options.  How
much off?  probably not a lot unless you're super-focused on Rust code,
but that's just a guess.

-- 
Randell Jesup, Mozilla Corp
remove "news" for personal email
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Reorganization of Firefox-UI tests in mozilla-central

[Martijn]

Update MDN docs when moving Marionette tests all over the place.

On Wed, Nov 9, 2016 at 11:16 AM, Henrik Skupin  wrote:
> Henrik Skupin wrote on 01/09/16 17:37:
>
> After a longer time without a response I would like to give a follow-up
> on where we stand at the moment and what the future will be for those tests.
>
> But first, I want to say thanks to everyone who participated in this
> thread. The received feedback was very helpful and showed that a couple
> of topics are questionable and needed further discussion.
>
> With all that in mind we decided to get away with the original idea of
> moving the firefox-ui tests to the appropriate components in the state
> they are in right now. This will ensure that:
>
> * no other subdirectory for a new kind of test has to be added
> * don't make it harder for developers to decide which harness to use
>
> Instead our team decided to work towards the goal in transforming the
> firefox-ui-functional tests into plain Marionette tests. The work as
> such is not that trivial given that a couple of things have to be
> obeyed, and not everything is clear yet - especially not how we want to
> continue in testing nightly and release builds via mozmill-ci. But that
> shouldn't stop us to make writing Marionette tests for Firefox easier.
>
> Just to give an overview, here are the sub-projects I have to work on:
>
> * Decouple the Firefox Puppeteer package from FirefoxTestCase and make
> it an optional (mixin) class, which then could even be used with
> MarionetteTestCase if wanted.
>
> * Get rid of large portions of the firefox-ui harness except for update
> tests which would still require a separate harness due to their own
> command line arguments.
>
> * Refactor Marionette tests in domain specific jobs. As you know we run
> all the existing tests (unit, browser, layout, toolkit) in a single job
> and report as `Mn` to Treeherder. This should be split up into chunks.
> There will be a follow-up email on this topic soon.
>
> * Ensure that those jobs which report as Tier-1 will not use remote
> testcase data, and consider a new Tier-2 group for others (necessary for
> lot of the fx-ui security tests)
>
> * Refactor existing firefox-ui-functional tests into plain Marionette
> tests and get browser peer review before moving them to the appropriate
> tests folders.
>
> * Keep automation (mozharness, mozmill-ci) intact in parallel so we do
> not loose test coverage as needed by QE.
>
>
> I'm sure that the above outlined goals will be in a better alignment
> with you all. If not, or if there are questions, please let me know.
>
> Thanks,
>
> --
> Henrik Skupin
> Senior Software Engineer
> Mozilla Corporation
> ___
> 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: nsAutoConfig

[mkaply]

On Tuesday, October 31, 2017 at 12:10:21 AM UTC-5, Nicholas Nethercote wrote:
> Hi,
> 
> I was just looking at the extensions/pref/autoconfig/ directory and trying
> to understand what it does.
> 
> As far as I can tell, the code is there to allow custom deployments with
> particular prefs set, as described at
> https://developer.mozilla.org/en-US/Firefox/Enterprise_deployment#Configuration
> 
> It's initialized by modules/libpref/Preferences.cpp if a
> "general.config.filename" pref is found:
> http://searchfox.org/mozilla-central/rev/1ebd2eff44617df3b82eea7d2f3ca1b60cc591a0/modules/libpref/Preferences.cpp#3907-3920
> 
> There is also some MozHarness code relating to it here:
> http://searchfox.org/mozilla-central/source/testing/mozharness/mozharness/mozilla/firefox/autoconfig.py
> 
> Just to check: is this still supported functionality?
> 
> Thanks.
> 
> Nick

Yes, this is very much supported functionality. It is our primary means of 
enterprise customization right now.

The reason there are very few tests is because when it was first developed, it 
wasn't possible to write tests that involved putting down files before startup. 
There are some tests now:

http://searchfox.org/mozilla-central/source/extensions/pref/autoconfig/test/unit

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

Re: Intent to ship: Retained Display Lists

[Shako Ho]

Hi J. Ryan,

Yes, the concept of AIL is pretty similar to the definition of input
latency of RAIL.


RAIL StepKey MetricUser Actions
Response Input latency (from tap to paint) < 100ms. User taps a button (for
example, opening navigation

And I think the only difference is Hasal using different approach to get
the value..

Regards,
Shako

J. Ryan Stinnett 於 2017年10月31日 週二，下午10:34寫道：

> How is the AIL metric defined? I looked around Hasal for a bit, but I
> didn't see a clear definition.
>
> Is it similar to RAIL[1], or something entirely different?
>
> [1]: https://developers.google.com/web/fundamentals/performance/rail
>
> - Ryan
>
> On Tue, Oct 31, 2017 at 5:23 AM, Shako Ho  wrote:
>
>> Hi Matt,
>>
>>   We just re-run the Hasal against the latest nightly with
>> layout.display-list.retain=true,
>>
>>   and you can see the detail report as below:
>>
>> https://gist.github.com/ShakoHo/f9a654e327ee9dfa499584a8eeb27b7a
>>
>>  Summary:
>>
>>- 60% of test cases(12/20) indicate AIL time improved on this testing
>>target build
>>- The test cases listed below show significant improvement ail time
>>-
>>   - test_firefox_amazon_ail_hover_related_product_thumbnail
>>-
>>   - test_firefox_facebook_ail_click_open_chat_tab
>>-
>>   - test_firefox_gmail_ail_open_mail
>
>
>>
>> Feel free to ask if there is any question
>> Regards,
>> Shako
>>
>> --
>> Senior Software Engineer,
>> Firefox Mozilla
>>
>> On Tue, Oct 31, 2017 at 6:16 PM, Kan-Ru Chen  wrote:
>>
>> > Looks good!
>> >
>> > Could you share this to the other mail list? Thanks!
>> >
>> > Kanru
>> >
>> >
>> > On Tue, Oct 31, 2017, at 05:43 PM, Shako Ho wrote:
>> >
>> > Hi Kan-Ru,
>> >
>> >   Please check the detail report below:
>> >
>> > https://gist.github.com/ShakoHo/f9a654e327ee9dfa499584a8eeb27b7a
>> >
>> >   Summary:
>> >
>>
> >- 60% of test cases(12/20) indicate AIL time improved on this testing
>> >target build
>> >- The test cases listed below show significant improvement ail time
>> >-
>> >   - test_firefox_amazon_ail_hover_related_product_thumbnail
>> >   -
>> >   - test_firefox_facebook_ail_click_open_chat_tab
>> >   -
>> >   - test_firefox_gmail_ail_open_mail
>
>
>> >
>> >
>> > --
>> > Senior Software Engineer,
>> > Firefox Mozilla
>> >
>> > On Mon, Oct 30, 2017 at 5:29 PM, Kan-Ru Chen  wrote:
>> >
>> > RDL is in Nightly now. Time to test again?
>> >
>> > Kanru
>> >
>> > - Original message -
>> > From: mwood...@mozilla.com
>> > To: dev-platform@lists.mozilla.org
>> > Subject: Re: Intent to ship: Retained Display Lists
>> > Date: Wed, 25 Oct 2017 21:13:14 -0700 (PDT)
>> >
>> > On Monday, October 9, 2017 at 1:22:55 PM UTC+13, Matt Woodrow wrote:
>> >
>> > >
>> > > We're planning on landing the code for retaining display lists in 58,
>> > > behind the pref layout.display.list.retain.
>> > >
>> >
>> > This has now landed in Nightly, and looks to be working really well.
>> >
>> > We'd really appreciate some early feedback, so feel free to set
>> > layout.display-list.retain=true and give it a try!
>> >
>> > Please file bugs blocking 1352499 if you find any issues.
>> >
>> > Thanks!
>> >
>> >  - Matt
>> > ___
>> > dev-platform mailing list
>> > dev-platform@lists.mozilla.org
>> > https://lists.mozilla.org/listinfo/dev-platform
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "hasal-dev" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an
>> > email to hasal-dev+unsubscr...@mozilla.com.
>> > To post to this group, send email to hasal-...@mozilla.com.
>> > To view this discussion on the web visit https://groups.google.com/a/mo
>> > zilla.com/d/msgid/hasal-dev/1509355750.2035304.1155294128.4C
>> > 0C7C44%40webmail.messagingengine.com.
>> >
>> >
>> >
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
> --
--
Senior Software Engineer,
Firefox Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Retained Display Lists

[J. Ryan Stinnett]

How is the AIL metric defined? I looked around Hasal for a bit, but I
didn't see a clear definition.

Is it similar to RAIL[1], or something entirely different?

[1]: https://developers.google.com/web/fundamentals/performance/rail

- Ryan

On Tue, Oct 31, 2017 at 5:23 AM, Shako Ho  wrote:

> Hi Matt,
>
>   We just re-run the Hasal against the latest nightly with
> layout.display-list.retain=true,
>
>   and you can see the detail report as below:
>
> https://gist.github.com/ShakoHo/f9a654e327ee9dfa499584a8eeb27b7a
>
>  Summary:
>
>- 60% of test cases(12/20) indicate AIL time improved on this testing
>target build
>- The test cases listed below show significant improvement ail time
>-
>   - test_firefox_amazon_ail_hover_related_product_thumbnail
>-
>   - test_firefox_facebook_ail_click_open_chat_tab
>-
>   - test_firefox_gmail_ail_open_mail
>
> Feel free to ask if there is any question
> Regards,
> Shako
>
> --
> Senior Software Engineer,
> Firefox Mozilla
>
> On Tue, Oct 31, 2017 at 6:16 PM, Kan-Ru Chen  wrote:
>
> > Looks good!
> >
> > Could you share this to the other mail list? Thanks!
> >
> > Kanru
> >
> >
> > On Tue, Oct 31, 2017, at 05:43 PM, Shako Ho wrote:
> >
> > Hi Kan-Ru,
> >
> >   Please check the detail report below:
> >
> > https://gist.github.com/ShakoHo/f9a654e327ee9dfa499584a8eeb27b7a
> >
> >   Summary:
> >
> >- 60% of test cases(12/20) indicate AIL time improved on this testing
> >target build
> >- The test cases listed below show significant improvement ail time
> >-
> >   - test_firefox_amazon_ail_hover_related_product_thumbnail
> >   -
> >   - test_firefox_facebook_ail_click_open_chat_tab
> >   -
> >   - test_firefox_gmail_ail_open_mail
> >
> >
> > --
> > Senior Software Engineer,
> > Firefox Mozilla
> >
> > On Mon, Oct 30, 2017 at 5:29 PM, Kan-Ru Chen  wrote:
> >
> > RDL is in Nightly now. Time to test again?
> >
> > Kanru
> >
> > - Original message -
> > From: mwood...@mozilla.com
> > To: dev-platform@lists.mozilla.org
> > Subject: Re: Intent to ship: Retained Display Lists
> > Date: Wed, 25 Oct 2017 21:13:14 -0700 (PDT)
> >
> > On Monday, October 9, 2017 at 1:22:55 PM UTC+13, Matt Woodrow wrote:
> >
> > >
> > > We're planning on landing the code for retaining display lists in 58,
> > > behind the pref layout.display.list.retain.
> > >
> >
> > This has now landed in Nightly, and looks to be working really well.
> >
> > We'd really appreciate some early feedback, so feel free to set
> > layout.display-list.retain=true and give it a try!
> >
> > Please file bugs blocking 1352499 if you find any issues.
> >
> > Thanks!
> >
> >  - Matt
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "hasal-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to hasal-dev+unsubscr...@mozilla.com.
> > To post to this group, send email to hasal-...@mozilla.com.
> > To view this discussion on the web visit https://groups.google.com/a/mo
> > zilla.com/d/msgid/hasal-dev/1509355750.2035304.1155294128.4C
> > 0C7C44%40webmail.messagingengine.com.
> >
> >
> >
> ___
> 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: Visual Studio 2017 coming soon

[Sylvestre Ledru]

2017-10-30 19:19 GMT+01:00 Kris Maglione :

> Our static analysis tools are pretty good at catching a lot of lambda
> capture bugs at this point, though. I'd be much less comfortable using them
> if they weren't.
>
> It's probably worth considering whether we need to write static analysis
> tools for a new feature before we turn it on, though...

We can probably help with introducing more static analysis to avoid
incorrect usages of C++{11,14,17} features.

Don't hesitate to report suggestions here:
https://bugzilla.mozilla.org/enter_bug.cgi?product=Core=Rewriting%20and%20Analysis

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

Re: How much context does CF_HTML really need?

[Ted Mielczarek]

On Tue, Oct 31, 2017, at 05:46 AM, Henri Sivonen wrote:
> (Context: I'm trying to understand the requirements for our
> serializers in case we rewrite them [in Rust].)
> 
> The HTML fragment parsing algorithm can have only one context node.
> The context is never a chain of nodes towards to the root, since such
> a thing wouldn't affect the result per the HTML parsing algorithm.
> 
> However, when the HTML parsing algorithm is in the non-fragment mode,
> some tags get ignored without appropriate parent, so e.g. to represent
>  in the non-fragment mode, you need to include , etc. But
> that's about it.
> 
> The Windows CF_HTML clipboard format,
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms649015(v=vs.85).aspx
> , represents fragments by designating them in a full HTML document, so
> what are logically fragments have to work with non-fragment parsing.
> 
> This indicates that when we export a fragment to the clipboard, we
> should serialize its parent if not table-related or reconstruct a full
> table if table-related.
> 
> Yet, it seems that we serialize much more ancestor context.
> 
> Is there a good reason to? For example, does Microsoft office (our old
> bugs suggest that Excel is the pickiest consumer) or other CF_HTML
> consumers on Windows care about more context than the standard HTML
> parsing algorithm? What could consumers possibly do with knowlegde
> about ancestors beyond parent or the nearest ? (I'm ignoring
> SVG and MathML for the moment.)
> 
> OTOH, it seems that we include only some element types in the context
> (https://searchfox.org/mozilla-central/source/dom/base/nsDocumentEncoder.cpp#1540).
> It's unclear to me why. The first revision of the list came from jst
> during the Netscape 6 crunch without an explanation either in Bugzilla
> or code comments. (https://bugzilla.mozilla.org/show_bug.cgi?id=50742)
> 
> Does anyone know why?

I don't know exactly why, but I did try to fix pasting table cells into
Excel a long time ago (someone else eventually fixed it), and it was
definitely tricky and underspecified:
https://bugzilla.mozilla.org/show_bug.cgi?id=137450

Comments on the bug indicate that there are non-table cases where the
context is important, like `` to ensure you wind up pasting
numbered list items.

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

Re: Re: nsAutoConfig

[Marco Castelluccio]

Are you sure the test you wrote is testing nsAutoConfig and not
nsReadConfig?

nsReadConfig does not instantiate nsAutoConfig unless
autoadmin.global_config_url exists and is not emtpy:

https://codecov.io/gh/marco-c/gecko-dev/src/9ca76dcb7a5c61d33750e9718c02b11ba35c1032/extensions/pref/autoconfig/src/nsReadConfig.cpp#L205

https://dxr.mozilla.org/mozilla-central/rev/1c618b1a13662de7cec429f606367db3827b6dc7/extensions/pref/autoconfig/src/nsReadConfig.cpp#208

- Marco.


Il 31/10/2017 10:38, Masatoshi Kimura ha scritto:
> On 2017/10/31 19:22, Marco Castelluccio wrote:
>> It is not covered by any automated test:
>> https://codecov.io/gh/marco-c/gecko-dev/src/9ca76dcb7a5c61d33750e9718c02b11ba35c1032/extensions/pref/autoconfig/src/nsAutoConfig.cpp
>> (this doesn't mean it isn't actually used ever, but it can be a clue).
> Actually I wrote an automated test, although it is difficult for
> coverage tools to find the usage:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1267567
>

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

Re: nsAutoConfig

[Masatoshi Kimura]

On 2017/10/31 19:22, Marco Castelluccio wrote:
> It is not covered by any automated test:
> https://codecov.io/gh/marco-c/gecko-dev/src/9ca76dcb7a5c61d33750e9718c02b11ba35c1032/extensions/pref/autoconfig/src/nsAutoConfig.cpp
> (this doesn't mean it isn't actually used ever, but it can be a clue).

Actually I wrote an automated test, although it is difficult for
coverage tools to find the usage:
https://bugzilla.mozilla.org/show_bug.cgi?id=1267567
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Retained Display Lists

[Shako Ho]

Hi Matt,

  We just re-run the Hasal against the latest nightly with
layout.display-list.retain=true,

  and you can see the detail report as below:

https://gist.github.com/ShakoHo/f9a654e327ee9dfa499584a8eeb27b7a

 Summary:

   - 60% of test cases(12/20) indicate AIL time improved on this testing
   target build
   - The test cases listed below show significant improvement ail time
   -
  - test_firefox_amazon_ail_hover_related_product_thumbnail
   -
  - test_firefox_facebook_ail_click_open_chat_tab
   -
  - test_firefox_gmail_ail_open_mail

Feel free to ask if there is any question
Regards,
Shako

--
Senior Software Engineer,
Firefox Mozilla

On Tue, Oct 31, 2017 at 6:16 PM, Kan-Ru Chen  wrote:

> Looks good!
>
> Could you share this to the other mail list? Thanks!
>
> Kanru
>
>
> On Tue, Oct 31, 2017, at 05:43 PM, Shako Ho wrote:
>
> Hi Kan-Ru,
>
>   Please check the detail report below:
>
> https://gist.github.com/ShakoHo/f9a654e327ee9dfa499584a8eeb27b7a
>
>   Summary:
>
>- 60% of test cases(12/20) indicate AIL time improved on this testing
>target build
>- The test cases listed below show significant improvement ail time
>-
>   - test_firefox_amazon_ail_hover_related_product_thumbnail
>   -
>   - test_firefox_facebook_ail_click_open_chat_tab
>   -
>   - test_firefox_gmail_ail_open_mail
>
>
> --
> Senior Software Engineer,
> Firefox Mozilla
>
> On Mon, Oct 30, 2017 at 5:29 PM, Kan-Ru Chen  wrote:
>
> RDL is in Nightly now. Time to test again?
>
> Kanru
>
> - Original message -
> From: mwood...@mozilla.com
> To: dev-platform@lists.mozilla.org
> Subject: Re: Intent to ship: Retained Display Lists
> Date: Wed, 25 Oct 2017 21:13:14 -0700 (PDT)
>
> On Monday, October 9, 2017 at 1:22:55 PM UTC+13, Matt Woodrow wrote:
>
> >
> > We're planning on landing the code for retaining display lists in 58,
> > behind the pref layout.display.list.retain.
> >
>
> This has now landed in Nightly, and looks to be working really well.
>
> We'd really appreciate some early feedback, so feel free to set
> layout.display-list.retain=true and give it a try!
>
> Please file bugs blocking 1352499 if you find any issues.
>
> Thanks!
>
>  - Matt
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
> --
> You received this message because you are subscribed to the Google Groups
> "hasal-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to hasal-dev+unsubscr...@mozilla.com.
> To post to this group, send email to hasal-...@mozilla.com.
> To view this discussion on the web visit https://groups.google.com/a/mo
> zilla.com/d/msgid/hasal-dev/1509355750.2035304.1155294128.4C
> 0C7C44%40webmail.messagingengine.com.
>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: nsAutoConfig

[Marco Castelluccio]

It is not covered by any automated test:
https://codecov.io/gh/marco-c/gecko-dev/src/9ca76dcb7a5c61d33750e9718c02b11ba35c1032/extensions/pref/autoconfig/src/nsAutoConfig.cpp
(this doesn't mean it isn't actually used ever, but it can be a clue).

- Marco.


Il 31/10/2017 05:09, Nicholas Nethercote ha scritto:
> Hi,
>
> I was just looking at the extensions/pref/autoconfig/ directory and trying
> to understand what it does.
>
> As far as I can tell, the code is there to allow custom deployments with
> particular prefs set, as described at
> https://developer.mozilla.org/en-US/Firefox/Enterprise_deployment#Configuration
>
> It's initialized by modules/libpref/Preferences.cpp if a
> "general.config.filename" pref is found:
> http://searchfox.org/mozilla-central/rev/1ebd2eff44617df3b82eea7d2f3ca1b60cc591a0/modules/libpref/Preferences.cpp#3907-3920
>
> There is also some MozHarness code relating to it here:
> http://searchfox.org/mozilla-central/source/testing/mozharness/mozharness/mozilla/firefox/autoconfig.py
>
> Just to check: is this still supported functionality?
>
> Thanks.
>
> Nick
>


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

How much context does CF_HTML really need?

[Henri Sivonen]

(Context: I'm trying to understand the requirements for our
serializers in case we rewrite them [in Rust].)

The HTML fragment parsing algorithm can have only one context node.
The context is never a chain of nodes towards to the root, since such
a thing wouldn't affect the result per the HTML parsing algorithm.

However, when the HTML parsing algorithm is in the non-fragment mode,
some tags get ignored without appropriate parent, so e.g. to represent
 in the non-fragment mode, you need to include , etc. But
that's about it.

The Windows CF_HTML clipboard format,
https://msdn.microsoft.com/en-us/library/windows/desktop/ms649015(v=vs.85).aspx
, represents fragments by designating them in a full HTML document, so
what are logically fragments have to work with non-fragment parsing.

This indicates that when we export a fragment to the clipboard, we
should serialize its parent if not table-related or reconstruct a full
table if table-related.

Yet, it seems that we serialize much more ancestor context.

Is there a good reason to? For example, does Microsoft office (our old
bugs suggest that Excel is the pickiest consumer) or other CF_HTML
consumers on Windows care about more context than the standard HTML
parsing algorithm? What could consumers possibly do with knowlegde
about ancestors beyond parent or the nearest ? (I'm ignoring
SVG and MathML for the moment.)

OTOH, it seems that we include only some element types in the context
(https://searchfox.org/mozilla-central/source/dom/base/nsDocumentEncoder.cpp#1540).
It's unclear to me why. The first revision of the list came from jst
during the Netscape 6 crunch without an explanation either in Bugzilla
or code comments. (https://bugzilla.mozilla.org/show_bug.cgi?id=50742)

Does anyone know why?

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: upcoming requirements changes for Stylo builds + request for help

[Simon Sapin]

On 31/10/17 10:37, m...@fireburn.co.uk wrote:

I'm curious as to why Clang is required, why doesn't GCC work?


rust-bindgen uses libclang to parse C++ header files and generate 
corresponding Rust definitions. GCC can still be used for compiling.


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

Re: upcoming requirements changes for Stylo builds + request for help

[mike]

I'm curious as to why Clang is required, why doesn't GCC work?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Experimenting with a shared review queue for Core::Build Config

[Mark Banner]

On 11/10/2017 19:41, Botond Ballo wrote:

On Wed, Oct 11, 2017 at 2:37 PM, Chris Cooper  wrote:

On Wed, Oct 11, 2017 at 1:46 PM, Nathan Froyd  wrote:

Does this user have a bugzilla :alias so that folks submitting patches
via MozReview or similar can just write r=build-peer or something,
rather than having to manually select the appropriate shared queue
after submitting their patch for review?

I see this as an added efficiency, so I'll see how much effort it is
to set this up. The people behind MozReview are explicitly not
expending effort there right now in favor of phabricator though.

It does not require any setup on the MozReview side - you just need to
add ":build-peer" (or whatever the chosen alias) to the "Real name"
field of the user's Bugzilla profile, and MozReview will autodetect
it.

In case anyone hits this, you need to add "r?Build" for mozreview to 
detect the reviewer properly.


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

Security Principles for coding secure IPC

[Paul Theriault]

With tighter sandbox restrictions hitting release in 57, I thought it might
be a good time to provide some tips on writing IPC in a safe way. Our
sandbox is less effective if we punch holes in it through due to IPC bugs
or overly permissive APIs. This document highlights some of the common
issues we have come across during our work to audit Firefox IPC mechanisms
for sandboxing escapes. These type of bugs aren't very common, but the
anti-patterns that lead to these type of bugs fall into a few categories,
and hopefully this document will help you avoid them.

https://wiki.mozilla.org/Security/Sandbox/IPCguide

NB: these are general guidelines - often its Not That Simple (tm). Help is
at hand - either my team, or the Content Isolation team (Jim Mathies) are
always interested to talk sandboxing.

Big thank you to Julian Hector for writing this, and to the Content
Isolation team and others for their input and review.

Feedback, corrections, suggestions all welcome.

Regards,

Paul Theriault
Firefox Security Assurance
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform