New issue
Advanced search Search tips

Issue 669959 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug


Participants' hotlists:
Payment-Interop


Sign in to add a comment

Payment APIs don't reliably reject objects which aren't "JSON-serializable"

Project Member Reported by rbyers@chromium.org, Nov 30 2016

Issue description

According to https://w3c.github.io/browser-payment-api/#dfn-json-serializable-object:

"The term JSON-serializable object used in this specification means an object that can be serialized to a string using JSON.stringify and later deserialized back to an object using JSON.parse with no loss of data."

But it looks like we only actually validate that JSON.stringify succeeds.  So, for example:

new PaymentRequest([{supportedMethods: ["visa", "mastercard"], data:data}], {total: { label:"tot", amount: {currency: "USD", value:"60.00"}}})

Succeeds in the following cases where the spec implies it should throw:
data = {a:undefined};
data = {a:navigator};

Spec debate: https://github.com/w3c/browser-payment-api/issues/307
 

Comment 1 by rbyers@chromium.org, Nov 30 2016

Labels: Hotlist-Interop

Comment 2 by rbyers@chromium.org, Nov 30 2016

Another example that will be more difficult to test for in the general case: data = [undefined]  (serializes to "[null]").

Do we need to call JSON.parse and compare the resulting object graph with the original property by property in order to be spec compliant?
Owner: rouslan@chromium.org
Status: Assigned (was: Untriaged)
Cc: haraken@chromium.org mek@chromium.org
mek, haraken: any ideas?

Comment 5 by bzbar...@mit.edu, Nov 30 2016

I strongly urge anyone working on this to read the thread at https://lists.w3.org/Archives/Public/public-script-coord/2016OctDec/0071.html

I also strongly urge changing the spec so that these attempts to solve the halting problem don't need to be done.  ;)

Sign in to add a comment