Renaming nsAString_internal to nsAString

TL;DR this will change crash signatures and possibly other tool output; talk to me if this adversely affects you. Now that bug 1332639 has removed the external string API, we no longer need to differentiate between internal and external strings. Currently we #define nsAString to nsAString_interna

Intent to build (but not enable) WebRender by default on some Nightly platforms

(Cross-posted to dev-platform and dev-tech-gfx, please reply to dev-platform) In the near future I'm planning to make a change so that WebRender will be built (but not enabled) by default in most Nightly/local builds [1]. This will allow anybody running a stock nightly to turn on The QuantumRender

Re: The future of commit access policy for core Firefox

A bit off topic On 03/13/2017 04:37 PM, David Burns wrote: Regarding burden on reviewers, the comments in this thread just highlight how broken our current process is by having to flag individual people for reviews. This leads to the a handful of people doing 50%+ of reviews on the code. Unfor

Re: Please write good commit messages before asking for code review

On 03/10/2017 12:43 AM, Ben Kelly wrote: On Thu, Mar 9, 2017 at 5:35 PM, Mike Hommey wrote: On Thu, Mar 09, 2017 at 02:46:53PM -0500, Ehsan Akhgari wrote: I review a large number of patches on a typical day, and usually I have to spend a fair amount of time to just understand what the patch

Re: The future of commit access policy for core Firefox

On Monday, March 13, 2017 at 7:45:44 AM UTC-7, Byron Jones wrote: > David Burns wrote: > > We should try mitigate the security problem and fix our nit problem > > instead of bashing that we can't handle re-reviews because of nits. > one way tooling could help here is to allow the reviewer to make

Re: Startup JS debugging (sometimes) possible via Browser Toolbox

On Mon, Mar 13, 2017 at 2:04 PM, Jared Wein wrote: > Yes, we support watches in the new debugger UI now. The new debugger UI is > used by default in the Browser Content Toolbox, and it is pretty nice and > shiny. New debugger UI is on for Browser Content Toolbox, but at the moment, it's still o

Re: Startup JS debugging (sometimes) possible via Browser Toolbox

Yes, we support watches in the new debugger UI now. The new debugger UI is used by default in the Browser Content Toolbox, and it is pretty nice and shiny. Cheers, Jared On Mon, Mar 13, 2017 at 12:50 PM, Gijs Kruitbosch wrote: > On 13/03/2017 16:48, J. Ryan Stinnett wrote: > > > On Thu, Mar 9,

Re: What are the differences between a profile in Safe Mode, and a clean profile?

On Mon, Mar 13, 2017 at 2:10 PM, Botond Ballo wrote: > Over time, I have encountered a number of (what I assume are) Firefox bugs > that: > > - Reproduce in my default profile, even in Safe Mode > - Do not reproduce in a clean profile > > Since they do not reproduce in a clean profile, I have

Re: The future of commit access policy for core Firefox

On 2017-03-12 4:53 PM, smaug wrote: > On 03/12/2017 10:40 PM, Ehsan Akhgari wrote: >> On 2017-03-11 9:23 AM, smaug via governance wrote: >>> On 03/11/2017 08:23 AM, Nicholas Nethercote wrote: On Sat, Mar 11, 2017 at 2:23 PM, smaug via governance < governa...@lists.mozilla.org> wrote:

What are the differences between a profile in Safe Mode, and a clean profile?

Over time, I have encountered a number of (what I assume are) Firefox bugs that: - Reproduce in my default profile, even in Safe Mode - Do not reproduce in a clean profile Since they do not reproduce in a clean profile, I have not been able to turn these into actionable bug reports. Since th

Re: Startup JS debugging (sometimes) possible via Browser Toolbox

On 13/03/2017 16:48, J. Ryan Stinnett wrote: On Thu, Mar 9, 2017 at 2:18 AM, Panos Astithas > wrote: You almost completely resolved the 4-year-old bug 814298, yay! I now wonder if this makes it easier to improve mochitest debugging per bug 929535. Thank

Re: Startup JS debugging (sometimes) possible via Browser Toolbox

