Last Comment Bug 679872 - Support for returning a Javascript object from C++
: Support for returning a Javascript object from C++
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: XPConnect (show other bugs)
: unspecified
: x86 Mac OS X
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Andrew Overholt [:overholt]
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-08-17 14:06 PDT by Jeff Muizelaar [:jrmuizel]
Modified: 2011-08-17 14:47 PDT (History)
1 user (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Jeff Muizelaar [:jrmuizel] 2011-08-17 14:06:13 PDT
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 2011-08-17 14:10:57 PDT
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 [:bsmedberg] 2011-08-17 14:12:17 PDT
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] 2011-08-17 14:47:29 PDT
(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.

Note You need to log in before you can comment on or make changes to this bug.