1029248 - Allow CPOWs to be converted to native interfaces

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

The purpose of this bug is to allow CPOWs to masquerade as interfaces like HTMLDocument, which normally don't allow scripted implementations.

Comment 1

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Attachment: cpow-wrapping

This patch adds a new IsWrappedCPOW that unwraps an object before testing if it's a CPOW. There were a few existing places where we did this, and I found more where we were missing the unwrapping. I also think CheckedUnwrapped is the way to go. We absolutely shouldn't be exposing CPOWs to content.

Comment 2

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Attachment: cpow-scriptable

If we need to pass a CPOW to a function over XPIDL, we may need to QI it to some non-scriptable interface like HTMLDocument. This patch bypasses the checks that normally would forbid that.

I think the main danger here is that C++ code will assume that it can cast an nsIHTMLDocument or whatever to something concrete. I'm going to try to figure out a way that we can prevent passing CPOWs to C++ code, possibly with some exceptions whitelisted. However, I'd like to take this now so that we can make progress on add-on compatibility.

Comment 3

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Attachment: cpow-wrapping v2

I probably should have tried to compile these before posting them.

Comment 4

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Attachment: cpow-scriptable v2

Comment 5

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 8445588 [details] [diff] [review]
cpow-scriptable v2

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

This is OK because we also have builtinclass, right?

Comment 6

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/4907115e02e3
remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/4a19dcbc7e7a

(In reply to Blake Kaplan (:mrbkap) from comment #5)
> This is OK because we also have builtinclass, right?

Yes, that should offer some protection.

Comment 7

[Ryan VanderMeulen [:RyanVM]]

Backed out for non-unified bustage.
https://hg.mozilla.org/integration/mozilla-inbound/rev/3002e0200450

https://tbpl.mozilla.org/php/getParsedLog.php?id=43047696&tree=Mozilla-Inbound

Comment 8

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/f8be8f1a923b
https://hg.mozilla.org/integration/mozilla-inbound/rev/c7df28f9f545

Comment 9

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/f8be8f1a923b
https://hg.mozilla.org/mozilla-central/rev/c7df28f9f545