Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

Bobby Holley 2018 March 12 at 12:25 That's not how I'd define XPCOM - XPCOM existed before XPIDL/XPConnect (and the name XPConnect means "connecting Javascript to XPCOM"). But quibbling over the definition isn't really useful. I was aware that XPCOM predated

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

On 3/26/18 6:29 PM, Myk Melez wrote: Do any of those bits of C++ code depend on a particular feature of XPCOM They depend on the dynamic casting provided by QueryInterface. That said, they could in many cases switch to other methods of dynamic casting that are more limited... or do they

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

On Mon, Mar 12, 2018 at 11:56 AM, Myk Melez wrote: > Nicholas Nethercote > 2018 March 9 at 20:02 > > What's your definition of XPCOM? > > This is basically what I'm asking Kris. I define it as the system that > Firefox uses to make intra- and inter-language calls between C++

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

On Mon, Mar 12, 2018 at 11:56 AM, Myk Melez wrote: > Nicholas Nethercote > 2018 March 9 at 20:02 > > What's your definition of XPCOM? > > This is basically what I'm asking Kris. I define it as the system that > Firefox uses to make intra- and

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

Nicholas Nethercote 2018 March 9 at 20:02 What's your definition of XPCOM? This is basically what I'm asking Kris. I define it as the system that Firefox uses to make intra- and inter-language calls between C++ and JS via XPIDL and XPConnect. I'm interested in

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

On Sat, Mar 10, 2018 at 11:11 AM, Myk Melez wrote: > If we removed XPConnect bindings entirely and converted XPIDL interfaces > used only by C++ into concrete native classes, then what else would > continue to need XPCOM? > What's your definition of XPCOM? Look in xpcom/,

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

Kris Maglione 2018 March 8 at 16:22 Removing XPCOM entirely is not really a possibility. Removing XPConnect bindings entirely is... theoretically possible, but would be a monumental amount of work, and is not something I've heard anyone seriously suggest. If we

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

On Fri, Mar 9, 2018 at 11:53 AM, Jeff Muizelaar wrote: > On Fri, Mar 9, 2018 at 7:21 AM, Ted Mielczarek wrote: > > On Thu, Mar 8, 2018, at 7:41 PM, Bobby Holley wrote: > >> (C) The API uses complex arguments like promises that XPIDL doesn't > handle

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

On Fri, Mar 9, 2018 at 7:21 AM, Ted Mielczarek wrote: > On Thu, Mar 8, 2018, at 7:41 PM, Bobby Holley wrote: >> (C) The API uses complex arguments like promises that XPIDL doesn't handle >> in a nice way. > > I think this is an understated point. WebIDL was designed

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

On Fri, Mar 9, 2018 at 12:15 AM, Zibi Braniecki (Gandalf) < zbranie...@mozilla.com> wrote: > > > On Thu, Mar 8, 2018 at 7:09 PM, Bobby Holley > wrote: > >> I just looked at the first 10 methods/attributes on that interface. None >> of them are remotely

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

On 09/03/2018 00:06, Kris Maglione wrote: There are different costs to WebIDL and XPIDL bindings. WebIDL bindings have more cost in terms of compiled code size. XPIDL have greater costs in terms of performance and runtime memory. It's not that simple. In terms of runtime memory for example,

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

On Thu, Mar 8, 2018, at 7:41 PM, Bobby Holley wrote: > (C) The API uses complex arguments like promises that XPIDL doesn't handle > in a nice way. I think this is an understated point. WebIDL was designed explicitly to allow expressing the semantics of JS APIs, where XPIDL is some arbitrary set

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

On Thu, Mar 8, 2018 at 7:09 PM, Bobby Holley wrote: > I just looked at the first 10 methods/attributes on that interface. None > of them are remotely performance-sensitive, and several are test-only. If > we see certain methods on it show up in profiles, we should move

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

On Fri, Mar 9, 2018 at 1:16 AM, Stuart Philp wrote: > Generally I think we’d take performance and memory wins over installer > size, but we monitor all three and if installer size grows (gradually) by > an uncomfortable amount we ought to make a call on the trade off. We can >

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

On 3/8/18 11:29 PM, Boris Zbarsky wrote: I expect there is, but it wasn't super-obvious low-hanging fruit. Sorry, I should have been clearer: there wasn't super-obvious low-hanging fruit in the getter/setter/method bits. At least the parts of it I poked at. There might also be low-hanging

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

