509103 - Drop support for assigning to parameterized properties

Status: RESOLVED FIXED

(Core :: XPConnect, defect)

Description

[Jason Orendorff [:jorendorff]]

JS plans to delete JS_SetCallReturnValue2.  Its sole caller in the Mozilla codebase is XPCDispObject::Invoke(), where it is used to implement something called "parameterized properties".

If anyone knows a good reason to keep that, now's a good time to speak up.

Comment 1

[Benjamin Smedberg]

That's part of the xpconnect support for scripting IDispatch wrappers on Windows.

I don't know what parameterized properties are, though... the test at http://mxr.mozilla.org/mozilla-central/source/js/src/xpconnect/tests/idispatch/Tests/WrappedCOM might be informative. Or we could just agree to drop support for IDispatch (that would make xpconnect simpler and make me happy). My only concern is that Fennec wants to use the ActiveX control wrapper for Flash on WinCE, and I'm not sure whether that requires IDispatch scripting support or not.

Comment 2

[Benjamin Smedberg]

ah, http://mxr.mozilla.org/mozilla-central/source/js/src/xpconnect/tests/idispatch/Tests/WrappedCOM/Attributes/XPCIDispatchAttributeTests.js#88

Comment 3

[Jason Orendorff [:jorendorff]]

OK, Cc:ing bent and stuart then.

If y'all don't need IDispatch, I'm willing to rip it out.

Comment 4

[Brendan Eich [:brendan]]

Why don't we break just parameterized property assignment? I doubt anything Fennec would rely on will care. With these lvalue-return APIs, IIRC, there is invariably another way to say the same thing without putting a call on the left of assignment. We supported lvalue returns in SpiderMonkey simply to free folks using VB-ish code from having to rewrite.

/be

Comment 5

[Jason Orendorff [:jorendorff]]

Well, if we *can* rip out IDispatch support, we should -- nobody's in favor of keeping a bunch of tricky code that we don't need, right?

And deleting a bunch of files sounds real easy, maybe even easier than narrowly removing this feature.  Certainly easier than narrowly removing this feature and *then* deleting all the rest anyway.

Comment 6

[Jason Orendorff [:jorendorff]]

Nobody seems to know if it's ok to remove IDispatch support or not. I'll just break parameterized property assignment.

Comment 7

[David Bradley]

Microsoft was supposedly deprecating ActiveX in favor of .Net. Maybe now is the time to end support here.

What I don't know is what the impact of this would be. I can't imagine the general "consumer" market would have any noticeable impact. If this is used much at all I would expect it to be used by companies that have legacy ActiveX controls they've built for IE and now have moved to FireFox and have it use these ActiveX controls. I'm sure some of these instances can get by just by instantiating the control and don't need IDispatch support.

Lastly parametrized properties are often used in the "item" mechanism where you have a collection of items. So removing parametrized property support would break some aspects of Windows Media Player (manipulating playlists for one) as one example. "items" is a pretty common convention in ActiveX world of accessing a collection of things. So removing support definitely could break access to some ActiveX controls.

Comment 8

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

No, there is no impact on Firefox if we remove IDispatch support.  We should do that as soon as we can, however we have a need to keep the activex shunt limping along for plugins for at least a few more months.

Comment 9

[Jason Orendorff [:jorendorff]]

Attachment: v1

Comment 10

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Comment on attachment 394354 [details] [diff] [review]
v1

r=shaver; that's a sweet blast of minuses, that is.

Comment 11

[Jason Orendorff [:jorendorff]]

http://hg.mozilla.org/tracemonkey/rev/2983b136963a

Comment 12

[Robert Sayre]

http://hg.mozilla.org/mozilla-central/rev/2983b136963a