Verify behavior of PaymentRequest constructor.

Verify behavior of PaymentRequest constructor.

This patch adds web platform tests that verify behavior of
PaymentRequest constructor. To match the spec, PaymentRequest
constructor in this patch has been changed to:
- Check for secure context before validating any parameters.
- Check the amount value first before checking the rest of the fields in
  each line item.
- Determine the selected shipping option even if requestShipping is
  false.
- Validate shipping options even if requestShipping is false.
- Validate shipping options before checking for duplicate shipping
  option IDs.
- Allow empty line item labels (but discourage via a console warning).
- Allow empty shipping option ID (but discourage via a console warning).
- Allow empty list of modifiers.

Because of changes in the WebIDL, certain conditions are not possible,
so they are ensured via DCHECK() in this patch instead of if statements
before this patch:
- Total is always present.
- Every line item has a label and amount.
- Every amount has value and currency.
- Every shipping option has an ID.
- Shipping type is always valid.

Invalid shipping type ("delivery", "shipping", or "pickup") is now
impossible because the WebIDL specifies it as an enum. Therefore,
there's no need for additional validation there.

To help developers better decipher the behavior of the API, error
messages have been improved in this patch. For example:
  "'-1/3' is not a valid amount for total."

Spec:
https://w3c.github.io/browser-payment-api/#constructor

BUG=705252
Review-Url: https://codereview.chromium.org/2851383002
Cr-Commit-Position: refs/heads/master@{#469369}
Committed: https://chromium.googlesource.com/chromium/src/+/dca98e1e37e61a0019ab182bdd7b18748575b6f1

[please use gerrit instead, 2017-05-01 22:12:31]

The CQ bit was checked by rouslan@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-01 22:13:41]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-01 23:35:04]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-01 23:35:05]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[please use gerrit instead, 2017-05-02 15:56:54]

Description was changed from

==========
Verify behavior of PaymentRequest constructor.

BUG=705252
==========

to

==========
Verify behavior of PaymentRequest constructor.

This patch adds web platform tests that verify behavior of PaymentRequest
constructor. To match the spec, PaymentRequest constructor in this patch has
been changed to:
- Check for secure context before validating any parameters.
- Check the amount value first before checking the rest of the line item.
- Determine the selected shipping option even if requestShipping is false.
- Validate shipping options even if requestShipping is false.
- Validate shipping options before checking for duplicate shipping option IDs.
- Allow empty line item labels (but discourage via a console warning).
- Allow empty shipping option ID (but discourage via a console warning).
- Allow empty list of modifiers.

Because of changes in the WebIDL, certain conditions are not possible, so they
are ensured via DCHECK() in this patch instead of if statements before this
patch:
- Total is always present.
- Every line item has a label and amount.
- Every amount has value and currency.
- Every shipping option has an ID.

Invalid shipping type ("delivery", "shipping", or "pickup") is now impossible
because the WebIDL specifies it as an enum. Therefore, there's no need for
additional validation there.

To help developers better decipher the behavior of the API, error messages have
been improved in this patch. For example:
  "'-1/3' is not a valid amount for total."

Spec:
https://w3c.github.io/browser-payment-api/#constructor

BUG=705252
==========

[please use gerrit instead, 2017-05-02 17:11:25]

Description was changed from

==========
Verify behavior of PaymentRequest constructor.

This patch adds web platform tests that verify behavior of PaymentRequest
constructor. To match the spec, PaymentRequest constructor in this patch has
been changed to:
- Check for secure context before validating any parameters.
- Check the amount value first before checking the rest of the line item.
- Determine the selected shipping option even if requestShipping is false.
- Validate shipping options even if requestShipping is false.
- Validate shipping options before checking for duplicate shipping option IDs.
- Allow empty line item labels (but discourage via a console warning).
- Allow empty shipping option ID (but discourage via a console warning).
- Allow empty list of modifiers.

Because of changes in the WebIDL, certain conditions are not possible, so they
are ensured via DCHECK() in this patch instead of if statements before this
patch:
- Total is always present.
- Every line item has a label and amount.
- Every amount has value and currency.
- Every shipping option has an ID.

Invalid shipping type ("delivery", "shipping", or "pickup") is now impossible
because the WebIDL specifies it as an enum. Therefore, there's no need for
additional validation there.

To help developers better decipher the behavior of the API, error messages have
been improved in this patch. For example:
  "'-1/3' is not a valid amount for total."

Spec:
https://w3c.github.io/browser-payment-api/#constructor

BUG=705252
==========

to

==========
Verify behavior of PaymentRequest constructor.

