Re: Intent to ship: Allow the overflow shorthand to accept two values.

Yay! This will resolve an issue I filed on the spec, so that's a happy day for me. :) On Wed, Apr 11, 2018 at 3:42 AM, Emilio Cobos Álvarez wrote: > Hi, > > In bug 1453148 I'm planning to implement the CSSWG resolution at: > > https://github.com/w3c/csswg-drafts/issues/2484 > > It's a very unc

Intent to implement: Early, experimental support for application/javascript+binast

# Summary JavaScript parsing and compilation are performance bottlenecks. The JavaScript Binary AST is a domain-specific content encoding for JavaScript, designed to speed up parsing and compilation of JavaScript, as well as to allow streaming compilation of JavaScript (and possibly streaming star

Re: Intent to implement: Early, experimental support for application/javascript+binast

This is awesome. I understand that we already do some kind of pre-compile for our chrome code, is there any plan/benefit to switch to this eventually there? On Wed, Apr 18, 2018 at 9:50 AM David Teller wrote: > # Summary > > JavaScript parsing and compilation are performance bottlenecks. The > J

Re: Intent to implement: Early, experimental support for application/javascript+binast

No plans yet, but it's a good idea. The only reason not to do this (that I can think of) is that we might prefer switching to the Bytecode Cache, which would probably give us even better speed ups. I understand that we can't use the Bytecode Cache for our chrome code yet due to the fact that it us

Re: XPT files shouldn't be added to package-manifest.in any more

Err, so it seems a side-effect of this (which wasn't very obvious to me when this was posted) is that it's now no longer possible to change a .idl file for a JS component in an artifact build and have it "work". Specifically, I ran into this when changing the return type of an extant idl metho

Re: XPT files shouldn't be added to package-manifest.in any more

On 4/18/18 1:54 PM, Gijs Kruitbosch wrote: Err, so it seems a side-effect of this (which wasn't very obvious to me when this was posted) is that it's now no longer possible to change a ..idl file for a JS component in an artifact build and have it "work". So to be clear, this is a case in whic

Re: XPT files shouldn't be added to package-manifest.in any more

On Wed, Apr 18, 2018 at 03:15:23PM -0400, Boris Zbarsky wrote: On 4/18/18 1:54 PM, Gijs Kruitbosch wrote: Given that we're also not supposed to be making new JS-implemented webidl things, what's the long-term plan for artifact build support for changing JS-implemented interfaces? For the spec

Re: XPT files shouldn't be added to package-manifest.in any more

On 4/18/18 3:27 PM, Kris Maglione wrote: Legacy. The blocklist service is ancient, and has some C++ consumers. The JS-only parts wound up getting glommed onto the XPIDL interface over time. I'd already suggested we fix that before I realized it was the cause of this problem. OK. In that case

Using WebIDL objects in XPIDL

Yesterday, bug 1444991 landed on inbound, which adds support for using WebIDL defined objects directly inside of XPIDL definition files. This allows us to avoid using nsISupports to pass WebIDL objects which don't have corresponding XPIDL inte

Re: Using WebIDL objects in XPIDL

On Thu, Apr 19, 2018, at 1:19 PM, Nika Layzell wrote: > This allows us to avoid using nsISupports to pass WebIDL objects which > don't have corresponding XPIDL interfaces through XPIDL defined methods. Thanks Nika, this is great! Avoiding nsIDOMBlah interfaces in C++ was one of the reasons that