Re: Enabling (many) assertions in opt builds locally and eventually Nightly

[Randell Jesup]

>On 9/17/2018 1:31 PM, Botond Ballo wrote:
>> One potential issue here is that an assertion failure in Nightly
>> builds might be simultaneously very annoying (because it crashes the
>> browser of Nightly users every time it occurs) and not very actionable
>> (because no reliable STR can be found for it).
>
>I would also be concerned about data loss and profile corruption when an
>assertion crashes the browser. I don't think we'll have a very easy time
>convincing people to do anything non-trivial with Nightly if there's a
>pretty good chance that they completely lose the fruits of their labour.
>
>I'd hope that this wouldn't be too frequent a problem, but it probably
>depends on the assertion, and the state of the durability of our user
>profiles.

We already *need* to be stable in that case, given MOZ_RELEASE_ASSERT
(and normal just-because crashes). And as best I can tell, we are stable
(with regards to user profiles).  Once upon a time we weren't (5(?)
years ago?)

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

Intent to ship: Unprefixed Fullscreen API

[Xidorn Quan]

As of Firefox 64, I intend to turn on unprefixed Fullscreen API by default on 
all platforms. It has been developed behind the 
full-screen-api.unprefix.enabled preference.

Bug to turn on by default: https://bugzilla.mozilla.org/show_bug.cgi?id=1269276

Unprefixed Fullscreen API has been enabled in Nightly since Firefox 47. We once 
attempted to ship it at that time, but failed because of some webcompat 
concerns which happen only when unprefixed Fullscreen API is present. Since 
then, the spec has been revised to address some of the issues, but some of them 
were not fixable from our side, so I hoped to have other browsers do 
coordinated shipping with us.

After years, Chrome / Blink eventually caught up the spec, and it reached a 
point that they are attempting to ship it now. I think this is the best chance 
ever we can have unprefixed Fullscreen API actually available on the web. 
Chrome will ship it in Chrome 71 which reaches stable on Dec 4, and Firefox 64 
will reach release on Dec 11, so it's roughly the same time frame.

Notably, there are two feature changes since our last attempt to unprefix 
Fullscreen API:
1. Fullscreen related events are now dispatched to element when it is still 
connected in the same document, which matches other browsers' behavior and 
provides better modularization opportunity.
2. Element.requestFullscreen() and Document.exitFullscreen() now return Promise 
which gets resolved when fullscreen change finishes.

I'd also like to deprecate the prefixed Fullscreen API, but probably we should 
do that only after unprefixed Fullscreen API reaches release.

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

Re: Enabling (many) assertions in opt builds locally and eventually Nightly

[Aaron Klotz]

On 9/17/2018 1:31 PM, Botond Ballo wrote:

One potential issue here is that an assertion failure in Nightly
builds might be simultaneously very annoying (because it crashes the
browser of Nightly users every time it occurs) and not very actionable
(because no reliable STR can be found for it).


I would also be concerned about data loss and profile corruption when an 
assertion crashes the browser. I don't think we'll have a very easy time 
convincing people to do anything non-trivial with Nightly if there's a 
pretty good chance that they completely lose the fruits of their labour.


I'd hope that this wouldn't be too frequent a problem, but it probably 
depends on the assertion, and the state of the durability of our user 
profiles.

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

Re: Enabling (many) assertions in opt builds locally and eventually Nightly

[Alexis Beingessner]

With webrender we've had pretty good results from always defaulting to
MOZ_RELEASE_ASSERT, as users are often mildly decent at producing an STR.
But perhaps we're luckier in that everyone dogfooding webrender was more
willing to figure things out than a nightly user?

On Mon, Sep 17, 2018 at 3:31 PM Botond Ballo  wrote:

