Payment APIs don't reliably reject objects which aren't "JSON-serializable" |
|||
Issue descriptionAccording 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
,
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?
,
Nov 30 2016
,
Nov 30 2016
mek, haraken: any ideas?
,
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 |
|||
Comment 1 by rbyers@chromium.org
, Nov 30 2016