1452011 - XPIDL parser should probably reject [noscript] in non-[builtinclass] interface

Status: NEW

(Core :: XPCOM, enhancement)

Description

[Xidorn Quan [:xidorn] UTC+10]

It seems that it currently rejects [infallible] attributes in that case. I don't think [noscript] can be implemented by script... so probably they should be banned from non-[builtinclass] interfaces as well.

Comment 1

[Xidorn Quan [:xidorn] UTC+10]

So it is not doable. At least nsINetAddr has implementation in JavaScript[1] while it also has [noscript] method[2].

I have no idea how this can work...


[1] https://searchfox.org/mozilla-central/rev/d0413b711da4dac72b237d0895daba2537f1514c/dom/presentation/tests/mochitest/PresentationSessionChromeScript.js#259-264
[2] https://searchfox.org/mozilla-central/rev/d0413b711da4dac72b237d0895daba2537f1514c/netwerk/base/nsINetAddr.idl#87

Comment 2

[Boris Zbarsky [:bzbarsky]]

> I don't think [noscript] can be implemented by script...

Sure.  Trying to call it on the C++ side on a JS implementation will return a failure nsresult.

That wasn't an option with [infallible], obviously.  ;)

While it seems like it would be nice if people were clear on whether they expect their interface to be implemented in JS or not, one can sort of imagine a noscript API that you try first and if that fails try a scriptable API that might still do (part of?) what you want...

Comment 3

[Andrew McCreight [:mccr8]]

I could imagine some kind of "noscriptish" property that does the current fallback, and then a stronger noscript property that bans non-[builtinclass] interfaces. I don't know if that's worth the trouble. At a certain point, you might be better off deCOMing things.