> One potential issue here is that an assertion failure in Nightly
> builds might be simultaneously very annoying (because it crashes the
> browser of Nightly users every time it occurs) and not very actionable
> (because no reliable STR can be found for it). That's the situation
> I'm in with bug 1457603, for example, where I may have to end up
> _downgrading_ a diagnostic assert that I added, to a regular assert.
>
> On Mon, Sep 17, 2018 at 3:25 PM, Jeff Gilbert 
> wrote:
> > I would be excited for something between MOZ_ASSERT and MOZ_CRASH, but
> > I think raising MOZ_ASSERTs to MOZ_ASSERT_NIGHTLY should be done by
> > hand and reviewed.
> >
> > On Mon, Sep 17, 2018 at 11:46 AM, Kris Maglione 
> wrote:
> >> There are some non-trivial snags for this proposal. A lot of assertions
> rely
> >> on other code gated on #ifdef DEBUG or DebugOnly<...> to avoid defining
> data
> >> members or storing values in non-debug builds. We could replace those
> with
> >> more fine-grained macros, of course, but particularly in the case of
> data
> >> members, we'd probably also take a significant memory usage regression.
> >>
> >> There's also the snag of NS_ASSERTION macros which are... weird.
> >>
> >> This is nothing we can't deal with, of course, but it will probably
> require
> >> a lot of manual work if we want to do it correctly.
> >>
> >>
> >> On Mon, Sep 17, 2018 at 02:38:14PM -0400, Randell Jesup wrote:
> >>>
> >>> There are quite a few things that may be caught by assertions by
> >>> developers before committing, especially sec issues - but most
> >>> developers don't run debug builds as their main local test builds, or
> >>> for local browsing use, because they are almost unusably slow.  And
> >>> turning on compiler optimization doesn't actually help much here - the
> >>> problem is mostly debug-only assertions and code that's debug only,
> such
> >>> as bug 1441052 ("Don't do full grey-node checking in local debug
> >>> builds").
> >>>
> >>> These added checks may be useful for CI tests, but they make the builds
> >>> unusable, so the vast majority of assertions don't run in the builds
> our
> >>> developers are using.  So enabling most of the existing MOZ_ASSERTs for
> >>> local opt builds (minus the worst performance-limiting ones) would help
> >>> developers catch bugs before landing them (and perhaps shipping
> >>> them). It's a lot like using ASAN builds to browse - but with much less
> >>> perf degradation on hopes.
> >>>
> >>> Even better, if we can make the overall hit to perf low enough (1%?),
> we
> >>> could enable it for some/all Nightly users/builds.  Or make "early
> >>> nightly" (and developer builds) enable them, and late nightly and beta
> >>> not.
> >>>
> >>> If we moved some of the most expensive checks to an alternative macro
> >>> (MOZ_ASSERT_DEBUG()), we could (selectively?) enable MOZ_ASSERT checks
> >>> in some opt builds.  Alternatively we could promote some MOZ_ASSERTs to
> >>> MOZ_ASSERT_NIGHTLY() (or MOZ_DIAGNOSTIC_ASSERT), which would assert in
> >>> (all) debug builds, and in nightly opt builds - and maybe promote some
> >>> to MOZ_ASSERT_RELEASE if we can take the perf hit, and they're in an
> >>> important spot.
> >>>
> >>> And as a stepping-stone to the above, having local opt builds enable
> >>> (most) MOZ_ASSERTs (excluding really expensive ones, like bug 1441052)
> >>> even if the hit is larger (5, 10%) would also increase the likelihood
> >>> that we'll catch things before we land them, or before they get to
> beta.
> >>> (Note: --enable-release would turn this local-build behavior off - and
> >>> anyone doing speed tests/profiling/etc needs that already, and probably
> >>> we should have a specific enable/disable like
> >>> --disable-extra-assertions).  This wouldn't be all that hard - most of
> >>> the work would be finding "expensive" assertions like bug 1441052.
> >>>
> >>> (and perhaps we should not continue to overload --enable-release for "I
> >>> want to benchmark/profile this build")
> >>>
> >>> Enabling most MOZ_ASSERTs in automation tests on opt builds would also
> >>> slightly increase our odds of finding problems - though this may not
> >>> help much, as the same tests are being run in debug builds.  The only
> >>> advantage would be races may be more likely in the faster opt builds.
> >>> It might be worth trying once we have this for a few weeks, and see if
> >>> it helps or not.
> >>>
> >>> Note: I've discussed this concept with various people including bz in
> >>> the past, and mostly have had agreement that this would be useful -
> thus
> >>> my filing of bug 1441052.  If we agree this is worth doing, we should
> >>> file bugs on it and 

Re: Enabling (many) assertions in opt builds locally and eventually Nightly

[Boris Zbarsky]

On 9/17/18 3:25 PM, Jeff Gilbert wrote:

I would be excited for something between MOZ_ASSERT and MOZ_CRASH


Note that we already have MOZ_DIAGNOSTIC_ASSERT in between those.  We 
should perhaps be using it a bit more.


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

Re: Enabling (many) assertions in opt builds locally and eventually Nightly

[Botond Ballo]

One potential issue here is that an assertion failure in Nightly
builds might be simultaneously very annoying (because it crashes the
browser of Nightly users every time it occurs) and not very actionable
(because no reliable STR can be found for it). That's the situation
I'm in with bug 1457603, for example, where I may have to end up
_downgrading_ a diagnostic assert that I added, to a regular assert.

On Mon, Sep 17, 2018 at 3:25 PM, Jeff Gilbert  wrote:
> I would be excited for something between MOZ_ASSERT and MOZ_CRASH, but
> I think raising MOZ_ASSERTs to MOZ_ASSERT_NIGHTLY should be done by
> hand and reviewed.
>
> On Mon, Sep 17, 2018 at 11:46 AM, Kris Maglione  wrote:
>> There are some non-trivial snags for this proposal. A lot of assertions rely
>> on other code gated on #ifdef DEBUG or DebugOnly<...> to avoid defining data
>> members or storing values in non-debug builds. We could replace those with
>> more fine-grained macros, of course, but particularly in the case of data
>> members, we'd probably also take a significant memory usage regression.
>>
>> There's also the snag of NS_ASSERTION macros which are... weird.
>>
>> This is nothing we can't deal with, of course, but it will probably require
>> a lot of manual work if we want to do it correctly.
>>
>>
>> On Mon, Sep 17, 2018 at 02:38:14PM -0400, Randell Jesup wrote:
>>>
>>> There are quite a few things that may be caught by assertions by
>>> developers before committing, especially sec issues - but most
>>> developers don't run debug builds as their main local test builds, or
>>> for local browsing use, because they are almost unusably slow.  And
>>> turning on compiler optimization doesn't actually help much here - the
>>> problem is mostly debug-only assertions and code that's debug only, such
>>> as bug 1441052 ("Don't do full grey-node checking in local debug
>>> builds").
>>>
>>> These added checks may be useful for CI tests, but they make the builds
>>> unusable, so the vast majority of assertions don't run in the builds our
>>> developers are using.  So enabling most of the existing MOZ_ASSERTs for
>>> local opt builds (minus the worst performance-limiting ones) would help
>>> developers catch bugs before landing them (and perhaps shipping
>>> them). It's a lot like using ASAN builds to browse - but with much less
>>> perf degradation on hopes.
>>>
>>> Even better, if we can make the overall hit to perf low enough (1%?), we
>>> could enable it for some/all Nightly users/builds.  Or make "early
>>> nightly" (and developer builds) enable them, and late nightly and beta
>>> not.
>>>
>>> If we moved some of the most expensive checks to an alternative macro
>>> (MOZ_ASSERT_DEBUG()), we could (selectively?) enable MOZ_ASSERT checks
>>> in some opt builds.  Alternatively we could promote some MOZ_ASSERTs to
>>> MOZ_ASSERT_NIGHTLY() (or MOZ_DIAGNOSTIC_ASSERT), which would assert in
>>> (all) debug builds, and in nightly opt builds - and maybe promote some
>>> to MOZ_ASSERT_RELEASE if we can take the perf hit, and they're in an
>>> important spot.
>>>
>>> And as a stepping-stone to the above, having local opt builds enable
>>> (most) MOZ_ASSERTs (excluding really expensive ones, like bug 1441052)
>>> even if the hit is larger (5, 10%) would also increase the likelihood
>>> that we'll catch things before we land them, or before they get to beta.
>>> (Note: --enable-release would turn this local-build behavior off - and
>>> anyone doing speed tests/profiling/etc needs that already, and probably
>>> we should have a specific enable/disable like
>>> --disable-extra-assertions).  This wouldn't be all that hard - most of
>>> the work would be finding "expensive" assertions like bug 1441052.
>>>
>>> (and perhaps we should not continue to overload --enable-release for "I
>>> want to benchmark/profile this build")
>>>
>>> Enabling most MOZ_ASSERTs in automation tests on opt builds would also
>>> slightly increase our odds of finding problems - though this may not
>>> help much, as the same tests are being run in debug builds.  The only
>>> advantage would be races may be more likely in the faster opt builds.
>>> It might be worth trying once we have this for a few weeks, and see if
>>> it helps or not.
>>>
>>> Note: I've discussed this concept with various people including bz in
>>> the past, and mostly have had agreement that this would be useful - thus
>>> my filing of bug 1441052.  If we agree this is worth doing, we should
>>> file bugs on it and see what the effort to get this would be, and if we
>>> could ship some of this to users.  Much like nightly-asan, this would
>>> shake out bugs we'll never find from crash-stats reports, and which can
>>> lead to critical sec bugs, and turn them into frequently-actionable
>>> bugs.  If needed this can be enabled incrementally once the build/config
>>> infra and macros are in place; there are several options for that.
>>
>> ___
>> dev-platform mailing list
>> 

Re: Enabling (many) assertions in opt builds locally and eventually Nightly

[Jeff Gilbert]

I would be excited for something between MOZ_ASSERT and MOZ_CRASH, but
I think raising MOZ_ASSERTs to MOZ_ASSERT_NIGHTLY should be done by
hand and reviewed.

On Mon, Sep 17, 2018 at 11:46 AM, Kris Maglione  wrote:
> There are some non-trivial snags for this proposal. A lot of assertions rely
> on other code gated on #ifdef DEBUG or DebugOnly<...> to avoid defining data
> members or storing values in non-debug builds. We could replace those with
> more fine-grained macros, of course, but particularly in the case of data
> members, we'd probably also take a significant memory usage regression.
>
> There's also the snag of NS_ASSERTION macros which are... weird.
>
> This is nothing we can't deal with, of course, but it will probably require
> a lot of manual work if we want to do it correctly.
>
>
> On Mon, Sep 17, 2018 at 02:38:14PM -0400, Randell Jesup wrote:
>>
>> There are quite a few things that may be caught by assertions by
>> developers before committing, especially sec issues - but most
>> developers don't run debug builds as their main local test builds, or
>> for local browsing use, because they are almost unusably slow.  And
>> turning on compiler optimization doesn't actually help much here - the
>> problem is mostly debug-only assertions and code that's debug only, such
>> as bug 1441052 ("Don't do full grey-node checking in local debug
>> builds").
>>
>> These added checks may be useful for CI tests, but they make the builds
>> unusable, so the vast majority of assertions don't run in the builds our
>> developers are using.  So enabling most of the existing MOZ_ASSERTs for
>> local opt builds (minus the worst performance-limiting ones) would help
>> developers catch bugs before landing them (and perhaps shipping
>> them). It's a lot like using ASAN builds to browse - but with much less
>> perf degradation on hopes.
>>
>> Even better, if we can make the overall hit to perf low enough (1%?), we
>> could enable it for some/all Nightly users/builds.  Or make "early
>> nightly" (and developer builds) enable them, and late nightly and beta
>> not.
>>
>> If we moved some of the most expensive checks to an alternative macro
>> (MOZ_ASSERT_DEBUG()), we could (selectively?) enable MOZ_ASSERT checks
>> in some opt builds.  Alternatively we could promote some MOZ_ASSERTs to
>> MOZ_ASSERT_NIGHTLY() (or MOZ_DIAGNOSTIC_ASSERT), which would assert in
>> (all) debug builds, and in nightly opt builds - and maybe promote some
>> to MOZ_ASSERT_RELEASE if we can take the perf hit, and they're in an
>> important spot.
>>
>> And as a stepping-stone to the above, having local opt builds enable
>> (most) MOZ_ASSERTs (excluding really expensive ones, like bug 1441052)
>> even if the hit is larger (5, 10%) would also increase the likelihood
>> that we'll catch things before we land them, or before they get to beta.
>> (Note: --enable-release would turn this local-build behavior off - and
>> anyone doing speed tests/profiling/etc needs that already, and probably
>> we should have a specific enable/disable like
>> --disable-extra-assertions).  This wouldn't be all that hard - most of
>> the work would be finding "expensive" assertions like bug 1441052.
>>
>> (and perhaps we should not continue to overload --enable-release for "I
>> want to benchmark/profile this build")
>>
>> Enabling most MOZ_ASSERTs in automation tests on opt builds would also
>> slightly increase our odds of finding problems - though this may not
>> help much, as the same tests are being run in debug builds.  The only
>> advantage would be races may be more likely in the faster opt builds.
>> It might be worth trying once we have this for a few weeks, and see if
>> it helps or not.
>>
>> Note: I've discussed this concept with various people including bz in
>> the past, and mostly have had agreement that this would be useful - thus
>> my filing of bug 1441052.  If we agree this is worth doing, we should
>> file bugs on it and see what the effort to get this would be, and if we
>> could ship some of this to users.  Much like nightly-asan, this would
>> shake out bugs we'll never find from crash-stats reports, and which can
>> lead to critical sec bugs, and turn them into frequently-actionable
>> bugs.  If needed this can be enabled incrementally once the build/config
>> infra and macros are in place; there are several options for that.
>
> ___
> 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: Enabling (many) assertions in opt builds locally and eventually Nightly

[Kris Maglione]

There are some non-trivial snags for this proposal. A lot of 
assertions rely on other code gated on #ifdef DEBUG or 
DebugOnly<...> to avoid defining data members or storing values 
in non-debug builds. We could replace those with more 
fine-grained macros, of course, but particularly in the case of 
data members, we'd probably also take a significant memory usage 
regression.


There's also the snag of NS_ASSERTION macros which are... weird.

This is nothing we can't deal with, of course, but it will 
probably require a lot of manual work if we want to do it 
correctly.


On Mon, Sep 17, 2018 at 02:38:14PM -0400, Randell Jesup wrote:

There are quite a few things that may be caught by assertions by
developers before committing, especially sec issues - but most
developers don't run debug builds as their main local test builds, or
for local browsing use, because they are almost unusably slow.  And
turning on compiler optimization doesn't actually help much here - the
problem is mostly debug-only assertions and code that's debug only, such
as bug 1441052 ("Don't do full grey-node checking in local debug
builds").

These added checks may be useful for CI tests, but they make the builds
unusable, so the vast majority of assertions don't run in the builds our
developers are using.  So enabling most of the existing MOZ_ASSERTs for
local opt builds (minus the worst performance-limiting ones) would help
developers catch bugs before landing them (and perhaps shipping
them). It's a lot like using ASAN builds to browse - but with much less
perf degradation on hopes.

Even better, if we can make the overall hit to perf low enough (1%?), we
could enable it for some/all Nightly users/builds.  Or make "early
nightly" (and developer builds) enable them, and late nightly and beta
not.

If we moved some of the most expensive checks to an alternative macro
(MOZ_ASSERT_DEBUG()), we could (selectively?) enable MOZ_ASSERT checks
in some opt builds.  Alternatively we could promote some MOZ_ASSERTs to
MOZ_ASSERT_NIGHTLY() (or MOZ_DIAGNOSTIC_ASSERT), which would assert in
(all) debug builds, and in nightly opt builds - and maybe promote some
to MOZ_ASSERT_RELEASE if we can take the perf hit, and they're in an
important spot.

And as a stepping-stone to the above, having local opt builds enable
(most) MOZ_ASSERTs (excluding really expensive ones, like bug 1441052)
even if the hit is larger (5, 10%) would also increase the likelihood
that we'll catch things before we land them, or before they get to beta.
(Note: --enable-release would turn this local-build behavior off - and
anyone doing speed tests/profiling/etc needs that already, and probably
we should have a specific enable/disable like
--disable-extra-assertions).  This wouldn't be all that hard - most of
the work would be finding "expensive" assertions like bug 1441052.

(and perhaps we should not continue to overload --enable-release for "I
want to benchmark/profile this build")

Enabling most MOZ_ASSERTs in automation tests on opt builds would also
slightly increase our odds of finding problems - though this may not
help much, as the same tests are being run in debug builds.  The only
advantage would be races may be more likely in the faster opt builds.
It might be worth trying once we have this for a few weeks, and see if
it helps or not.

Note: I've discussed this concept with various people including bz in
the past, and mostly have had agreement that this would be useful - thus
my filing of bug 1441052.  If we agree this is worth doing, we should
file bugs on it and see what the effort to get this would be, and if we
could ship some of this to users.  Much like nightly-asan, this would
shake out bugs we'll never find from crash-stats reports, and which can
lead to critical sec bugs, and turn them into frequently-actionable
bugs.  If needed this can be enabled incrementally once the build/config
infra and macros are in place; there are several options for that.

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

Re: Enabling (many) assertions in opt builds locally and eventually Nightly

[Randell Jesup]

It may be possible to narrow down the performance-regressing MOZ_ASSERTs
by pushing a series of Talos try runs with MOZ_ASSERT enabled for
specific top-level directories - then take those with significant
regressions, and recurse down a layer, lather, rinse, repeat to at least
the leaf-dir level, or (if there are a lot in the dir) the file level.

Then we can look with eyeballs and figure out what's up.

It might also be possible to use trace APIs to measure the cost of each
assertion... though the traces themselves might swamp most assertion
costs.

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

Enabling (many) assertions in opt builds locally and eventually Nightly

[Randell Jesup]

There are quite a few things that may be caught by assertions by
developers before committing, especially sec issues - but most
developers don't run debug builds as their main local test builds, or
for local browsing use, because they are almost unusably slow.  And
turning on compiler optimization doesn't actually help much here - the
problem is mostly debug-only assertions and code that's debug only, such
as bug 1441052 ("Don't do full grey-node checking in local debug
builds").

These added checks may be useful for CI tests, but they make the builds
unusable, so the vast majority of assertions don't run in the builds our
developers are using.  So enabling most of the existing MOZ_ASSERTs for
local opt builds (minus the worst performance-limiting ones) would help
developers catch bugs before landing them (and perhaps shipping
them). It's a lot like using ASAN builds to browse - but with much less
perf degradation on hopes.

Even better, if we can make the overall hit to perf low enough (1%?), we
could enable it for some/all Nightly users/builds.  Or make "early
nightly" (and developer builds) enable them, and late nightly and beta
not.

If we moved some of the most expensive checks to an alternative macro
(MOZ_ASSERT_DEBUG()), we could (selectively?) enable MOZ_ASSERT checks
in some opt builds.  Alternatively we could promote some MOZ_ASSERTs to
MOZ_ASSERT_NIGHTLY() (or MOZ_DIAGNOSTIC_ASSERT), which would assert in
(all) debug builds, and in nightly opt builds - and maybe promote some
to MOZ_ASSERT_RELEASE if we can take the perf hit, and they're in an
important spot.

And as a stepping-stone to the above, having local opt builds enable
(most) MOZ_ASSERTs (excluding really expensive ones, like bug 1441052)
even if the hit is larger (5, 10%) would also increase the likelihood
that we'll catch things before we land them, or before they get to beta.
(Note: --enable-release would turn this local-build behavior off - and
anyone doing speed tests/profiling/etc needs that already, and probably
we should have a specific enable/disable like
--disable-extra-assertions).  This wouldn't be all that hard - most of
the work would be finding "expensive" assertions like bug 1441052.

(and perhaps we should not continue to overload --enable-release for "I
want to benchmark/profile this build")

Enabling most MOZ_ASSERTs in automation tests on opt builds would also
slightly increase our odds of finding problems - though this may not
help much, as the same tests are being run in debug builds.  The only
advantage would be races may be more likely in the faster opt builds.
It might be worth trying once we have this for a few weeks, and see if
it helps or not.

Note: I've discussed this concept with various people including bz in
the past, and mostly have had agreement that this would be useful - thus
my filing of bug 1441052.  If we agree this is worth doing, we should
file bugs on it and see what the effort to get this would be, and if we
could ship some of this to users.  Much like nightly-asan, this would
shake out bugs we'll never find from crash-stats reports, and which can
lead to critical sec bugs, and turn them into frequently-actionable
bugs.  If needed this can be enabled incrementally once the build/config
infra and macros are in place; there are several options for that.

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

Looking for an implementer for a improvement to SublimeLinter-ESlint

[Mark Banner]

Hi all,

I am trying to improve our ESLint configuration, especially around HTML 
files. One of the things that limits us in the ideal scenario is the 
SublimeLinter-ESLint plugin.


The plugin currently does its own work for html files which stops 
working when eslint-plugin-html is enabled (which we want to enable by 
default in the mozilla-central configuration). I've been discussing it 
with the SublimeLinter-eslint team, and they have accepted an idea for 
an implementation for an automatic detection method so that it detects 
the ESLint plugin and stops doing its own html processing.


At the moment, this is not something I really want to try and tackle, so 
I'm looking for someone who might like to take it on.


We have a description of what needs changing, which is in the plugin 
itself, and is python based. Here's the details of the bug and the fix 
needed:


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

https://github.com/SublimeLinter/SublimeLinter-eslint/issues/253#issuecomment-416910981

If there's anyone interested in taking this on, please let me know.

Thanks

Mark.



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

Re: Intent to implement: Feature Policy

[Christoph Kerschbaumer]

> On Sep 15, 2018, at 12:54 AM, Ehsan Akhgari  wrote:
> 
> We also have https://bugzilla.mozilla.org/show_bug.cgi?id=1449501 open to
> display the CSP policy, perhaps it might make sense to expose both in
> similar ways (or at least for similar contexts, e.g. iframes).

FWIW, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1491748 
 to get some devtools 
support for feature policy.

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