Using WebIDL objects in XPIDL

[Nika Layzell]

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 interfaces through XPIDL defined methods.

WebIDL objects must be forward declared, like XPIDL types, in the .idl file
which uses them:

  // C++ 'nsFrameLoader', from FrameLoader.webidl
  webidl FrameLoader;

  // C++ 'mozilla::dom::DataTransfer', from DataTransfer.webidl
  webidl DataTransfer;

These types may then be used like XPIDL types in method and attribute
declarations. These types can be used from both C++ and JS code. They are
exposed into Rust as '*const ::libc::c_void`.

- NIka
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using WebIDL objects in XPIDL

[Cameron McCormack]

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 prompted me recently to try converting some interfaces from 
XPIDL to Web IDL, so it's really nice that we can now avoid that awkwardness 
and also avoid the code size overhead that a conversion to Web IDL would cause.

Cameron
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using WebIDL objects in XPIDL

[Boris Zbarsky]

On 4/18/18 11: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.


This is awesome.

In particular, it means we can pass WebIDL things through XPIDL without 
adding weird "QI to the concrete type" bits to them.  This should let us 
make pretty rapid progress on 
https://bugzilla.mozilla.org/show_bug.cgi?id=1387169 and in particular 
on getting rid of things like nsIDOMNode/nsIDOMEvent/nsIDOMDocument.


Thank you for doing this,
Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using WebIDL objects in XPIDL

[Gijs Kruitbosch]

Dumb question because I don't do this very often - sorry!

I am intending to async-ify a sync JS-implemented idl-defined API (which 
currently returns an unsigned long), that has a few C++ consumers. I was 
thinking the simplest solution would be a separate method definition in 
the idl that took a separate interface (nsIFooCallback) that then got 
the long and/or any other data we needed to pass. This because returning 
a promise seems to previously have involved returning jsval and then 
things get more complicated from there. The only in-tree .idl uses I saw 
for Promise are in the wpt test idl files, which I presume don't reflect 
our ability to implement that as a return type.


If I understand correctly, with these changes I could now just use 
Promise instead. Is that correct? Can I declare it including the 
resolution result of the promise, ie can I now use:


Promise asyncGetFoo()

in xpidl? Because that would make my life considerably easier...

~ Gijs

On 19/04/2018 04:19, Nika Layzell wrote:

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 interfaces through XPIDL defined methods.

WebIDL objects must be forward declared, like XPIDL types, in the .idl file
which uses them:

   // C++ 'nsFrameLoader', from FrameLoader.webidl
   webidl FrameLoader;

   // C++ 'mozilla::dom::DataTransfer', from DataTransfer.webidl
   webidl DataTransfer;

These types may then be used like XPIDL types in method and attribute
declarations. These types can be used from both C++ and JS code. They are
exposed into Rust as '*const ::libc::c_void`.

- NIka



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using WebIDL objects in XPIDL

[Andrew McCreight]

On Thu, Apr 19, 2018 at 12:53 PM, Gijs Kruitbosch 
wrote:

> Dumb question because I don't do this very often - sorry!
>
> I am intending to async-ify a sync JS-implemented idl-defined API (which
> currently returns an unsigned long), that has a few C++ consumers. I was
> thinking the simplest solution would be a separate method definition in the
> idl that took a separate interface (nsIFooCallback) that then got the long
> and/or any other data we needed to pass. This because returning a promise
> seems to previously have involved returning jsval and then things get more
> complicated from there. The only in-tree .idl uses I saw for Promise are in
> the wpt test idl files, which I presume don't reflect our ability to
> implement that as a return type.
>
> If I understand correctly, with these changes I could now just use Promise
> instead. Is that correct? Can I declare it including the resolution result
> of the promise, ie can I now use:
>
> Promise asyncGetFoo()
>
> in xpidl? Because that would make my life considerably easier...
>

Bug 1455217 by Nika is going to add a Promise type to XPIDL.  So I think
you have to wait for that.


