>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 f
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 i
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
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 P
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 l
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, f
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
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
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, o
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
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 (whic
> 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://bugz
12 matches
Mail list logo
