[builtinclass] in idl
Jonas Sicking
I recently checked in a fix for bug 661980 [1] which adds support for
marking idl interfaces as [buildinclass]. When an interface is marked
as [builtinclass] it means that XPConnect will refuse to let script
implement it. It also means that other non-C++ means of implementing
it, such as using cross-thread-proxies also will refuse to work.
The advantage of this is that C++ code can rely on that if it gets a
pointer to that interface, it knows that that interface has a "real"
implementation, and not just backed by an XPTStub.
This is especially useful when dealing with content script.
Previously, any interface which we wanted to expose to content script,
could also be implemented by content script. This meant that for
example any time that we got a nsIDOMNode reference from script, we
had to check if it was a "real" node, or one implemented by a content
script object, for example by QIing it to a non-scriptable interface
that we know that all nsIDOMNodes "should" support.
Now we can instead simply add a [builtinclass] marked on the
interface. This makes XPConnect throw if script tried to call a
function which takes a nsIDOMNode argument and pass in a script object
as that argument.
nsIDOMEventTarget [2] is an example of a scriptable interface marked
as [builtinclass].
The idl compiler already enforces that a interface marked as
[builtinclass] is only inherited by other interfaces marked as
[builtinclass]. Eventually we should also force any scriptable
interface which has [notxpcom] to be marked as [builtinclass]. This
because XPTStub can't implement such functions. If you try you'll
likely end up with a corrupted stack or random return values.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=661980
[2] http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/events/nsIDOMEventTarget.idl#72
/ Jonas