48564 - [xml-rpc] createType not working as before

Status: VERIFIED FIXED

(Core :: XML, defect, P3)

Description

[Jan Varga [:janv]]

before:

var x=xmlrpc.createType(xmlrpc.STRING)
x.data="text";
 

now:
var x=xmlrpc.createType(xmlrpc.STRING)
x=x.QueryInterface(Components.interfaces.nsISupportsString);
x.data="text";

Why I have to QueryInterface ?
In M17 it's working without quering.

Comment 1

[Martijn Pieters]

Hmm, strange. Nothing changed in that area, it seems that
.createInstance(interface) ignores the interface argument.

If it is, than that would be a bug in XPConnect, but just now I have no time to
investigate.

In the meantime, you could try and see what the following code gives you:

  var id = 'component://netscape/supports-string'
  var inf = 'nsISupportsString'
  var x = Components.classes[id].createInstance(Components.interfaces[intf])

This is exactly what happens when you call .createType(xmlrpc.STRING)

Comment 2

[Jan Varga [:janv]]

This code works, I also tried something similar.

I think too that this is bug in XPConnect.
Same function createType works standalone (copied to my script)
problem probably rise when instance is returned as nsISupports

adding jband to CC list

Comment 3

[John Bandhauer]

No, this is not really a bug in XPConnect. I tightened the rules for JS 
Components and closed loopholes that were open only when the caller and the 
component were both implemented in JavaScript.

see my posting:
news://news.mozilla.org/3987B45D.FB8301D2%40netscape.com

and the referenced urls:
http://www.mozilla.org/scriptable/js-components-status.html
http://bugzilla.mozilla.org/show_bug.cgi?id=25180

I'm sorry this change broke your code.

Before this change a JS caller to the JS component was not restricted to the 
semantics of the interface as declared. This was bad. Some things that should 
not have worked for xpcom interfaces did work. You have a case of that here...

The interface says:

    nsISupports createType(in unsigned long type);

If you implement or call this in C++ you would have to QI to the type you want. 
This only worked before because the JS caller was getting direct access to the 
JSObject returned by the JS component implementing the interface. 

XPConnect now enforces the semantics of the interface. This may seem annoying, 
but imagine that at some later time it is decided to implement this same 
interface in C++ or python. Then all the callers relying on this special 
behavior that is *not* suggested by the semantics of the interface would be 
broken. we decided it as better to do this fix now then later when more JS 
Componets are likely to be in use.

So how should you work around it?

I appreciate the idea of having this convenience function that allows the caller 
to not worry about the actual iid, but instead just use the limited set of 
types. But, one way or another the actual iid needs to be communicated in the 
interface in order for the mapping layer (xpconnect or some future layer) to 
know what the interface type actually is. I would suggest:

  void createType(in unsigned long type,
                  out nsIIDRef uuid, 
                  [iid_is(uuid),retval] out nsQIResult result);

In the implementation you'd have to set uuid.value = theIID for each of the 
cases to let xpconnect know what type of wrapper to build.

And, since xpconnect does not allow you to not pass required params (even if the 
caller is going to ignore them), the callers would have to pass an additional 
object to hold the 'out' param. This can be as simple as:

  var x = xmlrpc.createType(xmlrpc.STRING,{});

    or

  var ignored = {};
  var x = xmlrpc.createType(xmlrpc.STRING, ignored);
  var y = xmlrpc.createType(xmlrpc.ARRAY, ignored);
  // etc...

Sorry, that's the best solution I have.

Comment 4

[Martijn Pieters]

Thanks John,

I'll use your new method, it is not that big a change for JS users. I'll attach
a patch for this.

Comment 5

[Martijn Pieters]

Attachment: Proposed path relative to extensions/xml-rpc/

Comment 6

[John Bandhauer]

Martijn, Looks right to me. Does it work as expected?

Comment 7

[Jan Varga [:janv]]

this broke linux filepicker also

Comment 8

[Jan Varga [:janv]]

please ignore my last comment

Comment 9

[Jan Varga [:janv]]

I tried proposed patch but it doesn't work for me.

here is error message:

Call Async
JavaScript error:
 line 0: uncaught exception: [Exception... "[JavaScript Error: "uuid has no
properties" {file:
"/home/varga/mozilla/obj-optimized/dist/bin/components/nsXmlRpcClient.js" line:
416}] [nsIXmlRpcClient::createType]"  nsresult: "0x80570021
(NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)"  location: "JS frame ::
chrome://lis/content/xml-rpc.xul :: callAsync :: line 23"  data:
yes]

Comment 10

[Jan Varga [:janv]]

forgot remove bryner from CC list
because this is not also filepicker issue as I thought

Comment 11

[John Bandhauer]

Did you force the typelib to get updated by doing a make in this directory?

Comment 12

[Jan Varga [:janv]]

Thanks, createType works now.

But I think this require more work

Comment 13

[John Bandhauer]

>But I think this require more work

meaning?

Comment 14

[Jan Varga [:janv]]

Attachment: new patch

Comment 15

[Jan Varga [:janv]]

New patch includes additional small fixes to get XML-RPC working

For example, variable "internalContext" was passed to channel.asyncRead as
nsISupports and then accessed as ctxt.listener, ctxt.context, ctxt.seenStart
but this is impossible now.
Insteed I created 2 new member variables _listener and _seenStart

Hope it will work

Comment 16

[Jan Varga [:janv]]

Attachment: I'm sorry previous patch is bad, use this

Comment 17

[Martijn Pieters]

Almost there :)

The Interface definition for call needs to be updated too.

I am sorry that I my reaction speed is so low, I have little time to spare just
now. I'll try to and test this later this week.

Comment 18

[Martijn Pieters]

Sorry, I won't be able to look into this until after my holiday (the next two
weeks).

Comment 19

[Martijn Pieters]

Attachment: Proposed patch

Comment 20

[Martijn Pieters]

Attached patch fixes the problems, and unscrews RayW carpool "fix" for the
prog-ids. He didn't see I do dynamic "Contract ID" stuff with createType.

I am waiting for a r= before checkin.

Comment 21

[Martijn Pieters]

Attachment: *Correct* proposed fix

Comment 22

[Martijn Pieters]

Latest patch has the right test/xml-rpc.xul file.

Comment 23

[Jan Varga [:janv]]

works for me

Comment 24

[Martijn Pieters]

Fix checked in. Thanks Jan.

Comment 25

[Chris Petersen]

Marking verified per last comments.