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

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

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

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

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

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:

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

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

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

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

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

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

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

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

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

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

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