Bobby Holley (:bholley) Reporter
	Description • 6 years ago

There are various ergonomic issues with XPIDL that make it less-nice to use relative to WebIDL. This tempts developers to use WebIDL for internal interfaces, which has a negative impact on codesize (see [1]).

Now that extension compat is no longer a concern, we have a freer hand to modernize XPIDL in various ways. Some things, particularly complex types, are probably not tractable to implement - but others might be.

Suggestions welcome.

[1] https://groups.google.com/forum/#!topic/mozilla.dev.platform/ONHBIzzM7WU

	Matthew N. [:MattN]
	Comment 1 • 6 years ago

Dealing with nsIArray from JS is not great and unfortunately the new web payments XPIDL interfaces use many arrays. Something like bug 380839 would help. In our case we really just want to be able to serialize the nsIPaymentRequest objects to a string (via JSON.stringify) to send across the process boundary so maybe just implementing toJSON for nsIArray would be good enough for us.

	Nathan Froyd [:froydnj]
	Comment 2 • 6 years ago

(In reply to Matthew N. [:MattN] (PM if requests are blocking you) from comment #1)
> Dealing with nsIArray from JS is not great and unfortunately the new web
> payments XPIDL interfaces use many arrays. Something like bug 380839 would
> help. In our case we really just want to be able to serialize the
> nsIPaymentRequest objects to a string (via JSON.stringify) to send across
> the process boundary so maybe just implementing toJSON for nsIArray would be
> good enough for us.

Is marking parameters as [array] in XPIDL not suitable for this case?  Can you provide an example of what the interfaces involved look like for people unfamiliar with web payments?

	Bobby Holley (:bholley) Reporter
	Comment 3 • 6 years ago

To keep this metabug clean, let's move the array discussion to bug 1444524.