1068389 - Add a way to prevent exposing XPIDL interfaces to C++

Status: RESOLVED WONTFIX

(Core :: XPCOM, defect)

Description

[(no longer active)]

Bobby is right in bug 1067340 comment 7, we should make it impossible to call nsIDOMWindowUtils to C++.

Instead of doing a one-off hack, how about adding an interface attribute called [scriptonly] that will add include guards to the generated header to make sure that only the implementation translation unit can see it.  Something like:

// nsIFoo.h

// normal header guard goes here

#ifdef __impl_nsIFoo__

class nsIDOMWindowUtils ... {
  ...
};

#endif


// nsFoo.cpp

#define __impl_nsIFoo__
#include "nsIFoo.h"
#include "nsFoo.h"

...


// nsFoo.h

// Assume nsIFoo is available.  This makes nsFoo.h usable only in nsFoo.cpp.
class nsFoo : public nsIFoo {
  ...
};


Thoughts?

Comment 1

[Trevor Saunders (:tbsaunde)]

Well, you'll have to define __IMPL_nsIWhatever in the header not the cpp file, which may or may not be ok depending on how many other things use your object.  It seems like this is fine in the case of nsDOMWindowUtils.h which is only included in
./content/media/webrtc/MediaEngineTabVideoSource.cpp:#include "nsDOMWindowUtils.h"
./dom/base/nsGlobalWindow.cpp:#include "nsDOMWindowUtils.h"
./dom/base/nsDOMWindowUtils.cpp:#include "nsDOMWindowUtils.h"

However other things could implement an xpcom interface and have C++ stuff on them, and then you might end up exposing the xpcom interface to a bunch of stuff.

ANother option would be to have your attribute imply thing named "x" in the .idl gets binaryname(ScriptOnlyX).  That's not really great either though.

Comment 2

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Making the nsIDOMWindowUtils getter be implicit_jscontext would probably be enough to dissuade most people :P.

Comment 3

[Boris Zbarsky [:bzbarsky]]

The getter is via getInterface, sadly.

What we could do very easily is binaryname() all the things to names that say something like DoNotCallExceptFromJSTheActualName or something.  I guess comment 1 mentioned that approach too.  It seems nice and simple and not involving lots of investment in xpidl gunk.

Comment 4

[Nathan Froyd [:froydnj]]

I think it would be reasonable to make [scriptonly] (bikeshed paint name: js_callers_only) imply magic binaryname'ing of the interface members, ala comment 1 and comment 3.

Comment 5

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Why don't we just move the object to WebIDL and then not expose a getter for the concrete type?

Comment 6

[Boris Zbarsky [:bzbarsky]]

Oh, nice.  That sounds pretty doable.

Comment 7

[(no longer active)]

Note that currently there is no getter, as Boris suggested.  Should we do something such as make GetInterface return something is IsCallerChrome returns true or some such?

Comment 8

[Boris Zbarsky [:bzbarsky]]

If we do the webidl thing, we can just make the xpidl interface empty.  Then you can getInterface it, but can't do anything with it from C++.

Comment 9

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

I'm going to declare this WONTFIX in favor of that.  XPIDL interfaces are pretty tightly bound to C++, and we already have an interface system that's bound to JS instead.  We can consider reopening this if WebIDL doesn't work out for some reason.

Comment 10

[(no longer active)]

OK, sounds good!