This patch adds web platform tests that verify behavior of
PaymentRequest constructor. To match the spec, PaymentRequest
constructor in this patch has been changed to:
- Check for secure context before validating any parameters.
- Check the amount value first before checking the rest of the line
  item.
- Determine the selected shipping option even if requestShipping is
  false.
- Validate shipping options even if requestShipping is false.
- Validate shipping options before checking for duplicate shipping
  option IDs.
- Allow empty line item labels (but discourage via a console warning).
- Allow empty shipping option ID (but discourage via a console warning).
- Allow empty list of modifiers.

Because of changes in the WebIDL, certain conditions are not possible,
so they are ensured via DCHECK() in this patch instead of if statements
before this patch:
- Total is always present.
- Every line item has a label and amount.
- Every amount has value and currency.
- Every shipping option has an ID.

Invalid shipping type ("delivery", "shipping", or "pickup") is now
impossible because the WebIDL specifies it as an enum. Therefore,
there's no need for additional validation there.

To help developers better decipher the behavior of the API, error
messages have been improved in this patch. For example:
  "'-1/3' is not a valid amount for total."

Spec:
https://w3c.github.io/browser-payment-api/#constructor

BUG=705252
==========

[please use gerrit instead, 2017-05-02 18:32:22]

Description was changed from

==========
Verify behavior of PaymentRequest constructor.

This patch adds web platform tests that verify behavior of
PaymentRequest constructor. To match the spec, PaymentRequest
constructor in this patch has been changed to:
- Check for secure context before validating any parameters.
- Check the amount value first before checking the rest of the line
  item.
- Determine the selected shipping option even if requestShipping is
  false.
- Validate shipping options even if requestShipping is false.
- Validate shipping options before checking for duplicate shipping
  option IDs.
- Allow empty line item labels (but discourage via a console warning).
- Allow empty shipping option ID (but discourage via a console warning).
- Allow empty list of modifiers.

Because of changes in the WebIDL, certain conditions are not possible,
so they are ensured via DCHECK() in this patch instead of if statements
before this patch:
- Total is always present.
- Every line item has a label and amount.
- Every amount has value and currency.
- Every shipping option has an ID.

Invalid shipping type ("delivery", "shipping", or "pickup") is now
impossible because the WebIDL specifies it as an enum. Therefore,
there's no need for additional validation there.

To help developers better decipher the behavior of the API, error
messages have been improved in this patch. For example:
  "'-1/3' is not a valid amount for total."

Spec:
https://w3c.github.io/browser-payment-api/#constructor

BUG=705252
==========

to

==========
Verify behavior of PaymentRequest constructor.

This patch adds web platform tests that verify behavior of
PaymentRequest constructor. To match the spec, PaymentRequest
constructor in this patch has been changed to:
- Check for secure context before validating any parameters.
- Check the amount value first before checking the rest of the line
  item.
- Determine the selected shipping option even if requestShipping is
  false.
- Validate shipping options even if requestShipping is false.
- Validate shipping options before checking for duplicate shipping
  option IDs.
- Allow empty line item labels (but discourage via a console warning).
- Allow empty shipping option ID (but discourage via a console warning).
- Allow empty list of modifiers.

Because of changes in the WebIDL, certain conditions are not possible,
so they are ensured via DCHECK() in this patch instead of if statements
before this patch:
- Total is always present.
- Every line item has a label and amount.
- Every amount has value and currency.
- Every shipping option has an ID.
- Shipping type is always valid.

Invalid shipping type ("delivery", "shipping", or "pickup") is now
impossible because the WebIDL specifies it as an enum. Therefore,
there's no need for additional validation there.

To help developers better decipher the behavior of the API, error
messages have been improved in this patch. For example:
  "'-1/3' is not a valid amount for total."

Spec:
https://w3c.github.io/browser-payment-api/#constructor

BUG=705252
==========

[please use gerrit instead, 2017-05-02 18:35:38]

Description was changed from

==========
Verify behavior of PaymentRequest constructor.

This patch adds web platform tests that verify behavior of
PaymentRequest constructor. To match the spec, PaymentRequest
constructor in this patch has been changed to:
- Check for secure context before validating any parameters.
- Check the amount value first before checking the rest of the line
  item.
- Determine the selected shipping option even if requestShipping is
  false.
- Validate shipping options even if requestShipping is false.
- Validate shipping options before checking for duplicate shipping
  option IDs.
- Allow empty line item labels (but discourage via a console warning).
- Allow empty shipping option ID (but discourage via a console warning).
- Allow empty list of modifiers.

