Re: Switching to async/await from Task.jsm/yield

One issue I have just spotted is that Task.jsm uses a JavaScript implementation of promises under the hood while async/await obviously uses our native implementation in the JS engine. This may mean the two have slightly different characteristics. That shouldn't matter for new code written but may

Re: windows build anti-virus exclusion list?

On 3/17/2017 1:45 AM, Honza Bambas wrote: I have a very similar setup, with even way more exceptions added, but none of them has the desired effect. Unfortunately, the only way to make MsMpEng shut up is to disable run-time protection completely for the time of the build. I think it's a bug in

Re: windows build anti-virus exclusion list?

On Fri, Mar 17, 2017, at 01:12 PM, Chris Peterson wrote: > On 3/17/2017 1:45 AM, Honza Bambas wrote: > > I have a very similar setup, with even way more exceptions added, but > > none of them has the desired effect. Unfortunately, the only way to make > > MsMpEng shut up is to disable run-time

Please do NOT hand-edit web platform test MANIFEST.json files

We have tools for this: "mach wpt-manifest-update" will do the right thing. The typical result of hand-edits is that later changesets that do use the tools end up conflicting with each other, as they all fix up the incorrect hand-edits. Please don't cause this pain for other developers and

Re: windows build anti-virus exclusion list?

I filed meta bug 1326328 [1] a few months ago for tracking things we can do to improve Windows build times. It would be great to file / block existing bugs against the meta bug to track these issues. There hasn't been much traction on any of the bugs though, perhaps a good topic for the next

Re: Switching to async/await from Task.jsm/yield

On Fri, Mar 17, 2017 at 10:19:02AM -0700, Dave Townsend wrote: One issue I have just spotted is that Task.jsm uses a JavaScript implementation of promises under the hood while async/await obviously uses our native implementation in the JS engine. This may mean the two have slightly different

Re: Third Party Library Alert Service

Le 17/03/2017 à 19:40, trit...@mozilla.com a écrit : > On Friday, March 17, 2017 at 1:35:15 PM UTC-5, Sylvestre Ledru wrote: >> Looks like we are duplicating some contents and efforts with: >> https://dxr.mozilla.org/mozilla-central/source/tools/rewriting/ThirdPartyPaths.txt >> Any plan to

Re: Third Party Library Alert Service

On Fri, Mar 17, 2017 at 3:26 PM, Sylvestre Ledru wrote: > > > Le 17/03/2017 à 19:40, trit...@mozilla.com a écrit : >> On Friday, March 17, 2017 at 1:35:15 PM UTC-5, Sylvestre Ledru wrote: >>> Looks like we are duplicating some contents and efforts with: >>>

Re: windows build anti-virus exclusion list?

On Fri, Mar 17, 2017, at 02:20 PM, Ben Kelly wrote: > On Fri, Mar 17, 2017 at 1:36 PM, Ted Mielczarek > wrote: > > > Back to the original topic, I recently set up a fresh Windows machine > > and I followed the same basic steps (enable performance power mode, > > whitelist a

Re: windows build anti-virus exclusion list?

On 3/17/17 3:40 PM, Ted Mielczarek wrote: We do try to build js/src pretty early in the build We do? It's always the last thing I see building before we link libxul. Seeing the js/src stuff appearing is how I know my build is about done... -Boris

Re: windows build anti-virus exclusion list?

It looks like there's bug 1188823 [1] for enabling fastlink to improve link times, but that's in a bad way right now. FWIW on my ThankPad laptop I have clobber build times in the 35 - 40 minute range, so even things that seem small for a 16 core desktop are a bigger win for me. -e [1]

Re: Third Party Library Alert Service

Le 17/03/2017 à 19:30, Tom Ritter a écrit : > As part of a broader initiative to perform a security review of the > third party libraries we use, there is now a semi-automated service > that can file bugs when upstream libraries are newer than the one we > embed. > > Closely tracking upstream

Re: Third Party Library Alert Service

I also want this information programmatically for the clang plugin at some point. It will be useful for many of the checks which we can't enforce on third party code due to not being able to / wanting to modify them directly. Right now we have a decent number of check-specific whitelists which

Re: windows build anti-virus exclusion list?

On Fri, Mar 17, 2017 at 3:40 PM, Ted Mielczarek wrote: > Yeah, the JS engine uses a lot more complex C++ features than the rest of > the code in our tree, so it takes longer to compile. This is also why the > `FILES_PER_UNIFIED_FILE` setting is lower in js/src than the rest

Re: windows build anti-virus exclusion list?

On 03/17/2017 12:40 PM, Ted Mielczarek wrote: On Fri, Mar 17, 2017, at 03:16 PM, Ben Kelly wrote: For the 1:38 between Unified_cpp_js_src9.cpp and Interpreter.cpp only a single cl.exe process is running. I guess thats closer to 8% of the total build time. Still seems very weird to me.

Re: Third Party Library Alert Service

On Fri, Mar 17, 2017, at 02:40 PM, trit...@mozilla.com wrote: > On Friday, March 17, 2017 at 1:35:15 PM UTC-5, Sylvestre Ledru wrote: > > Looks like we are duplicating some contents and efforts with: > > https://dxr.mozilla.org/mozilla-central/source/tools/rewriting/ThirdPartyPaths.txt > > Any

Re: windows build anti-virus exclusion list?

On Fri, Mar 17, 2017, at 02:43 PM, Ted Mielczarek wrote: > Similarly, I heard from someone (I can't remember who it was) that said > they could do a Linux Firefox build in ~8(?) minutes on the same > hardware. (I will try to track down the source of that number.) That > gives us a fair lower-bound

Re: windows build anti-virus exclusion list?

On Fri, Mar 17, 2017 at 1:36 PM, Ted Mielczarek wrote: > Back to the original topic, I recently set up a fresh Windows machine > and I followed the same basic steps (enable performance power mode, > whitelist a bunch of stuff in Windows Defender) and my build seemed >

Re: Third Party Library Alert Service

On Friday, March 17, 2017 at 1:35:15 PM UTC-5, Sylvestre Ledru wrote: > Looks like we are duplicating some contents and efforts with: > https://dxr.mozilla.org/mozilla-central/source/tools/rewriting/ThirdPartyPaths.txt > Any plan to "merge" them? There is now! (Or, well, there will be one.) =)

Re: windows build anti-virus exclusion list?

On Fri, Mar 17, 2017 at 2:52 PM, Ben Kelly wrote: > On Fri, Mar 17, 2017 at 2:43 PM, Ted Mielczarek > wrote: > > Yeah, I specifically meant "CPU-bound during the compile tier", where we >> compile all the C++ code. If you look at the resource usage

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

On Fri, Mar 17, 2017 at 11:44:08AM +0200, Henri Sivonen wrote: On Thu, Mar 16, 2017 at 8:12 PM, Kris Maglione wrote: On Wed, Mar 15, 2017 at 11:35:10PM +0200, Henri Sivonen wrote: What's the current outlook on letting chrome JS read ArrayBuffers as opposed to JS strings

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

On 2017-03-16 2:29 PM, Bobby Holley wrote: > On Thu, Mar 16, 2017 at 11:23 AM, R Kent James wrote: > >> On 3/15/2017 3:51 PM, Benjamin Smedberg wrote: >> >>> after Firefox 57 when >>> Webextensions are the only extensions, if our product no longer needs some >>> functionality

Re: windows build anti-virus exclusion list?

On Fri, Mar 17, 2017 at 6:31 PM, Mike Hommey wrote: > On Fri, Mar 17, 2017 at 03:53:14PM -0400, Boris Zbarsky wrote: >> On 3/17/17 3:40 PM, Ted Mielczarek wrote: >> > We do try to build js/src pretty early in the build >> >> We do? It's always the last thing I see building

Posthumous intent to unship: experimental createImageBitmap() overload accepting ArrayBuffer and ArrayBufferView arguments

Last night, we were informed of security vulnerabilities in the implementation of an experimental extension to createImageBitmap() accepting ArrayBuffer and ArrayBufferView arguments which, as it turns out, was accidentally shipped in bug 1141979. After careful examination it became clear that

Re: Switching to async/await from Task.jsm/yield

On 2017-03-16 6:29 PM, Dave Townsend wrote: > For a long time now we've been writing JS code that waits for promises > using Task.jsm and generator functions. Recently though the JS team > added support for the JS standard way of doing this, async/await: >

Re: windows build anti-virus exclusion list?

On Fri, Mar 17, 2017 at 07:13:03PM -0400, Nathan Froyd wrote: > On Fri, Mar 17, 2017 at 6:31 PM, Mike Hommey wrote: > > On Fri, Mar 17, 2017 at 03:53:14PM -0400, Boris Zbarsky wrote: > >> On 3/17/17 3:40 PM, Ted Mielczarek wrote: > >> > We do try to build js/src pretty early in

Re: Third Party Library Alert Service

We have library imports that are forks, for example dom/media/webaudio/blink, as the README file explains. That should probably be removed from that list. On 2017-03-17 2:30 PM, Tom Ritter wrote: > As part of a broader initiative to perform a security review of the > third party libraries we

Re: windows build anti-virus exclusion list?

On Fri, Mar 17, 2017 at 03:53:14PM -0400, Boris Zbarsky wrote: > On 3/17/17 3:40 PM, Ted Mielczarek wrote: > > We do try to build js/src pretty early in the build > > We do? It's always the last thing I see building before we link libxul. > Seeing the js/src stuff appearing is how I know my

Re: Switching to async/await from Task.jsm/yield

On Fri, Mar 17, 2017 at 07:30:46PM -0400, Ehsan Akhgari wrote: Have we measured the performance of our async/await implementation? I think we should definitely do some extensive testing of the performance of any new ES primitives before deciding to switch to using them in the front-end code en

Third Party Library Alert Service

As part of a broader initiative to perform a security review of the third party libraries we use, there is now a semi-automated service that can file bugs when upstream libraries are newer than the one we embed. Closely tracking upstream can ensure we don't inherit publicly known vulnerabilities.

Re: windows build anti-virus exclusion list?

On Fri, Mar 17, 2017 at 2:43 PM, Ted Mielczarek wrote: > > The 14min measurement must have been for a partial build. With defender > > disabled the best I can get is 18min. This is on one of the new lenovo > > p710 machines with 16 xeon cores. > > Nope, full clobber

Re: windows build anti-virus exclusion list?

On Fri, Mar 17, 2017, at 03:16 PM, Ben Kelly wrote: > On Fri, Mar 17, 2017 at 2:52 PM, Ben Kelly wrote: >> On Fri, Mar 17, 2017 at 2:43 PM, Ted Mielczarek >> wrote: >> >> >> >> >> >>> Yeah, I specifically meant "CPU-bound during the compile

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

On Thu, Mar 16, 2017 at 8:12 PM, Kris Maglione wrote: > On Wed, Mar 15, 2017 at 11:35:10PM +0200, Henri Sivonen wrote: >> >> What's the current outlook on letting chrome JS read ArrayBuffers as >> opposed to JS strings where the high 8 bits are zero and the low 8 >> bits

Re: The future of commit access policy for core Firefox

And yet, despite many people’s concerns, it appears that policy of removing r+ whenever a new push has been made effective. And so, here I am with a r+ requesting to fix a comment, I have to ask for r+ again from someone not in my timezone and already on week-end. Turn around time, from 30

Re: The future of commit access policy for core Firefox

On Fri, Mar 17, 2017 at 12:41 AM, Jean-Yves Avenard wrote: > And yet, despite many people’s concerns, it appears that policy of > removing r+ whenever a new push has been made effective. > To my knowledge, mconnor's proposal has yet to get anywhere close to an actual

Re: windows build anti-virus exclusion list?

I have a very similar setup, with even way more exceptions added, but none of them has the desired effect. Unfortunately, the only way to make MsMpEng shut up is to disable run-time protection completely for the time of the build. I think it's a bug in Defender. On a 20 core system it saves

Do we actually have use cases for rejecting non-characters in UTF-8ness check?

Our IsUTF8() by default rejects strings that contain code points whose lowest 16 bits are 0xFFFE or 0x. Do we actually have use cases for rejecting such strings in UTF-8ness checks? The code was introduced in https://bugzilla.mozilla.org/show_bug.cgi?id=191541 and both the patch author and

Re: Do we actually have use cases for rejecting non-characters in UTF-8ness check?

On Fri, Mar 17, 2017 at 12:12 PM, Henri Sivonen wrote: > The callers aren't many, but they involve protocols and formats that > I'm not familiar with on the quirk level of detail: > https://searchfox.org/mozilla-central/search?q=symbol:_Z6IsUTF8RK10nsACStringb=false > > As a

Proper way to return nsresult from Rust before Stylo is mandatory?

It seems that our Rust bindings for nsresult are part of Stylo, but Stylo isn't yet a guaranteed part of the build. Until Stylo becomes a mandatory part of the build, what's the proper way to return nsresult from Rust such that it works with or without Stylo enabled? -- Henri Sivonen

Re: Do we actually have use cases for rejecting non-characters in UTF-8ness check?

On Fri, Mar 17, 2017 at 11:00 AM, Henri Sivonen wrote: > Our IsUTF8() by default rejects strings that contain code points whose > lowest 16 bits are 0xFFFE or 0x. > > Do we actually have use cases for rejecting such strings in UTF-8ness checks? I'm not aware of any

Re: Do we actually have use cases for rejecting non-characters in UTF-8ness check?

On Fri, Mar 17, 2017 at 12:12 PM, Anne van Kesteren wrote: > On Fri, Mar 17, 2017 at 11:00 AM, Henri Sivonen wrote: >> Our IsUTF8() by default rejects strings that contain code points whose >> lowest 16 bits are 0xFFFE or 0x. >> >> Do we actually have

Re: Proper way to return nsresult from Rust before Stylo is mandatory?

I don't think we have any particularity good tools for this right now. A while ago I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1320179 to add a separate crate like the nsstring crate which provides the nsresult bindings. If we are starting to get more use cases for it we probably want to

Re: Proper way to return nsresult from Rust before Stylo is mandatory?

On Fri, Mar 17, 2017 at 12:03:30PM +0200, Henri Sivonen wrote: > It seems that our Rust bindings for nsresult are part of Stylo, but > Stylo isn't yet a guaranteed part of the build. FWIW those bindings are only checked-in into Servo for CI purposes (so we can build the Gecko version of the style

Re: The future of commit access policy for core Firefox

On Fri, Mar 17, 2017 at 3:55 AM, Bobby Holley wrote: > On Fri, Mar 17, 2017 at 12:41 AM, Jean-Yves Avenard > > wrote: > > > And yet, despite many people’s concerns, it appears that policy of > > removing r+ whenever a new push has been made