Intent to ship: CSP Violation DOM Events

[Chung-Sheng Fu]

Content Security Policy suggests Security Policy Violation DOM Events [1].
In case any of the directives within a policy are violated, such a
SecurityPolicyViolationEvent is generated and sent out to a reporting
endpoint associated with the policy. We are working on implementing those
violation events here [2] and plan to ship them within Firefox 59.

Thanks,

Chung-Sheng Fu, Christoph Kerschbaumer

[1] https://w3c.github.io/webappsec-csp/#violation-events

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1037335
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Please switch from MOZ_DEBUG to MOZ_NO_OSX_EVENT_TAPS to avoid event taps on Mac

[Boris Zbarsky]

I just landed a change [1] to use the MOZ_NO_OSX_EVENT_TAPS environment 
variable instead of the MOZ_DEBUG environment variable to disable event 
taps on Mac.


If you aren't setting MOZ_DEBUG in your environment, you don't need to 
do anything.


If you _are_ setting it, to work around bug 699538, then just change the 
env var you're setting.


For the curious, we made this change because MOZ_DEBUG is something our 
build system cares about and it kept accidentally picking up the env var 
when it shouldn't have, breaking build on Mac if you had it defined


-Boris

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1415741
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: mozilla-central now compiles with C++14

[gsquelart]

On Friday, November 17, 2017 at 6:05:38 AM UTC+11, Jeff Walden wrote:
> On 11/16/2017 08:35 AM, Ben Kelly wrote:
> > I would like to use initialized lambda capture as I think it will allow
> > move-only objects to be used in lambdas like this:
> > 
> > UniquePtr uniqueThing = MakeUnique();
> > nsCOMPtr r = NS_NewRunnableFunction([uniqueThing =
> > Move(uniqueThing)] () {
> >   uniqueThing->Stuff();
> > });
> > thread->Dispatch(r.forget());
> > 
> > Thanks.
> 
> Do it!  https://bugzilla.mozilla.org/show_bug.cgi?id=1322962 was WONTFIX'd 
> for adding a dodgy workaround for this purpose, so it is expected that people 
> will do/use this in this manner.
> 
> Jeff

Please note one hurdle before C++14 can actually be used:
https://bugzilla.mozilla.org/show_bug.cgi?id=1418047

This should hopefully land soon.
Then let the floodgates open, and let us yearn for C++17 features we suddenly 
*need* right now! :-)

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

Re: mozilla-central now compiles with C++14

[Jim Blandy]

Oh, this is great!! I was going to have to use horrible kludges to get
around the lack of generic lambdas.

On Wed, Nov 15, 2017 at 8:44 PM, Nathan Froyd  wrote:

> C++14 constructs are now usable in mozilla-central and related trees.
> According to:
>
> https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code
>
> this opens up the following features for use:
>
> * binary literals (0b001)
> * return type deduction
> * generic lambdas
> * initialized lambda captures
> * digit separators in numeric constants
> * [[deprecated]] attribute
>
> My personal feeling is that all of these features minus return type
> deduction seem pretty reasonable to use immediately, but I would
> welcome comments to the contrary.
>
> Please note that our minimum GCC version remains at 4.9: I have seen
> reports that GCC 4.9 might not always be as adept at compiling C++14
> constructs as one might like, so you may want to be a little cautious
> and use try to make sure GCC 4.9 does the right thing.
>
> Starting the race to lobby for C++17 support in three...two...one... =D
>
> Happy hacking,
> -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: mozilla-central now compiles with C++14

[Jeff Walden]

On 11/16/2017 08:35 AM, Ben Kelly wrote:
> I would like to use initialized lambda capture as I think it will allow
> move-only objects to be used in lambdas like this:
> 
> UniquePtr uniqueThing = MakeUnique();
> nsCOMPtr r = NS_NewRunnableFunction([uniqueThing =
> Move(uniqueThing)] () {
>   uniqueThing->Stuff();
> });
> thread->Dispatch(r.forget());
> 
> Thanks.

Do it!  https://bugzilla.mozilla.org/show_bug.cgi?id=1322962 was WONTFIX'd for 
adding a dodgy workaround for this purpose, so it is expected that people will 
do/use this in this manner.

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

Re: mozilla-central now compiles with C++14

[Ben Kelly]

On Wed, Nov 15, 2017 at 8:44 PM, Nathan Froyd  wrote:

> * initialized lambda captures
>

I would like to use initialized lambda capture as I think it will allow
move-only objects to be used in lambdas like this:

UniquePtr uniqueThing = MakeUnique();
nsCOMPtr r = NS_NewRunnableFunction([uniqueThing =
Move(uniqueThing)] () {
  uniqueThing->Stuff();
});
thread->Dispatch(r.forget());

Thanks.

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

Re: Still-supported cases of out-of-tree XPCOM code?

[Jonathan Kingston]

> Code search wouldn't have helped *this* case, but considering how
useful https://dxr.mozilla.org/addons/ has been previously, the notion
of there still existing out-of-tree XPCOM callers but them being dark
matter code search-wise worries me.

This was failing for quite some time, we kept ahead of the failures when
firefox was radically changing this.

I agree a test suite would help for these addons for stability going
forward as maintaining this for containers was a hard task.

I would like to re-iterate what Baku said, there was a log failure that
wasn't picked up and was thought to be the failure. It however wasn't and
the actual bug was in central impacting Nightly container users also.

> If the file is needed for <56, why does it even run in 57 or 58?

The code shouldn't run for those versions, there was an import for all
versions which caused an error however didn't even prevent the rest of the
file from loading which is used to make the embedded extension load.

On Wed, Nov 15, 2017 at 4:31 PM, Kris Maglione 
wrote:

> On Wed, Nov 15, 2017 at 04:12:06PM +0200, Henri Sivonen wrote:
>
>> On Wed, Nov 15, 2017 at 3:16 PM, Andrea Marchesini
>>
>>> This is why we had this issue. It should not be impossible for a
>>> 'standard'
>>> webextension to generate such mess.
>>>
>>
>> How many Mozilla-signed special extensions are there? Does an analog
>> of https://dxr.mozilla.org/addons/ exist for searching their code? Is
>> there a CI system testing that the continue to work?
>>
>
> The situation is pretty bad at this point. Ideally, all XPCOM add-ons that
> we support should run tests in treeherder on checkin, both for add-on
> changes and m-c changes. But as of now, most system add-ons, Test Pilot
> add-ons, and SHIELD studies are hosted on Github and do their own ad-hoc
> testing, mostly using Node-ish testing frameworks.
>
> There's also no standard place to host or index all of this add-on code,
> or even to get a list of what such add-ons exist. At one point, I asked for
> all SHIELD add-ons to at least be hosted in the same Github organization.
> The same should probably go for all other Mozilla-signed add-ons. That
> would at least give us a single place to find any XPCOM add-on code that we
> still support.
>
> In the mean time, though, as far as I'm concerned, the maintainers of
> those add-ons are responsible for dealing with breakage that results from
> not having in-tree tests and a standard place to search that code. If
> you're removing legacy XPCOM functionality, all you should need to care
> about is whether treeherder is green.
>
> ___
> 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: mozilla-central now compiles with C++14

[Jet Villegas]

Nice! Binary literals sound cool for bit masks. I’d hate to have to
read/write them for anything else :-)

On Wed, Nov 15, 2017 at 20:44 Nathan Froyd  wrote:

> C++14 constructs are now usable in mozilla-central and related trees.
> According to:
>
> https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code
>
> this opens up the following features for use:
>
> * binary literals (0b001)
> * return type deduction
> * generic lambdas
> * initialized lambda captures
> * digit separators in numeric constants
> * [[deprecated]] attribute
>
> My personal feeling is that all of these features minus return type
> deduction seem pretty reasonable to use immediately, but I would
> welcome comments to the contrary.
>
> Please note that our minimum GCC version remains at 4.9: I have seen
> reports that GCC 4.9 might not always be as adept at compiling C++14
> constructs as one might like, so you may want to be a little cautious
> and use try to make sure GCC 4.9 does the right thing.
>
> Starting the race to lobby for C++17 support in three...two...one... =D
>
> Happy hacking,
> -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

GC header file regoranisation

[Jon Coppeard]

In bug 1417123 I'm regorganising the GC header files a little.  In summary:

 - if you need to use JS::Rooted, JS::Handle and the like please include 
js/RootingAPI.h.
 - if you need to configure the GC or trigger a collection please include 
js/GCAPI.h.

The idea is to move everything required for using GC pointers to RootingAPI.h 
and everything required for controlling the GC to GCAPI.h.  The former should 
cover almost all cases.

Thanks,

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