On Thu, Mar 9, 2017 at 2:18 AM, Panos Astithas wrote: > You almost completely resolved the 4-year-old bug 814298, yay! I now > wonder if this makes it easier to improve mochitest debugging per bug > 929535. Thanks for the pointers to these bugs. Bug 814298 stills needs breakpoint persistence t

Re: Tracking bug for removals after XPCOM extensions are no more?

On Mon, Mar 13, 2017 at 08:36:05AM -0700, Steve Fink wrote: For the record, there's some nonobvious stuff I can remove from the rooting hazard analysis due to this -- currently, it conservatively assumes that just about any nsISupports subclass's method could be implemented in a binary extensio

Re: Tracking bug for removals after XPCOM extensions are no more?

On 03/13/2017 06:17 AM, Nathan Froyd wrote: We do not. Bug 1299187 is related to such work, but that bug only covers unexporting symbols that 3rd party software would access. bz has filed a few bugs for removing nsIDOM* methods that only existed due to 3rd party compat concerns, but I don't thi

Re: The future of commit access policy for core Firefox

On 13/03/17 14:45, Byron Jones wrote: David Burns wrote: We should try mitigate the security problem and fix our nit problem instead of bashing that we can't handle re-reviews because of nits. one way tooling could help here is to allow the reviewer to make minor changes to the patch before it

Re: The future of commit access policy for core Firefox

David Burns wrote: We should try mitigate the security problem and fix our nit problem instead of bashing that we can't handle re-reviews because of nits. one way tooling could help here is to allow the reviewer to make minor changes to the patch before it lands. ie. "r+, fix typo in comment be

Re: The future of commit access policy for core Firefox

As the manager of the sheriffs, I am in favour of this proposal. The reasons why are as follow (and to note there are only 3 paid sheriffs to try cover the world): * A number of r+ with nits land up in the sheriffs queue for checkin-needed. This then puts the onus on the sheriffs, not the reviewe

[Firefox Desktop] Issues found: March 6th to March 10th

Hi everyone, Here's the list of new issues found and filed by the Desktop Release QA Team last week, *March 6 - March 10* (week 10). Additional details on the team's priorities last week, as well as the plans for the current week are available at: https://public.etherpad-mozilla.org/p/D

Re: The future of commit access policy for core Firefox

On 03/10/2017 12:59 AM, Bobby Holley wrote: At a high level, I think the goals here are good. However, the tooling here needs to be top-notch for this to work, and the standard approach of flipping on an MVP and dealing with the rest in followup bugs isn't going to be acceptable for something so

Re: Tracking bug for removals after XPCOM extensions are no more?

On 3/13/17 9:17 AM, Nathan Froyd wrote: We do not. Bug 1299187 is related to such work, but that bug only covers unexporting symbols that 3rd party software would access. bz has filed a few bugs for removing nsIDOM* methods that only existed due to 3rd party compat concerns, but I don't think t

Re: Tracking bug for removals after XPCOM extensions are no more?

We do not. Bug 1299187 is related to such work, but that bug only covers unexporting symbols that 3rd party software would access. bz has filed a few bugs for removing nsIDOM* methods that only existed due to 3rd party compat concerns, but I don't think there's been systematic evaluation of what'

Re: The future of commit access policy for core Firefox

On Mon, Mar 13, 2017 at 12:22 AM, Frederik Braun wrote: > On 12.03.2017 04:08, Cameron Kaiser wrote: > > On 3/10/17 4:38 AM, Masatoshi Kimura wrote: > >> On 2017/03/10 6:53, Mike Connor wrote: > >>> - Two-factor auth must be a requirement for all users approving or > >>> pushing a change.

Planned tree closure Tue 2017-03-14 08:30 UTC

We will be running a migration on the Treeherder database which will require pausing job ingestion at 08:30 UTC tomorrow (Tuesday). This is expected to take around 90 minutes, and trees will be closed for the duration. Thank you for your patience. _

Re: The future of commit access policy for core Firefox

On 12.03.2017 04:08, Cameron Kaiser wrote: > On 3/10/17 4:38 AM, Masatoshi Kimura wrote: >> On 2017/03/10 6:53, Mike Connor wrote: >>> - Two-factor auth must be a requirement for all users approving or >>> pushing a change. >> >> I have no mobile devices. How can I use 2FA? >> >> Previously