634156 - ConsoleAPI.js and InstallTrigger.js should not use sandboxes

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Andreas Gal :gal]

We currently use a sandbox to bind chrome functions to content objects. We could just do contentWindow.wrappedJSObject.Function.bind.call instead. Content can overwrite bind and intercept the wrapped chrome objects, but thats fine. We have __exposedProps__ in place so thats safe. This would be much faster and saves memory. Patrick, want to give this a try? Jonas and mrbkap should review.

Comment 1

[Andreas Gal :gal]

I would take an approved patch to avoid any further runaway situations.

Comment 2

[(no longer active)]

Attachment: Patch (v1)

Like this?

Comment 3

[Andreas Gal :gal]

Comment on attachment 522698 [details] [diff] [review]
Patch (v1)

Yeah, this is roughly what we had in mind. However, mrbkap was concerned that a malicious page might overwrite Function.bind, and then trick us into calling that. To be honest, I don't think anything bad would happen here. We are passing the chromeObject to bind, but its wrapped and you can't do much with it, so I would be ok with it, but mrbkap should make the final call.

Comment 4

[(no longer active)]

This breaks numerous tests:

1 in mochitest-4:
http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTry/1301429260.1301433190.17280.gz

1 in mochitest-5:
http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTry/1301429520.1301430563.3261.gz

324 in mochitest-o (debug):
http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTry/1301429271.1301434384.23735.gz

516 in mochitest-o (opt):
http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTry/1301434202.1301437331.7956.gz

I don't really know what I should do to address these, so I'm just unassigning myself, but hopefully somebody can pick up where I left off.

Comment 5

[Blake Kaplan (:mrbkap) (inactive)]

I have a patch in progress to fix this.

Comment 6

[Nicholas Nethercote [inactive]]

Blake, any progress on this?  What situations will it help in, and how much memory might it save?

Comment 7

[Blake Kaplan (:mrbkap) (inactive)]

I have a mostly-working patch (still a bit to do, though). I think this might end up fixing bug 664067.

Comment 8

[Andreas Gal :gal]

I noticed that console.log is ridiculously slow. Is that related to sandboxes?

Comment 9

[Blake Kaplan (:mrbkap) (inactive)]

I would assume not. The sandbox is a one-time creation deal. You do end up going through a couple of cross compartment wrappers because of it, but that shouldn't make it ridiculously slow.

Comment 10

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Please file a separate bug on that issue.

Comment 11

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: wip

This seems to work, but I haven't tested it very heavily yet.

I took the easy way out with this patch by splitting the work into two functions and letting JS code do most of the heavy lifting of figuring out which properties to expose. I can move it back into C++ now if people feel that it's worth it, though.

Comment 12

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: patch v1

Andreas, what do you think of this approach?

Comment 13

[Andreas Gal :gal]

Comment on attachment 539856 [details] [diff] [review]
patch v1

Looks great. Too bad we need C++ here. dherman's modules will fix that.

Comment 14

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 539856 [details] [diff] [review]
patch v1

Johnny, mind commenting on the API? Also requesting review from a JS hacker for his comments on the API.

Comment 15

[Johnny Stenback (:jst)]

Comment on attachment 539856 [details] [diff] [review]
patch v1

Looks good from an API point of view, and in general too! r=jst

Comment 16

[Peter Van der Beken [:peterv]]

Comment on attachment 539856 [details] [diff] [review]
patch v1

Review of attachment 539856 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/src/xpconnect/idl/xpccomponents.idl
@@ +232,5 @@
> +     * To be called from JS only.
> +     *
> +     * Returns an object created in |scope|'s compartment.
> +     */
> +    void /* JSObject */ createObjectIn(/*in JSObject scope */);

Could this use jsval for the argument and the return value and implicit_jscontext to get the JSContext? Might make the implementation a little shorter.

@@ +240,5 @@
> +     *
> +     * Ensures that all functions come from obj's scope (and aren't cross
> +     * compartment wrappers).
> +     */
> +    void makeObjectPropsNormal(/* in JSObject obj */);

Same here.

Comment 17

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Addressing peterv's comment

This is an interdiff addressing comment 16.

Comment 18

[Johnny Stenback (:jst)]

Comment on attachment 541522 [details] [diff] [review]
Addressing peterv's comment

(stealing peterv's review), r=jst. I like the - to + ratio here :)

Comment 19

[Blake Kaplan (:mrbkap) (inactive)]

http://hg.mozilla.org/tracemonkey/rev/ef1c0626aa25

Comment 20

[Blake Kaplan (:mrbkap) (inactive)]

And http://hg.mozilla.org/tracemonkey/rev/208160c856b7 to fix bustage.

Comment 21

[Chris Leary [:cdleary] (not checking bugmail)]

cdleary-bot mozilla-central merge info:
http://hg.mozilla.org/mozilla-central/rev/ef1c0626aa25
http://hg.mozilla.org/mozilla-central/rev/208160c856b7

Comment 22

[Nicholas Nethercote [inactive]]

Comment on attachment 541522 [details] [diff] [review]
Addressing peterv's comment

Asking for Aurora approval.  This was fixed-in-tracemonkey 9 days before the Aurora uplift, but missed out because TM was merged to m-c just too late.

I think it should be granted Aurora approval.  It would have gone in anyway if it wasn't for the late TM merge, so the risk doesn't seem higher than normal bugs.  The benefit is that it fixed 664067 which was a very good thing -- there are a lot of Facebook like buttons and Google +1 buttons on the web, and this makes at least some of them more efficient.

Comment 23

[Nickolay_Ponomarev]

dev-doc-needed for new Components.utils methods.

Comment 24

[Nicholas Nethercote [inactive]]

Comment on attachment 541522 [details] [diff] [review]
Addressing peterv's comment

Aurora approval no longer required, thanks to the special merge of late-landing TM things (http://hg.mozilla.org/releases/mozilla-aurora/rev/75552dfd25c2).

Comment 25

[Eric Shepherd [:sheppy]]

Documentation has been written. A review would be appreciated (especially of the code example, which was admittedly pieced together from the patch without expressly being tested):

https://developer.mozilla.org/en/Components.utils.createObjectIn
https://developer.mozilla.org/en/Components.utils.makeObjectPropsNormal

These pages have been updated to link to the new content:

https://developer.mozilla.org/en/Components_object
https://developer.mozilla.org/en/Components.utils
https://developer.mozilla.org/en/SpiderMonkey/JSAPI_Reference/JS_NewObject

Also linked from Firefox 8 for developers.