This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
Add a new member mAllowPaymentRequest on nsIDocument and following related
methods,
bool AllowPaymentRequest() const
void SetAllowPaymentRequest(bool aAllowPaymentRequest)
mAllowPaymentRequest is used to check if PaymentRequest is allowed to use on
the document. According to the spec
https://html.spec.whatwg.org/multipage/iframe-embed-object.html#allowed-to-use
the mAllowPaymentRequest should be true under following situations
1. The document is the top level content document.
2. The document is the same origin with its parent document and its parent
document's mAllowPaymentRequest is true.
3. The document is different origin with its parent document but its
parent node is an iframe with allowpaymentrequest flag and the parent
document's mAllowPaymentRquest is true.
This patch also include following mochitests
1. test for allowpaymentrequest flag changing. The flag change effect should
not be applied to the document immediately, it should be updated while
the browsing context is updated.
2. test for effect propagation in the nested iframe.
This was automatically generated by the script modeline.py.
MozReview-Commit-ID: BgulzkGteAL
--HG--
extra : rebase_source : a4b9d16a4c06c4e85d7d85f485221b1e4ebdfede
1. PaymentRequest::PrefEnabled() returns false under non-e10s situation.
2. Add a new mochitest test_block_none10s.html to expect to get ReferenceError
in non-e10s mode.
1. Test PaymentRequest construction with valid PMIs.
2. Test PaymentRequest construction with Invalid PMIs.
3. Test PaymentRequestUpdateEvent::updateWith with a valid PMI.
4. Test PaymentRequestUpdateEvent::updateWith with a invalid PMI.
Remove unnecessary html tags in html files.
This patch implements payment method identifier validation algorithm
according to the spec https://w3c.github.io/payment-method-id/.
The steps to validate a payment method identifier with a string pmi are
given by the following algorithm. It returns true if the pmi is valid.
1. Let url be the result of running the basic URL parser with pmi.
2. If url is failure, validate a standardized payment method identifier with
pmi and return the result.
3. Otherwise, validate a URL-based payment method identifier passing url and
return the result.
This patch changes the test_construction.html with following modification.
1. Modify the test testWithDuplicateShippingOptionsParameters to expect a
TypeError when constructing wiht duplicate shippingOption ids.
2. Add test testShippingOtpionAttribute for shippingOption setting checking
with following conditions
1. No selected shippingOption and PaymentOptions.requestShipping is false
2. One selected shippingOption and PaymentOptions.requestShipping is false
3. One selected shippingOption and PaymentOptions.requestShipping is true
4. Multiple selected shippingOptions and PaymentOptions.requestShipping is
true.
This patch implements the following changes according to the spec change.
See https://w3c.github.io/payment-request/#constructor step 8 for more
details.
1. Return TypeError during PaymentRequest construction with duplicate
shippingOption id.
2. Set PaymentRequest.shippingOption with the selected shippingOption only
if options.requestShipping is true.
1. Create a new test test_currency_amount_validation.html to test validation
with following scenarios
* test with well formed currency codes.
* test with invalid currency codes.
* test with valid lower case currency codes and check is it converted to
upper case.
* test with invalid currency codes while calling
PaymentRequestUpdateEvent::updateWith().
* test with invalid amount value with calling
PaymentRequestUpdateEvent::updateWith().
2. Move tests of test_validate_decimal_value.html to
test_currency_amount_validation.html
This patch implements currency validation algorithm according to the spec
https://w3c.github.io/payment-request/#validity-checkers.
1. amount.currencySystem must be "urn:iso:std:iso:4217".
2. amount.currency is valid with following criteria
1. The currency length must be 3.
2. The currency contains any character that must be in the range "A" to
"Z"(U+0041 to U+005A) or the range "a" to "z"(U+0061 to U+007A).
According to the spec, converting the currency to upper case and save it in
nsIPaymentRequest.
Replace it with NS_INTERFACE_MAP_BEGIN_CYCLE_COLLECTION, because it
has been the same for a while.
MozReview-Commit-ID: 5agRGFyUry1
--HG--
extra : rebase_source : 5388c56b2f6905c6ef969150f0c5b77bf247624d
1. Create a new action response status PAYMENT_NOTSUPPORTED and get rid of
unnecessary method isAccpeted() from nsIPaymentActionResponse.idl.
2. Create canMakePayment() in PaymentRequestService and run it before
launching UI. If canMakePayment() returns false, send PAYMENT_NOTSUPPORTED
back to content process.
3. If chrome process returns PAYMENT_NOTSUPPORTED when calling showPayment(),
throw NotSupportedError DOMException to merchant side.
1. Adding new checks in ConstructorChromeScript.js to checking the top level
document's principal information.
2. Adding a new test testCrossOriginTopLevelPrincipal in
test_constructor.html to testing the topLevelPrincipal attribute under
cross origin situation.
3. Removing some useless mochitest browser-chrome testcase.
Getting the top level document's principal when constructing PaymentRequest,
then sending it to chrome process and saving it in nsIPaymentRequest.
Creating a new readonly attribute nsIPrincipal topLevelPrincipal in
nsIPaymentRequest for UI to query the top level document's principal
information.
Per spec, given details and options parameters of PaymentRequest constructor,
1) if details.shippingOptions exists and IDs of all shipping options are unique,
request's shippingOption will be set to the last selected option's ID.
Otherwise, set request's shippingOption to null.
2) if options.requestShipping is ture, set request's shippingType to
options.shippingType. Otherwise, set request's shippingType to null.
Kris Maglione
Cosmin Sabou
Brindusan Cristian
Eden Chuang
Andrew McCreight
Masatoshi Kimura
Ryan VanderMeulen
Sebastian Hengst
Alphan Chen
btian
Jocelyn Liu
Bill McCloskey
Florian Quèze