> ~ Gijs
>
> On 19/04/2018 04:19, Nika Layzell wrote:
>
>> 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 interfaces through XPIDL defined methods.
>>
>> WebIDL objects must be forward declared, like XPIDL types, in the .idl
>> file
>> which uses them:
>>
>>// C++ 'nsFrameLoader', from FrameLoader.webidl
>>webidl FrameLoader;
>>
>>// C++ 'mozilla::dom::DataTransfer', from DataTransfer.webidl
>>webidl DataTransfer;
>>
>> These types may then be used like XPIDL types in method and attribute
>> declarations. These types can be used from both C++ and JS code. They are
>> exposed into Rust as '*const ::libc::c_void`.
>>
>> - NIka
>>
>>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using WebIDL objects in XPIDL

[Kris Maglione]

\o/

On Wed, Apr 18, 2018 at 11:19:27PM -0400, Nika Layzell wrote:

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 interfaces through XPIDL defined methods.

WebIDL objects must be forward declared, like XPIDL types, in the .idl file
which uses them:

 // C++ 'nsFrameLoader', from FrameLoader.webidl
 webidl FrameLoader;

 // C++ 'mozilla::dom::DataTransfer', from DataTransfer.webidl
 webidl DataTransfer;

These types may then be used like XPIDL types in method and attribute
declarations. These types can be used from both C++ and JS code. They are
exposed into Rust as '*const ::libc::c_void`.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using WebIDL objects in XPIDL

[Kris Maglione]

On Thu, Apr 19, 2018 at 12:58:33PM -0700, Andrew McCreight wrote:

On Thu, Apr 19, 2018 at 12:53 PM, Gijs Kruitbosch 
wrote:

If I understand correctly, with these changes I could now just use Promise
instead. Is that correct? Can I declare it including the resolution result
of the promise, ie can I now use:

Promise asyncGetFoo()

in xpidl? Because that would make my life considerably easier...



Bug 1455217 by Nika is going to add a Promise type to XPIDL.  So I think
you have to wait for that.


This actually isn't as difficult currently as you may expect. At 
least, the difference between XPIDL and WebIDL isn't. From the 
C++ consumer, you'd just have to do:


 RefPtr result(Promise::Resolve(global, cx, resultVal, rv));

Which is more or less what the WebIDL layer does.

The real problem is that you're going to have to do the coercion 
on the resolution value yourself. That problem is the same 
whether you're implementing it in WebIDL or XPIDL.


If you're just dealing with an integer value, that's pretty 
easy. Something like `result.toInt32()` should do the job.


If it's something more complicated, well, it's more complicated. 
But WebIDL dictionary types are probably by far the easiest way 
to handle it.



So, basically what I'm saying is that a callback interface is 
still probably the easiest way to handle this from the C++ side, 
but a Promise should work, and shouldn't be that much harder in 
XPIDL than it is in WebIDL.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using WebIDL objects in XPIDL

[Boris Zbarsky]

On 4/19/18 3:53 PM, Gijs Kruitbosch wrote:
If I understand correctly, with these changes I could now just use 
Promise instead.


Not yet, as Andrew said.  This just makes things declared as "interface 
Something { ... }" in .webidl files work.  Promise is not one of those 
things.


That said, I expect that bug 1455217 will land Very Soon Now.

Also, we have existing magic in XPConnect to make it possible to pass a 
Promise as nsISupports through XPConnect.  Specifically, the rules are 
as follows:


1)  When doing a C++-to-JS conversion, if the type is nsISupports (or 
Promise after Nika's patches in bug 1455217) and the C++ thing is a 
dom::Promise, it gets converted to the underlying SpiderMonkey Promise 
object.


2)  When doing a JS-to-C++ conversion, if the type is nsISupports and 
the JS thing being passed is a SpiderMonkey Promise, it gets wrapped up 
in a dom::Promise and the nsISupports* pointer to that is passed to the 
C++ code.


So today, before Nika's fix, you can write this idl:

  nsISupports doAsyncFoo();  // Implemented in JS

and call it from C++ like so:

  nsCOMPtr result;
  myThing->DoAsync(getter_AddRefs(result));

  RefPtr promise = do_QueryObject(result);
  if (!promise) {
// Callee messed up and returned a non-promise
  }
  // Work with "promise".


Is that correct? Can I declare it including the 
resolution result of the promise


Note that the resolution type is purely documentation in webidl; it 
doesn't affect any behavior.  A function could have Promise as its 
idl return type but mess up and and return a Promise resolved with a 
Node and the bindings won't stop it.


The xpconnect fix above does not add that syntax; it just adds "Promise" 
with no type parameter.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform