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

On Thu, Sep 20, 2018 at 09:22:12AM +1000, Cameron McCormack wrote: > On Thu, Sep 20, 2018, at 1:52 AM, Ehsan Akhgari wrote: > > While it may be the case that we may need to be more stable for > > MOZ_RELEASE_ASSERTs, I very much doubt that every single MOZ_ASSERT in our > > codebase is actually a

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

On Thu, Sep 20, 2018, at 1:52 AM, Ehsan Akhgari wrote: > While it may be the case that we may need to be more stable for > MOZ_RELEASE_ASSERTs, I very much doubt that every single MOZ_ASSERT in our > codebase is actually a guaranteed to never fail, so promoting them all to > be enabled in

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

>On Thu, Sep 20, 2018 at 09:22:12AM +1000, Cameron McCormack wrote: >> On Thu, Sep 20, 2018, at 1:52 AM, Ehsan Akhgari wrote: >> > While it may be the case that we may need to be more stable for >> > MOZ_RELEASE_ASSERTs, I very much doubt that every single MOZ_ASSERT in our >> > codebase is

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

Ehsan wrote: >On Tue, Sep 18, 2018 at 1:30 AM Randell Jesup wrote: >> 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

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

On 9/19/2018 5:30 PM, Mike Hommey wrote: On Linux and Mac, we could make MOZ_ASSERT fork and crash in the child, and continue in the parent process. There is kind of a way to do this on Windows 8.1+ too if we wanted [1], though it obviously doesn't quite work the same way. [1]

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

So, I don't think we need to do anything fancy with forking - we'd just need to capture stacks and send them via telemetry rather than as a crash report. This was the idea behind bug 1209131, which got pretty far along but never made it to the finish line. I spoke with Georg about it recently,

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

On Wed, Sep 19, 2018 at 05:37:46PM -0700, Bobby Holley wrote: So, I don't think we need to do anything fancy with forking - we'd just need to capture stacks and send them via telemetry rather than as a crash report. This was the idea behind bug 1209131, which got pretty far along but never made

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

On Tue, Sep 18, 2018 at 1:30 AM Randell Jesup wrote: > >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)

Re: WebRender on in Firefox Nightly for Windows 10 Nvidia

On Wednesday, September 12, 2018 at 3:07:20 PM UTC-5, Jeff Muizelaar wrote: > In bug 1490742 I have enabled WebRender in Nightly on non-laptop > Windows 10 Nvidia (~17% of our Nightly audience). This is a rewrite of > much the graphics backend in Firefox. We expect some edge-case > regressions,

Intent to implement and ship: New cookie jar policy to block storage access from tracking resources

Hi everyone, This is a (belated) intent to implement, as well as an intent to ship, a new cookie jar policy to block storage access to tracking resources. This work has been under development for several months now and has been tracked in

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

On Wed, Sep 19, 2018 at 11:52:07AM -0400, Ehsan Akhgari wrote: FWIW, I think your original proposal, having a way to opt into assertions without a slow build locally, is extremely valuable. I could see myself using that option intentionally even with the pain points I described above, but for

Re: WebRender on in Firefox Nightly for Windows 10 Nvidia

Hey Jim Our current plan is for Version 1 (Windows 10 Nividia users) to ride to release with Fx64. Although, this plan is considered 'At Risk' due to the high number of blocker bugs the team is currently working through. We are however reporting 'On track' for getting

Browser Architecture Newsletter #7 (S02E02)

Browser Architecture Newsletter #7 (S02E02) It’s been a long six months since the last Browser Architecture newsletter . Short and sweet and no theme for this newsletter. XUL/XBL Replacement The XUL/XBL replacement project

Re: mozilla-central Fails to Build on Mac With Latest Xcode (10.0)

This has been resolved. The fix for bug 1492210 is now in mozilla-central, thanks to Miko. Haik On Tue, Sep 18, 2018 at 11:30 AM Haik Aftandilian wrote: > If you don't build on macOS, read no further. > > With the latest XCode (10.0) just released, mozilla-central fails to build > due to bug

Input Delay Metric proposal

Problem: Various measures have been tried to capture user frustration with having to wait to interact with a site they're loading (or to see the site data). This includes: FID - First Input Delay -- https://developers.google.com/web/updates/2018/05/first-input-delay TTI - Time To Interactive --