From bug 553102: (In reply to Edward Lee :Mardak from comment #100) > Fabrice, it also seems like each object level needs to have __exposedProps__ > because accessing this.result.manifest.name from getSelf() triggers the > warning. (Test by running the following on an origin with an app installed.) > > navigator.mozApps.getSelf().onsuccess = function() this.result.manifest.name Oh, I thought we didn't need that for plain jsvals...

Can you create the relevant objects in the content compartment?

(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #1) > Can you create the relevant objects in the content compartment? Is there a way to do that in chrome JS?

This patch removes the manifest-related warnings, and also the one fired when returning arrays of apps.

I'm not sure if I'm the right person to be reviewing this, but do we want a general purpose wrapObjectIn or should we be explicit in what we expose from the manifest? Would being explicit just involve setting an __exposedProps__ hash of readable properties?

(In reply to Edward Lee :Mardak from comment #5) > I'm not sure if I'm the right person to be reviewing this, but do we want a > general purpose wrapObjectIn or should we be explicit in what we expose from > the manifest? Would being explicit just involve setting an __exposedProps__ > hash of readable properties? There are two issues with this approach: - we need to take care of nested structures in the manifest (eg, icons, authors, locales) and this will be very painful without introspecting. - the manifest structure is not stable, and can potentially have extension points, so it's hard to whitelist only the properties we want.