Re: Phabricator and confidential reviews

On Wed, Aug 9, 2017 at 11:32 AM, Mark Côté wrote: > I actually like Gijs's proposal, to mirror *from* Phabricator *to* BMO. > That way, if you're looking at the bug and want to pull someone in, you CC > them; if you're looking at the fix and want to involve someone, you add >

Re: disabled non-e10s tests on trunk

I ran some scripts that I had to find out tests that are *fully* disabled on e10s, and posted the results to https://bugzilla.mozilla.org/show_bug.cgi?id=1376934 In summary: mochitest-plain: 49 tests browser-chrome: 15 tests devtools: 86 tests Note that the script evaluates the skip-if condition

the root CA module now loads asynchronously

Hello Folks, Bug 1372656 landed this morning, which means that Nightly now loads the root certificate authority trust database asynchronously and shouldn't block the main thread*. This should make startup faster, but it's a bit experimental and improving PSM/NSS startup time is a work in progress

how to make your local --enable-optimize builds compile Rust faster

TL; DR: apply https://github.com/froydnj/gecko-dev/commit/12a80904837c60e2fc3c68295b79c42eb9be6650.patch to get faster --enable-optimize local builds if you are working on Stylo or touching Rust in any way. Please try to not commit it along with your regular patches. =D You may have noticed

Re: nsIURI API changes - punycode domain names

On 8/9/17 1:43 PM, Daniel Veditz wrote: ​What do web pages do if they want to reflect a pretty URL into their page? Cry, basically. This is the fundamental reason I was opposed to this behavior change, but apparently no other browsers care about this issue and we were getting compat

Re: Finalizer for WebIDL object backed by JS impl of an XPCOM interface

On 8/9/17 1:55 PM, Henri Sivonen wrote: I'm thinking of introducing a C++-implemented XPCOM object that the JS-implemented XPCOM object can hold a reference to and that has a C++ destructor that does what I want. Does that mean your action doesn't depend on which exact JS object got

Re: Phabricator and confidential reviews

For brevity and clarity I'm just replying to Dan here, but I am attempting to address other points raised so far in this thread. On Wednesday, 9 August 2017 13:07:08 UTC-4, Daniel Veditz wrote: > On Tue, Aug 8, 2017 at 5:30 PM, Mark Côté wrote: > > > I am not sure how often

Heads-up: WebRender now requires HWA enabled

TLDR: Once bug 1387764 merges to mozilla-central, anybody running with WebRender enabled on Linux will need to force-enable hardware acceleration (layers.acceleration.force-enabled=true) to keep WebRender enabled. Long version: Previously the check for enabling WebRender ignored the status of

Re: nsIURI API changes - punycode domain names

On 9 August 2017 at 19:43, Daniel Veditz wrote: > On Wed, Aug 9, 2017 at 9:57 AM, Valentin Gosu > wrote: > >> This is a definite improvement in terms of web-compat. document.origin, >> location.href, etc will from now on return punycode. >> > >

Re: Finalizer for WebIDL object backed by JS impl of an XPCOM interface

On Tue, Aug 8, 2017 at 1:26 PM, Henri Sivonen wrote: > What's the correct way to take an action right before a JS-implemented > XPCOM object that acts as the implementation for a WebIDL interface > gets garbage collected? Taking action soon after GC would work for me as

Re: nsIURI API changes - punycode domain names

On Wed, Aug 9, 2017 at 9:57 AM, Valentin Gosu wrote: > This is a definite improvement in terms of web-compat. document.origin, > location.href, etc will from now on return punycode. > ​What do web pages do if they want to reflect a pretty URL into their page? Will

Re: Phabricator and confidential reviews

On Tue, Aug 8, 2017 at 5:30 PM, Mark Côté wrote: > I am not sure how often CCed users are involved with confidential bugs' > patches > ​[​ > ​] Anecdotally I have been told that a lot of the time users are CCed > just to be informed of the problem, e.g. a manager might

nsIURI API changes - punycode domain names

TL;DR: we have made some changes to the nsIURI API that affect IDN domain names Before: ASCII - GetAsciiSpec, GetAsciiHost, GetAsciiHostPort UTF-8 - GetSpec, GetPrePath, GetHost, GetHostPort Now: UTF-8 - GetDisplaySpec, GetDisplayPrePath, GetDisplayHost, GetDisplayHostPort ASCII

Re: Phabricator and confidential reviews

On Wed, Aug 9, 2017 at 12:20 AM, Axel Hecht wrote: > I think we should strive to have as few people as possible with general > access to security bugs. ​We do. We've reduced the number of people with access, and split the "client" security group into ~10 sub groups so that

Re: Phabricator and confidential reviews

On Tue, Aug 8, 2017 at 11:38 PM, Nicolas B. Pierron < nicolas.b.pier...@mozilla.com> wrote: > However, users outside of the security group(s) can see confidential bugs >> if they are involved with them in some way. Frequently the CC field is >> used as a way to include outsiders in a bug. > > >

Re: Phabricator and confidential reviews

On 08/08/2017 08:30 PM, Mark Côté wrote: First I want to double check that this is truly useful. I am not sure how often CCed users are involved with confidential bugs' patches (I might be able to ballpark this with some Bugzilla searches, but I don't think it would be easy to get a straight

Re: Figuring out and controlling what tasks run before first paint

What you are looking for sounds pretty much like my Backtrack project [1]. It's still under development, tho, but I have strong motivations to move it forward in Q4/17. The goal of Backtrack is exactly what you are looking for - find the right scheduling prioritization. It's said we don't

Re: disabled non-e10s tests on trunk

On Wed, Aug 9, 2017 at 3:36 AM, Boris Zbarsky wrote: > > Hmm. Do we load about:blank from the url bar in a content process? > > Yes. I agree, I find it annoying too that we have to rely on MOZ_DEBUG_CHILD_PROCESS or MOZ_DEBUG_CHILD_PAUSE and that I have to be clever all the

Re: Phabricator and confidential reviews

On 09/08/2017 01:30, Mark Côté wrote: If you have any thoughts on this, please reply. I'll answer any questions and summarize the feedback with a decision in a few days. Note that we can, of course, try a simple approach to start, and add in more complex functionality after an evaluation

Re: Phabricator and confidential reviews

To answer the question not asked ;-) I think we should strive to have as few people as possible with general access to security bugs. The concerns the folks have when crossing borders is awful. And just from a general risk profile. Saying that as someone that neither has nor wants access to

Re: Phabricator and confidential reviews

On 08/09/2017 12:30 AM, Mark Côté wrote: Hi, I have an update and a request for comments regarding Phabricator and confidential reviews. First of all, thanks for considering confidential bugs as part of this process. This was my main reason for not using moz-review. We've completed the