Re: PSA: Local static analysis builds on Linux and Mac OS X

[Nicholas Nethercote]

On Wed, Oct 14, 2015 at 6:07 PM, Ehsan Akhgari  wrote:
>
> On Linux, most other recent versions of clang should work too, such as the
> one you usually get from your distro, provided that the dev package for
> LLVM/Clang has been installed.

Is there an easy way to determine if that package has been installed?
And if it's not installed, is there an easy way to install it?

Thank you.

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

Re: Fwd: On the future of and application/x-x509-*-cert MIME handling

[Simon Richter]

Hi,

sorry for warming up this topic, I've just been pointed here.

Am Donnerstag, 30. Juli 2015 01:35:49 UTC+2 schrieb David Keeler:

> Ryan Sleevi recently announced the pre-intention to deprecate and
> eventually remove support for the  element and special-case
> handling of the application/x-x509-*-cert MIME types from the blink
> platform (i.e. Chrome).

[...]

> I therefore propose we follow suit and begin the process of deprecating
> and removing these features. The intention of this post is to begin a
> discussion to determine the feasibility of doing so.

A common setup I build for small companies and organizations uses a
simple local CA and a web page containing a form with a  and a
password. Enrollment works by

1. Phone call or physical presence of applicant, CA administrator
authenticates applicant.
2. Administrator starts enrollment process, one time password in
generated and given to applicant
3. Applicant uses the  and the one time password to send a
signing request to the CA server
4. CA server replies with new client certificate

For simple setups, this is a really easy way to deploy certificates --
really, the hardest part is copying the certificate from Firefox to
Thunderbird if it is to be used for SMTP relay authentication as well.

Removing  obviously breaks this workflow, but I think it can be
replaced with JavaScript -- this adds an extra step for organizations
that do not enable JS by default, but I think that would be manageable.

In any case, however the key store would still need to be able to store
keys that are not associated with a certificate yet, or we're losing key
generation capability completely (well, theoretically we could generate
keys in JS and keep the private key material in DOM storage until the
certificate is ready, but I doubt anyone wants that).

Is there still an API left that allows me to easily deploy client
certificates in such a setting?

   Simon



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Decommissioning "dumbmake"

[Mike Hommey]

On Thu, Oct 15, 2015 at 08:43:53PM -0400, Ehsan Akhgari wrote:
> On 2015-10-15 8:37 PM, Bobby Holley wrote:
> >On Thu, Oct 15, 2015 at 5:26 PM, Mike Hommey  >> wrote:
> >
> >On Thu, Oct 15, 2015 at 05:21:44PM -0700, Bobby Holley wrote:
> >> Will building in an arbitrary source directory continue to link 
> > libxul? It
> >> was really great when we stopped needing to build in toolkit/library 
> > all
> >> the time.
> >
> >The point is, that doesn't reliably happen currently. You should
> >just use mach
> >build binaries, which will, reliably, and even better, only if needed.
> >
> >
> >|mach build binaries| is much slower for me than the present behavior,
> >because I often hack on header files that are included all over the
> >tree, but whose #include-ers generally don't need to be rebuilt all of
> >the time.
> 
> I have the exact same use case as Bobby and as such object to removing this
> feature.  Especially since it is unclear what we gain from removing it.

Consistency. Currently, when you do `mach build foo/bar`, you don't know
what's going to happen. Some people will get toolkit/library rebuild,
some won't. Or other directories. Or not.

"dumbmake" also breaks `mach build foo/bar/baz` when the expected outcome
is `make -C objdir/foo bar/baz` instead of `make -C objdir/foo/bar baz`.

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

Intent to implement and ship ::backdrop pseudo-element for Fullscreen API

[Xidorn Quan]

Summary: This pseudo-element is rendered immediately below every
fullscreen element, and covers the other part of the document by
default. This is part of the effort to update our Fullscreen API
implementation to the latest spec. And it is the last non-trivial part
before I'm going to unprefix the Fullscreen API.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1064843