Because of changes in the WebIDL, certain conditions are not possible,
so they are ensured via DCHECK() in this patch instead of if statements
before this patch:
- Total is always present.
- Every line item has a label and amount.
- Every amount has value and currency.
- Every shipping option has an ID.
- Shipping type is always valid.

Invalid shipping type ("delivery", "shipping", or "pickup") is now
impossible because the WebIDL specifies it as an enum. Therefore,
there's no need for additional validation there.

To help developers better decipher the behavior of the API, error
messages have been improved in this patch. For example:
  "'-1/3' is not a valid amount for total."

Spec:
https://w3c.github.io/browser-payment-api/#constructor

BUG=705252
==========

to

==========
Verify behavior of PaymentRequest constructor.

This patch adds web platform tests that verify behavior of
PaymentRequest constructor. To match the spec, PaymentRequest
constructor in this patch has been changed to:
- Check for secure context before validating any parameters.
- Check the amount value first before checking the rest of the fields in
  each line item.
- Determine the selected shipping option even if requestShipping is
  false.
- Validate shipping options even if requestShipping is false.
- Validate shipping options before checking for duplicate shipping
  option IDs.
- Allow empty line item labels (but discourage via a console warning).
- Allow empty shipping option ID (but discourage via a console warning).
- Allow empty list of modifiers.

Because of changes in the WebIDL, certain conditions are not possible,
so they are ensured via DCHECK() in this patch instead of if statements
before this patch:
- Total is always present.
- Every line item has a label and amount.
- Every amount has value and currency.
- Every shipping option has an ID.
- Shipping type is always valid.

Invalid shipping type ("delivery", "shipping", or "pickup") is now
impossible because the WebIDL specifies it as an enum. Therefore,
there's no need for additional validation there.

To help developers better decipher the behavior of the API, error
messages have been improved in this patch. For example:
  "'-1/3' is not a valid amount for total."

Spec:
https://w3c.github.io/browser-payment-api/#constructor

BUG=705252
==========

[please use gerrit instead, 2017-05-02 20:33:53]

The CQ bit was checked by rouslan@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-02 20:34:09]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[please use gerrit instead, 2017-05-02 20:42:30]

Patchset #1 (id:1) has been deleted

[commit-bot: I haz the power, 2017-05-02 23:07:21]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-02 23:07:22]

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[please use gerrit instead, 2017-05-03 14:15:03]

rouslan@chromium.org changed reviewers:
+ mek@chromium.org

[please use gerrit instead, 2017-05-03 14:15:03]

Marijn, ptal. Am I taking the right approach here? I looked at one section of
the spec, wrote web platform tests for it, and then updated the code to match
the spec better.

[Marijn Kruisselbrink, 2017-05-03 18:26:51]

the approach looks reasonable to me. I wonder if some of the tests would be
slightly more readable is some of the long lines are broken up more, but
ultimately layout and wpt tests don't really have a style guide (other than some
directories with self-enforces style rules, and
https://chromium.googlesource.com/chromium/src/+/master/docs/testing/layout_t...),
so that's totally up to you.

https://codereview.chromium.org/2851383002/diff/20001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/external/wpt/payment-request/payment-request-constructor.https.html
(right):

https://codereview.chromium.org/2851383002/diff/20001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/payment-request/payment-request-constructor.https.html:5:
<script src="../resources/testharness.js"></script>
This should just be /resources/testharness.js

https://codereview.chromium.org/2851383002/diff/20001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/payment-request/payment-request-constructor.https.html:6:
<script src="../../../resources/testharnessreport.js"></script>
same here, /resources/testharnessreport.js

