1027734 - Convert mozPay to WebIDL

Status: RESOLVED FIXED

(Core :: DOM: Device Interfaces, defect)

Description

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

We should move mozPay to use WebIDL rather than the Javascript-navigator-property stuff and JS implemented class info.

ferjm, could you take this?

Comment 1

[(no longer active)]

Note that because navigator.mozPay is a function, we either need to find a solution for bug 986455 or implement at least part of it in C++.

Comment 2

[Fernando Jiménez Moreno [:ferjm]]

I'm afraid that I won't be able to take this at least until the 2.0 peak is gone. Leaving the ni? anyway so I don't forget about this.

Comment 3

[Bobby Holley (:bholley)]

How about now?

The current mechanism that this API is using is going away soonish.

Comment 4

[Fernando Jiménez Moreno [:ferjm]]

Attachment: Untested WIP

Comment 5

[Peter Van der Beken [:peterv]]

Attachment: v1

Need to figure out why the tests don't work yet.

Comment 6

[Peter Van der Beken [:peterv]]

Attachment: v2

Comment 7

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8713728 [details] [diff] [review]
v2

>+++ b/dom/webidl/Navigator.webidl

>+  // The 'jwts' parameter can be either a single DOMString or an array of
>+  // DOMStrings.

Sure would be nice to make it a (DOMString or sequence<DOMString>) or something, but then talking to the back end would be a tad more annoying.  On the other hand, it wouldn't involve chrome poking at content arrays...

r=me as-is, but this might be worth a followup.

Comment 8

[Peter Van der Beken [:peterv]]

(In reply to Boris Zbarsky [:bz] from comment #7)
> Sure would be nice to make it a (DOMString or sequence<DOMString>) or
> something, but then talking to the back end would be a tad more annoying. 
> On the other hand, it wouldn't involve chrome poking at content arrays...

I thought about that, but would that do what we want if someone passes in a string? I thought it would end up being converted to a sequence because String has an @@iterator and conversion to sequence is an earlier step than conversion to string in http://heycam.github.io/webidl/#es-union.

Comment 9

[Peter Van der Beken [:peterv]]

I guess I should have said "... passes in a String object". Maybe we don't care about that case.

Comment 10

[Boris Zbarsky [:bzbarsky]]

I suspect we don't care about the String object case.  But as I said, this should be a followup if we do it at all.  We should certainly not hold up landing this over the DOMString union issue.

Comment 11

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/1f5aaf208c71

Comment 12

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/1f5aaf208c71