Link to standard: https://fullscreen.spec.whatwg.org/#::backdrop-pseudo-element

Platform coverage: all

Target release: 44

Preference behind which this will be implemented: none

DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1209831

Other browser support:
IE has shipped a prefixed version of this pseudo-element for
fullscreen since 11, and Edge shpped it unprefixed:
https://msdn.microsoft.com/en-us/library/dn312072%28v=vs.85%29.aspx
Blink has shipped this pseudo-element unprefixed for modal 
element (but not yet for fullscreen)

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

Re: Intent to unship: jar: URIs from content

[Ehsan Akhgari]

On 2015-10-15 7:08 PM, Robert O'Callahan wrote:

I'm sad that I won't be able to use jar: URLs to load testcases in ZIP
files uploaded to Bugzilla, but this sounds like the right thing to do.


When speaking with Boris on IRC today he also mentioned that he does use 
jar URLs in this way.  You can flip the pref to get this back  :-)


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

Re: Decommissioning "dumbmake"

[Benoit Girard]

+1

For my use case breaking dumbmake is preferable given that we now have
'build binaries'. When touching commonly included header I often like to
run ./mach build gfx && ./mach build binaries. This effectively let's me
say 'Make sure my gfx changes are good before you recompile the rest of
gecko' giving me control over the recompile order. This will notify me
quickly if there's a compile error without having to rebuild everything
that include the header that I changed giving me compile errors much
faster. With the current behavior './mach build gfx' will try to link when
I haven't yet recompiled all the files that I need.

On Thu, Oct 15, 2015 at 8:15 PM, Mike Hommey  wrote:

> Hi,
>
> I started a thread with the same subject almost two years ago. The
> motivation hasn't changed, but the context surely has, so it's probably
> time to reconsider.
>
> As a reminder, "dumbmake" is the feature that makes "mach build foo/bar"
> sometimes rebuild in some other directories as well. For example, "mach
> build gfx" will build gfx, as well as toolkit/library.
>
> OTOH, it is pretty limited, and, for instance, "mach build gfx/2d" will
> only build gfx/2d.
>
> There are however now two build targets that can do the right thing for
> most use cases:
> - mach build binaries, which will build C/C++ related things
>   appropriately
> - mach build faster, which will build JS, XUL, CSS, etc. (iow, non
>   C/C++) (although it skips what doesn't end up in dist/bin)
>
> At this point, I think "dumbmake" is more harmful than helpful, and the
> above two targets should be used instead. Removing "dumbmake" would mean
> that "mach build foo/bar" would still work, but would stop to "magically"
> do something else than what was requested (or fail to do that thing for
> all the cases it doesn't know about).
>
> Are there still objections to go forward, within the new context?
>
> Cheers,
>
> Mike
> ___
> 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: Decommissioning "dumbmake"

[Mike Hommey]

On Thu, Oct 15, 2015 at 05:21:44PM -0700, Bobby Holley wrote:
> Will building in an arbitrary source directory continue to link libxul? It
> was really great when we stopped needing to build in toolkit/library all
> the time.

The point is, that doesn't reliably happen currently. You should just use mach
build binaries, which will, reliably, and even better, only if needed.

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

Re: Decommissioning "dumbmake"

[Bobby Holley]

Also, interactive rebase often dirties a bunch of files unnecessarily - I
know they haven't changed, but the build system doesn't.

Basically, the best-effort approach of rebuilding directories saves a lot
of time for certain Gecko hackers like myself, and it would be really nice
if the libxul linking was preserved, if nothing else.

On Thu, Oct 15, 2015 at 5:37 PM, Bobby Holley  wrote:

> On Thu, Oct 15, 2015 at 5:26 PM, Mike Hommey  wrote:
>
>> On Thu, Oct 15, 2015 at 05:21:44PM -0700, Bobby Holley wrote:
>> > Will building in an arbitrary source directory continue to link libxul?
>> It
>> > was really great when we stopped needing to build in toolkit/library all
>> > the time.
>>
>> The point is, that doesn't reliably happen currently. You should just use
>> mach
>> build binaries, which will, reliably, and even better, only if needed.
>>
>
> |mach build binaries| is much slower for me than the present behavior,
> because I often hack on header files that are included all over the tree,
> but whose #include-ers generally don't need to be rebuilt all of the time.
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Decommissioning "dumbmake"

[Ehsan Akhgari]

On 2015-10-15 8:37 PM, Bobby Holley wrote:

On Thu, Oct 15, 2015 at 5:26 PM, Mike Hommey > wrote:

On Thu, Oct 15, 2015 at 05:21:44PM -0700, Bobby Holley wrote:
> Will building in an arbitrary source directory continue to link libxul? It
> was really great when we stopped needing to build in toolkit/library all
> the time.

The point is, that doesn't reliably happen currently. You should
just use mach
build binaries, which will, reliably, and even better, only if needed.


|mach build binaries| is much slower for me than the present behavior,
because I often hack on header files that are included all over the
tree, but whose #include-ers generally don't need to be rebuilt all of
the time.


I have the exact same use case as Bobby and as such object to removing 
this feature.  Especially since it is unclear what we gain from removing it.

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

Re: Decommissioning "dumbmake"

[Nicholas Nethercote]

On Fri, Oct 16, 2015 at 11:37 AM, Bobby Holley  wrote:
>
> |mach build binaries| is much slower for me than the present behavior,
> because I often hack on header files that are included all over the tree,
> but whose #include-ers generally don't need to be rebuilt all of the time.

I used to have a bunch of my own aliases for building particular
directories (and toolkit/library if necessary) and then relinking.
(Sounds like maybe I partially reimplemented dumbmake myself? Not
sure.) I stopped using them once |mach build binaries| came along
because it was better for my use cases.

I suspect the very small number of people who are in your position can
do something similar?

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

Decommissioning "dumbmake"

[Mike Hommey]

Hi,

I started a thread with the same subject almost two years ago. The
motivation hasn't changed, but the context surely has, so it's probably
time to reconsider.

As a reminder, "dumbmake" is the feature that makes "mach build foo/bar"
sometimes rebuild in some other directories as well. For example, "mach
build gfx" will build gfx, as well as toolkit/library.

OTOH, it is pretty limited, and, for instance, "mach build gfx/2d" will
only build gfx/2d.

There are however now two build targets that can do the right thing for
most use cases:
- mach build binaries, which will build C/C++ related things
  appropriately
- mach build faster, which will build JS, XUL, CSS, etc. (iow, non
  C/C++) (although it skips what doesn't end up in dist/bin)

At this point, I think "dumbmake" is more harmful than helpful, and the
above two targets should be used instead. Removing "dumbmake" would mean
that "mach build foo/bar" would still work, but would stop to "magically"
do something else than what was requested (or fail to do that thing for
all the cases it doesn't know about).

Are there still objections to go forward, within the new context?

Cheers,

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

Re: Decommissioning "dumbmake"

[Bobby Holley]

On Thu, Oct 15, 2015 at 5:26 PM, Mike Hommey  wrote:

> On Thu, Oct 15, 2015 at 05:21:44PM -0700, Bobby Holley wrote:
> > Will building in an arbitrary source directory continue to link libxul?
> It
> > was really great when we stopped needing to build in toolkit/library all
> > the time.
>
> The point is, that doesn't reliably happen currently. You should just use
> mach
> build binaries, which will, reliably, and even better, only if needed.
>

|mach build binaries| is much slower for me than the present behavior,
because I often hack on header files that are included all over the tree,
but whose #include-ers generally don't need to be rebuilt all of the time.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Decommissioning "dumbmake"

[Bobby Holley]

Will building in an arbitrary source directory continue to link libxul? It
was really great when we stopped needing to build in toolkit/library all
the time.

On Thu, Oct 15, 2015 at 5:15 PM, Mike Hommey  wrote:

> Hi,
>
> I started a thread with the same subject almost two years ago. The
> motivation hasn't changed, but the context surely has, so it's probably
> time to reconsider.
>
> As a reminder, "dumbmake" is the feature that makes "mach build foo/bar"
> sometimes rebuild in some other directories as well. For example, "mach
> build gfx" will build gfx, as well as toolkit/library.
>
> OTOH, it is pretty limited, and, for instance, "mach build gfx/2d" will
> only build gfx/2d.
>
> There are however now two build targets that can do the right thing for
> most use cases:
> - mach build binaries, which will build C/C++ related things
>   appropriately
> - mach build faster, which will build JS, XUL, CSS, etc. (iow, non
>   C/C++) (although it skips what doesn't end up in dist/bin)
>
> At this point, I think "dumbmake" is more harmful than helpful, and the
> above two targets should be used instead. Removing "dumbmake" would mean
> that "mach build foo/bar" would still work, but would stop to "magically"
> do something else than what was requested (or fail to do that thing for
> all the cases it doesn't know about).
>
> Are there still objections to go forward, within the new context?
>
> Cheers,
>
> Mike
> ___
> 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: Intent to unship: jar: URIs from content

[Nicholas Alexander]

On Thu, Oct 15, 2015 at 10:58 AM, Ehsan Akhgari 
wrote:

> We currently support URLs such as  http://mxr.mozilla.org/mozilla-central/source/modules/libjar/test/mochitest/bug403331.zip?raw=1=application/java-archive!/test.html>.
> This is a Firefox specific feature that no other engine implements, and it
> increases our attack surface unnecessarily.  As such, I would like to put
> it behind a pref and disable it for Web content by default.
>

I've always been surprised by this (and resource:, although I think there's
a story behind that one).  Glad to see it go.

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

Re: PSA: Local static analysis builds on Linux and Mac OS X

[Andrew Halberstadt]

On 15/10/15 01:59 PM, Ehsan Akhgari wrote:

On 2015-10-14 9:18 PM, Mike Hommey wrote:

BTW, since we're growing the set of checks the plugin does, what do we
do to ensure that it doesn't add too much overhead to the compilation
time?


Currently nothing beyond taking care to not add slow checks.

Since we're talking about the build speed here, I hope that some day we
start tracking our build speed to understand how it regresses over time.
  Once we have that infrastructure, we can easily track this for static
analysis builds in addition to other kinds of builds.


This data is available in active data right now. Here's a really dumb 
query that returns a tuple of builder name and seconds it took the 
"mozharness build step" to complete:

http://activedata.allizom.org/tools/query.html#query_id=wIv23AVn

Someone who is better at querying than me could probably come up with 
something that returns a daily average by platform. See the "jobs" 
schema linked from the query tool for other parameters.

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

Proposal to converge with Chromium / Blink for not firing events on ’s from dropdowns

[Mike Conley]

 Hey dev-platform,

TL;DR: I want Gecko to stop firing events on ’s on 
dropdowns.

Context:

Bug 1090602 was filed way back in the day by someone who used the old
Treestatus app, because they noticed it was broken once e10s was flipped on
by default. The problem was that the old Treestatus app was putting a click
event listener on a  to detect changes to the  and update
some state somewhere. With e10s (where the  dropdown is actually
opening in the parent), we weren’t triggering events on the selected
 in the content process.

So I’ve been hemming and hawing about how best to solve this, and I even
started working on the machinery to capture and synthesize the events from
the parent-side [1]. This ended up looking like a big pile of
work.

That’s when I found out that event behaviour for ’s is not spec’d
out, and the way in which events are fired differs widely from browser to
browser.

I tested Firefox Nightly (non-e10s), Safari, Chrome, Internet Explorer and
Edge, and posted my findings at [2].

What I’m proposing is that we try to converge with Chrome / Blink’s
behaviour on these events, where we do not fire any events on ’s,
ever, whenever e10s is enabled by default.

That’d greatly simplify my work in bug 1090602 - it’d basically be a
WONTFIX.

Note that this should not affect Gecko’s behaviour when the  is
displayed “inline” (for example, when the  has a “multiple”
attribute, or a “size” attribute with a value greater than 1). I'm only
concerned with the dropdown case.

Are there any objections or thoughts about this plan? Are there more events
that I've not considered in my manual test case[3] that I should test?

-Mike

[1]: Yep, that’s currently how we show the  dropdowns. We know
there are still usability problems with e10s’s  dropdowns, but this
email is not regarding those usability problems.
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1090602#c27
[3]: https://bug1090602.bmoattachments.org/attachment.cgi?id=8674454
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Decommissioning "dumbmake"

[Jonas Sicking]

> |mach build binaries| is much slower for me than the present behavior,
> because I often hack on header files that are included all over the tree,
> but whose #include-ers generally don't need to be rebuilt all of the time.

Before we had mach, I had an alias for linking libxul. If there is a
simple mach command for linking libxul you might be able to just build
your source dir and then linking libxul?

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

Re: Decommissioning "dumbmake"

[Mike Hommey]

On Thu, Oct 15, 2015 at 09:15:01PM -0700, Jonas Sicking wrote:
> > |mach build binaries| is much slower for me than the present behavior,
> > because I often hack on header files that are included all over the tree,
> > but whose #include-ers generally don't need to be rebuilt all of the time.
> 
> Before we had mach, I had an alias for linking libxul. If there is a
> simple mach command for linking libxul you might be able to just build
> your source dir and then linking libxul?

Actually, you can pass multiple directories to mach, so you can do

   mach build foo toolkit/library

in which case mach will do

   make -C objdir/foo
   make -C objdir/toolkit/library
 
And will only do the latter if the former succeeds.

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

Re: Intent to unship: jar: URIs from content

[Jason Duell]

OMG yes please.

Jason

On Thu, Oct 15, 2015 at 11:31 AM, Ehsan Akhgari 
wrote:

> On 2015-10-15 1:58 PM, Ehsan Akhgari wrote:
>
>> We currently support URLs such as
>> > http://mxr.mozilla.org/mozilla-central/source/modules/libjar/test/mochitest/bug403331.zip?raw=1=application/java-archive!/test.html
>> >.
>>   This is a Firefox specific feature that no other engine implements,
>> and it increases our attack surface unnecessarily.  As such, I would
>> like to put it behind a pref and disable it for Web content by default.
>>
>
> FWIW I filed bug 1215235 for this.  We'll wait for this discussion before
> landing code there.
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



-- 

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

Re: PSA: Local static analysis builds on Linux and Mac OS X

[Ehsan Akhgari]

On 2015-10-14 9:18 PM, Mike Hommey wrote:

BTW, since we're growing the set of checks the plugin does, what do we
do to ensure that it doesn't add too much overhead to the compilation
time?


Currently nothing beyond taking care to not add slow checks.

Since we're talking about the build speed here, I hope that some day we 
start tracking our build speed to understand how it regresses over time. 
 Once we have that infrastructure, we can easily track this for static 
analysis builds in addition to other kinds of builds.

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

Re: Intent to unship: jar: URIs from content

[Bobby Holley]

Huzzah! Thanks for fixing this Ehsan.

On Thu, Oct 15, 2015 at 10:58 AM, Ehsan Akhgari 
wrote:

> We currently support URLs such as  http://mxr.mozilla.org/mozilla-central/source/modules/libjar/test/mochitest/bug403331.zip?raw=1=application/java-archive!/test.html>.
> This is a Firefox specific feature that no other engine implements, and it
> increases our attack surface unnecessarily.  As such, I would like to put
> it behind a pref and disable it for Web content by default.
>
> Are there any objections?
>
> Thanks!
> ___
> 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: Intent to unship: jar: URIs from content

[Ehsan Akhgari]

On 2015-10-15 1:58 PM, Ehsan Akhgari wrote:

We currently support URLs such as
.
  This is a Firefox specific feature that no other engine implements,
and it increases our attack surface unnecessarily.  As such, I would
like to put it behind a pref and disable it for Web content by default.


FWIW I filed bug 1215235 for this.  We'll wait for this discussion 
before landing code there.


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

Re: PSA: Local static analysis builds on Linux and Mac OS X

[Ehsan Akhgari]

On 2015-10-14 9:32 PM, Gregory Szorc wrote:

On Wed, Oct 14, 2015 at 6:07 PM, Ehsan Akhgari > wrote:

Last weekend, I finished upgrading our Linux and OS X debug and opt
static
analysis builds ("S" jobs on TreeHerder) to the latest revision of clang
3.7.

Now, if you use the latest version of clang (3.7, which is available
from <
http://llvm.org/releases/download.html#3.7.0> in binary form), you
can turn
on static analysis checks locally by adding the following line to your
mozconfig:

ac_add_options --enable-clang-plugin

Doing this helps you in detecting errors specific to the "S" jobs early
during development, which simplifies the process of landing patches by
letting you see the errors at the same time as other compiler errors.

On Linux, most other recent versions of clang should work too, such
as the
one you usually get from your distro, provided that the dev package for
LLVM/Clang has been installed.  On OSX, the default clang that ships
with
recent versions of XCode lacks the dev headers and tools so it can't be
used, but the llvm.org  clang binaries should work
well.

I have been running this plugin locally in all of my builds for several
months now and once you migrate to this setup, everything should proceed
hassle free.  If you find issues getting your particular clang setup to
work with the plugin, please let me know, and I will help fix them.  I'd
like to eventually get us to a point where these checks are turned on by
default during local builds.


As you stated, this helps detect errors earlier during development,
which is a huge win. Is there a good reason configure doesn't enable the
clang plugin by default?


Like I said, that is what I would like to do eventually.  The problem is 
that right now I have no idea how many different clang setups work with 
the plugin, I just know that some of them (such as the Apple clang that 
ships with Xcode) doesn't work.  Right now I am trying to get feedback 
from early testers to get a better idea of how well this would work out 
of the box.  If possible, I would like to avoid turning this on 
opportunistically since then it would be hard for developers to say 
whether their build succeeded because it didn't trigger any static check 
errors or because their build has the clang plugin disabled...


(The situation would be a lot better if we had some kind of support for 
downloading the toolchain on Linux and OS X from tooltool similar to 
what we do on the infrastructure.)



If the plugin adds too much overhead, could we potentially factor out
the expensive checks so developers aren't burdened by them by default?


The plugin doesn't add much overhead right now.  The exact overhead 
really depends on the system in surprising ways.  Here are some 
measurements that I have performed:


On Linux builders, enabling the plugin doesn't have any measurable 
impact on the speed of the build.


On my Mac laptop, I did two measurements of a full debug build without 
and with the plugin enabled with clang 3.7.  The wall clock build times 
were 13m21.861s and 15m8.498s, respectively.


On my blazing fast Linux desktop machine, the same measurement yields 
8m26.966s and 8m39.880s respectively.


So the plugin overhead seems to be effectively negligible on Linux.  On 
Mac, the overhead is quite noticeable.


But back to your point, I agree that once we can turn it on by default 
reliably it would make sense to provide a --disable-clang-plugin option 
instead.

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

Re: Intent to unship: jar: URIs from content

[Aaron Klotz]

SGTM!

On 10/15/2015 11:58 AM, Ehsan Akhgari wrote:
We currently support URLs such as 
. 
 This is a Firefox specific feature that no other engine implements, 
and it increases our attack surface unnecessarily.  As such, I would 
like to put it behind a pref and disable it for Web content by default.


Are there any objections?

Thanks!
___
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