https://codereview.chromium.org/2851383002/diff/20001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/payment-request/payment-request-constructor.https.html:11:
});
Could you give every test() a name? The auto-generated test names ("Test for
PaymentRequest Constructor 13" etc) make test expectations less stable, as
re-ordering and adding/removing new substests will change the names for tests.

Personally I'd even say that having a name for a test is more useful than having
a description for an assertion, especially if the whole test is a single
assertion anyway (that's also what the docs at
https://chromium.googlesource.com/chromium/src/+/master/docs/testing/writing_...
seem to say "Test cases with a single assertion should omit the assertion's
description when it is sufficiently clear.")

https://codereview.chromium.org/2851383002/diff/20001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/payment-request/payment-request-constructor.https.html:28:
for (var i in invalid_monetary_amounts) {
for...in should generally never be used for arrays in javascript, probably you
meant for (const amount of invalid_monetary_amounts) {} or something similar
here instead?

[please use gerrit instead, 2017-05-03 19:28:36]

The CQ bit was checked by rouslan@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-03 19:29:15]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[please use gerrit instead, 2017-05-03 19:30:24]

Ptal patch 2.

https://codereview.chromium.org/2851383002/diff/20001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/external/wpt/payment-request/payment-request-constructor.https.html
(right):

https://codereview.chromium.org/2851383002/diff/20001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/payment-request/payment-request-constructor.https.html:5:
<script src="../resources/testharness.js"></script>
On 2017/05/03 18:26:51, Marijn Kruisselbrink wrote:
> This should just be /resources/testharness.js

Done.

https://codereview.chromium.org/2851383002/diff/20001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/payment-request/payment-request-constructor.https.html:6:
<script src="../../../resources/testharnessreport.js"></script>
On 2017/05/03 18:26:51, Marijn Kruisselbrink wrote:
> same here, /resources/testharnessreport.js

Done.

https://codereview.chromium.org/2851383002/diff/20001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/payment-request/payment-request-constructor.https.html:11:
});
On 2017/05/03 18:26:51, Marijn Kruisselbrink wrote:
> Could you give every test() a name? The auto-generated test names ("Test for
> PaymentRequest Constructor 13" etc) make test expectations less stable, as
> re-ordering and adding/removing new substests will change the names for tests.
> 
> Personally I'd even say that having a name for a test is more useful than
having
> a description for an assertion, especially if the whole test is a single
> assertion anyway (that's also what the docs at
>
https://chromium.googlesource.com/chromium/src/+/master/docs/testing/writing_...
> seem to say "Test cases with a single assertion should omit the assertion's
> description when it is sufficiently clear.")

Done.

https://codereview.chromium.org/2851383002/diff/20001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/payment-request/payment-request-constructor.https.html:28:
for (var i in invalid_monetary_amounts) {
On 2017/05/03 18:26:51, Marijn Kruisselbrink wrote:
> for...in should generally never be used for arrays in javascript, probably you
> meant for (const amount of invalid_monetary_amounts) {} or something similar
> here instead?

Done.

[commit-bot: I haz the power, 2017-05-03 21:12:19]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-03 21:12:20]

Dry run: This issue passed the CQ dry run.

[Marijn Kruisselbrink, 2017-05-03 23:11:00]

lgtm

https://codereview.chromium.org/2851383002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/payments/PaymentRequest.cpp (right):

https://codereview.chromium.org/2851383002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/payments/PaymentRequest.cpp:156:
ConsoleMessage::Create(kJSMessageSource, kErrorMessageLevel,
nit: would it make sense for this message to explain why this is discouraged?

https://codereview.chromium.org/2851383002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/payments/PaymentRequest.cpp:205: "Empty
shipping option ID is discouraged"));
nit: same here, why is an empty ID a problem? If I read the spec right, even
though empty IDs are allowed, they still have to be unique, so only one option
can have an empty ID.

[haraken, 2017-05-04 09:47:51]

haraken@chromium.org changed reviewers:
+ haraken@chromium.org

[haraken, 2017-05-04 09:47:52]

Just a drive-by :)

https://codereview.chromium.org/2851383002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/payments/PaymentRequest.cpp (right):

https://codereview.chromium.org/2851383002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/payments/PaymentRequest.cpp:411: if
(!input.V8Value()->IsObject() || input.V8Value()->IsArray() ||

Is it worth checking IsArray? To check whether the object is serializable, I
guess we can just call v8::JSON::Stringify and see the returned value.

[please use gerrit instead, 2017-05-04 15:10:54]

The CQ bit was checked by rouslan@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-04 15:11:14]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[please use gerrit instead, 2017-05-04 15:17:15]

https://codereview.chromium.org/2851383002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/payments/PaymentRequest.cpp (right):

https://codereview.chromium.org/2851383002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/payments/PaymentRequest.cpp:156:
ConsoleMessage::Create(kJSMessageSource, kErrorMessageLevel,
On 2017/05/03 23:10:59, Marijn Kruisselbrink wrote:
> nit: would it make sense for this message to explain why this is discouraged?

Done.

https://codereview.chromium.org/2851383002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/payments/PaymentRequest.cpp:205: "Empty
shipping option ID is discouraged"));
On 2017/05/03 23:10:59, Marijn Kruisselbrink wrote:
> nit: same here, why is an empty ID a problem? If I read the spec right, even
> though empty IDs are allowed, they still have to be unique, so only one option
> can have an empty ID.

Done.

https://codereview.chromium.org/2851383002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/payments/PaymentRequest.cpp:411: if
(!input.V8Value()->IsObject() || input.V8Value()->IsArray() ||
On 2017/05/04 09:47:51, haraken wrote:
> 
> Is it worth checking IsArray? To check whether the object is serializable, I
> guess we can just call v8::JSON::Stringify and see the returned value.
> 
> 

Good point, the spec does prohibit arrays. Added a layout test for that as well.

[please use gerrit instead, 2017-05-04 15:17:42]

On 2017/05/04 15:17:15, ಠ_ಠ wrote:
> Good point, the spec does prohibit arrays. Added a layout test for that as
well.

*does not prohibit*

[haraken, 2017-05-04 15:24:35]

LGTM

[please use gerrit instead, 2017-05-04 16:14:46]

The CQ bit was unchecked by rouslan@chromium.org

[please use gerrit instead, 2017-05-04 16:14:54]

The CQ bit was checked by rouslan@chromium.org

[please use gerrit instead, 2017-05-04 16:14:56]

The patchset sent to the CQ was uploaded after l-g-t-m from mek@chromium.org
Link to the patchset: https://codereview.chromium.org/2851383002/#ps60001
(title: "Comments")

[commit-bot: I haz the power, 2017-05-04 16:15:11]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-04 17:17:27]

CQ is committing da patch.

Bot data: {"patchset_id": 60001, "attempt_start_ts": 1493914494647510,
"parent_rev": "31438b99f6f743976583ce02a4a362c26b9e144e", "commit_rev":
"dca98e1e37e61a0019ab182bdd7b18748575b6f1"}

[commit-bot: I haz the power, 2017-05-04 17:17:59]

Description was changed from

==========
Verify behavior of PaymentRequest constructor.

This patch adds web platform tests that verify behavior of
PaymentRequest constructor. To match the spec, PaymentRequest
constructor in this patch has been changed to:
- Check for secure context before validating any parameters.
- Check the amount value first before checking the rest of the fields in
  each line item.
- Determine the selected shipping option even if requestShipping is
  false.
- Validate shipping options even if requestShipping is false.
- Validate shipping options before checking for duplicate shipping
  option IDs.
- Allow empty line item labels (but discourage via a console warning).
- Allow empty shipping option ID (but discourage via a console warning).
- Allow empty list of modifiers.

Because of changes in the WebIDL, certain conditions are not possible,
so they are ensured via DCHECK() in this patch instead of if statements
before this patch:
- Total is always present.
- Every line item has a label and amount.
- Every amount has value and currency.
- Every shipping option has an ID.
- Shipping type is always valid.

Invalid shipping type ("delivery", "shipping", or "pickup") is now
impossible because the WebIDL specifies it as an enum. Therefore,
there's no need for additional validation there.

To help developers better decipher the behavior of the API, error
messages have been improved in this patch. For example:
  "'-1/3' is not a valid amount for total."

Spec:
https://w3c.github.io/browser-payment-api/#constructor

BUG=705252
==========

to

==========
Verify behavior of PaymentRequest constructor.

This patch adds web platform tests that verify behavior of
PaymentRequest constructor. To match the spec, PaymentRequest
constructor in this patch has been changed to:
- Check for secure context before validating any parameters.
- Check the amount value first before checking the rest of the fields in
  each line item.
- Determine the selected shipping option even if requestShipping is
  false.
- Validate shipping options even if requestShipping is false.
- Validate shipping options before checking for duplicate shipping
  option IDs.
- Allow empty line item labels (but discourage via a console warning).
- Allow empty shipping option ID (but discourage via a console warning).
- Allow empty list of modifiers.

Because of changes in the WebIDL, certain conditions are not possible,
so they are ensured via DCHECK() in this patch instead of if statements
before this patch:
- Total is always present.
- Every line item has a label and amount.
- Every amount has value and currency.
- Every shipping option has an ID.
- Shipping type is always valid.

Invalid shipping type ("delivery", "shipping", or "pickup") is now
impossible because the WebIDL specifies it as an enum. Therefore,
there's no need for additional validation there.

To help developers better decipher the behavior of the API, error
messages have been improved in this patch. For example:
  "'-1/3' is not a valid amount for total."

Spec:
https://w3c.github.io/browser-payment-api/#constructor

BUG=705252

Review-Url: https://codereview.chromium.org/2851383002
Cr-Commit-Position: refs/heads/master@{#469369}
Committed:
https://chromium.googlesource.com/chromium/src/+/dca98e1e37e61a0019ab182bdd7b...
==========

[commit-bot: I haz the power, 2017-05-04 17:18:00]

Committed patchset #3 (id:60001) as
https://chromium.googlesource.com/chromium/src/+/dca98e1e37e61a0019ab182bdd7b...