679872 - Support for returning a Javascript object from C++

Status: RESOLVED FIXED

(Core :: XPConnect, defect)

Description

[Jeff Muizelaar [:jrmuizel]]

We would like to rewrite the way the GfxInfo class works. Currently it's an interface with a bunch of getters, this is a pain because we have to worry about getters throwing exceptions and we need to stub getters on different platforms.

It would be much nicer if we could just return a javascript object with a bunch of properties set. nsIPropertyBag is sort of like this, except it seems very painful to use from javascript:
http://mxr.mozilla.org/mozilla-central/source/layout/tools/reftest/reftest.js#1489

What's the best way for us to do this?

Comment 1

[Andreas Gal :gal]

You should be able to return a jsval in idl, and then use the JS API to make that object. I am happy to help with API questions and review.

Comment 2

[Benjamin Smedberg]

You want to change this because the API sucks, or because it's inefficient? There are two possible ways to solve this:

wrap the API in a JSM: keep the existing XPCOM badness, but have the JSM turn this into a single pretty JS object before handing it back to callers. This is the inefficient but "safe" way.

The perhaps more efficient way would be to return a jsval and hand-construct the a JS object. But this involves using raw JSAPI and is really only a good idea in very special cases.

Comment 3

[Jeff Muizelaar [:jrmuizel]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #2)
> You want to change this because the API sucks, or because it's inefficient?
> There are two possible ways to solve this:
> 
> wrap the API in a JSM: keep the existing XPCOM badness, but have the JSM
> turn this into a single pretty JS object before handing it back to callers.
> This is the inefficient but "safe" way.

The API is bad on both sides. I'm more interested in fixing the pain on the C++ side though and this approach won't help there.

> The perhaps more efficient way would be to return a jsval and hand-construct
> the a JS object. But this involves using raw JSAPI and is really only a good
> idea in very special cases.

This looks like it will match what we need. I'd be much happier to wrap raw JSAPI in shiny safety if it needs it then continue to have the pain that we have on the C++ side.