On 3/8/18 8:04 PM, Mike Hommey wrote: Last time I looked at bindings, I was horrified to see all the various strings that all look the same except between bindings for field and class names. So for what it's worth, I tried measuring this recently. When measuring with "size" on Mac, if I just

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

On Fri, Mar 9, 2018, at 9:41 AM, Robert O'Callahan wrote: > It might be worth measuring how that translates to installer code. One > might hope that all that repetitive boilerplate code compresses well > (or can be made to). Testing my local bug 1341546 patches, I get a 59 KiB increase in .tar.bz2

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

On Thu, Mar 8, 2018 at 5:56 PM, Kris Maglione wrote: > On Thu, Mar 08, 2018 at 04:41:38PM -0800, Bobby Holley wrote: > >> On Thu, Mar 8, 2018 at 3:06 PM, Kris Maglione >> wrote: >> >>> That said, if we're worried about binary size becoming an issue

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

On Thu, Mar 08, 2018 at 04:41:38PM -0800, Bobby Holley wrote: On Thu, Mar 8, 2018 at 3:06 PM, Kris Maglione wrote: That said, if we're worried about binary size becoming an issue for internal interfaces, there are things we can do to reduce the code size of bindings.

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

On Fri, Mar 9, 2018 at 2:26 PM, Bobby Holley wrote: > I was just measuring the methods themselves via |nm --print-size|. There > might be additional per-method overhead in the data segment for the > associated static tables, but the baseline size for the code itself >

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

On Fri, Mar 9, 2018, at 8:41 AM, Bobby Holley wrote: > The problem is precisely that it's gradual - a few kilobytes at a > time, certainly nothing to trigger our alerts. Waiting for it all to > pile up and then launching a herculean effort to move things _back_ to > XPIDL would be a huge waste of

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

On Thu, Mar 8, 2018 at 5:04 PM, Mike Hommey wrote: > On Thu, Mar 08, 2018 at 02:40:52PM -0800, Bobby Holley wrote: > > I've seen a lot of momentum around migrating chrome-only XPIDL interfaces > > to WebIDL. I'm concerned that insufficient attention is being paid to the > >

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

On Thu, Mar 08, 2018 at 02:40:52PM -0800, Bobby Holley wrote: > I've seen a lot of momentum around migrating chrome-only XPIDL interfaces > to WebIDL. I'm concerned that insufficient attention is being paid to the > impact on our binary size. > > Fundamentally, the WebIDL bindings improve

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

On Thu, Mar 08, 2018 at 11:16:44PM +, Stuart Philp wrote: > Generally I think we’d take performance and memory wins over installer > size, but we monitor all three and if installer size grows (gradually) by > an uncomfortable amount we ought to make a call on the trade off. We can > bring it

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

On Thu, Mar 8, 2018 at 3:06 PM, Kris Maglione wrote: > On Thu, Mar 08, 2018 at 02:40:52PM -0800, Bobby Holley wrote: > >> I've seen a lot of momentum around migrating chrome-only XPIDL interfaces >> to WebIDL. I'm concerned that insufficient attention is being paid to the

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

Kris Maglione 2018 March 8 at 15:06 At any rate, I don't expect us to convert anywhere near all of our XPIDL interfaces to WebIDL. A lot of them don't need to be exposed to JS at all. A lot of those should still go away, but they don't need WebIDL bindings, just

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

Generally I think we’d take performance and memory wins over installer size, but we monitor all three and if installer size grows (gradually) by an uncomfortable amount we ought to make a call on the trade off. We can bring it to product should that happen. On Thu, Mar 8, 2018 at 6:07 PM Kris

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

On Thu, Mar 08, 2018 at 03:06:57PM -0800, Kris Maglione wrote: The amount of WebIDL overhead I regularly see in profiles can be staggering. The amount of *XPConnect* overhead... ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

On Thu, Mar 08, 2018 at 02:40:52PM -0800, Bobby Holley wrote: I've seen a lot of momentum around migrating chrome-only XPIDL interfaces to WebIDL. I'm concerned that insufficient attention is being paid to the impact on our binary size. Fundamentally, the WebIDL bindings improve performance and

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

I've seen a lot of momentum around migrating chrome-only XPIDL interfaces to WebIDL. I'm concerned that insufficient attention is being paid to the impact on our binary size. Fundamentally, the WebIDL bindings improve performance and spec correctness at the expense of code size (and build times).

PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

It is now possible[1] to create chrome-only WebIDL interfaces in the dom/chrome-webidl/ directory that do not require review by DOM peers after every change. If you maintain an internal performance-sensitive XPIDL interface, or are considering creating one, I'd encourage you to consider