Zach, can you run this by the appropriate reviewers?

Durga, could you help Zach with this task, please? Ping me if you need the background.

 Issue 802142  has been merged into this issue.

A website should be able to query whether the user has a Google Pay wallet or cards in autofill database in two separate canMakePayment() calls, but should not be able to iterate all payment instruments within these wallets.

Intent to implement: https://groups.google.com/a/chromium.org/d/msg/blink-dev/pmq3VLPiw5E/3BUpoVm0CQAJ

Type-Launch-OWP is deprecated.

Filing issue 900792 to track the privacy review for this launch.

Please fill in Test survey (https://goto.google.com/chrome-test-questions).

please flip legal back to "review requested" when the privacy review is complete.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ded84011c8ebd8c6e1525c849289f7102e81f46b

commit ded84011c8ebd8c6e1525c849289f7102e81f46b
Author: Rouslan Solomakhin <rouslan@chromium.org>
Date: Fri Nov 02 13:27:10 2018

[Payment Request] Method based quota

Before this patch, a website could query PaymentRequest.canMakePayment()
with a single set of methods identifiers and parameters per user per 30
minutes. This prevented placing wallet-specific buttons on the page that
would be backed by one instance of PaymentRequest each, because only the
first of several PaymentRequest.canMakePayment() calls would succeed
before the quota limit was hit.

This patch adds per-method quota, which allows queries for different
payment method identifiers, as long as the method-specific parameters
remain unchanged for 30 minutes. The quota code on Android has been
refactored to use the common C++ code that is already used on desktop
and iOS. The new behavior is behind the
chrome://flags/#per-method-can-make-payment-quota flag, which is
disabled by default.

After this patch, if chrome://flags/#per-method-can-make-payment-quota
is enabled, a website can query PaymentRequest.canMakePayment() for
each payment method individually, as long as method-specific parameters
are unchanged. This allows placing wallet-specific buttons on the page
with each button backed by a separate instance of PaymentRequest.
Although the website can find out which wallets the user has, the quota
still hides the  individual instruments within a wallet.

Change-Id: I5056984ef3ada913679d3e0d07b10394592b557f
Bug: 871791
Reviewed-on: https://chromium-review.googlesource.com/c/1293569
Reviewed-by: Brian White <bcwhite@chromium.org>
Reviewed-by: Ganggui Tang <gogerald@chromium.org>
Commit-Queue: Rouslan Solomakhin <rouslan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#604903}
[add] https://crrev.com/ded84011c8ebd8c6e1525c849289f7102e81f46b/chrome/android/java/src/org/chromium/chrome/browser/payments/CanMakePaymentQuery.java
[modify] https://crrev.com/ded84011c8ebd8c6e1525c849289f7102e81f46b/chrome/android/java/src/org/chromium/chrome/browser/payments/PaymentRequestImpl.java
[modify] https://crrev.com/ded84011c8ebd8c6e1525c849289f7102e81f46b/chrome/android/java_sources.gni
[modify] https://crrev.com/ded84011c8ebd8c6e1525c849289f7102e81f46b/chrome/android/javatests/src/org/chromium/chrome/browser/payments/PaymentRequestPaymentAppCanMakePaymentQueryTest.java
[modify] https://crrev.com/ded84011c8ebd8c6e1525c849289f7102e81f46b/chrome/browser/BUILD.gn
[modify] https://crrev.com/ded84011c8ebd8c6e1525c849289f7102e81f46b/chrome/browser/about_flags.cc
[modify] https://crrev.com/ded84011c8ebd8c6e1525c849289f7102e81f46b/chrome/browser/flag_descriptions.cc
[modify] https://crrev.com/ded84011c8ebd8c6e1525c849289f7102e81f46b/chrome/browser/flag_descriptions.h
[add] https://crrev.com/ded84011c8ebd8c6e1525c849289f7102e81f46b/chrome/browser/payments/android/can_make_payment_query_android.cc
[modify] https://crrev.com/ded84011c8ebd8c6e1525c849289f7102e81f46b/chrome/browser/ui/views/payments/payment_request_can_make_payment_browsertest.cc
[modify] https://crrev.com/ded84011c8ebd8c6e1525c849289f7102e81f46b/components/payments/core/can_make_payment_query.cc
[modify] https://crrev.com/ded84011c8ebd8c6e1525c849289f7102e81f46b/components/payments/core/can_make_payment_query.h
[modify] https://crrev.com/ded84011c8ebd8c6e1525c849289f7102e81f46b/components/payments/core/can_make_payment_query_unittest.cc
[modify] https://crrev.com/ded84011c8ebd8c6e1525c849289f7102e81f46b/components/payments/core/features.cc
[modify] https://crrev.com/ded84011c8ebd8c6e1525c849289f7102e81f46b/components/payments/core/features.h
[modify] https://crrev.com/ded84011c8ebd8c6e1525c849289f7102e81f46b/components/test/data/payments/can_make_payment_query_bobpay.js
[modify] https://crrev.com/ded84011c8ebd8c6e1525c849289f7102e81f46b/testing/variations/fieldtrial_testing_config.json
[modify] https://crrev.com/ded84011c8ebd8c6e1525c849289f7102e81f46b/tools/metrics/histograms/enums.xml

> 1. Does the feature need manual testing?

No.

> 2. Feature implementation status 
>   a. What is currently working and not working/known issues? 

Feature is completely implemented.

>   b. Is all the code landed in canary and ready for testing?

Yes.

> 3. Link to Design Doc:

The feature is described in a couple of places, but is too trivial for a standalone design doc:

Intent to implement:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/pmq3VLPiw5E/3BUpoVm0CQAJ

Chrome feature status:
https://www.chromestatus.com/feature/6014793655779328

(The feature adds 237 LOC to Chrome total, but only 68 LOC of that is new logic.)

> 4. Link to demos (if any): 

A simple demo:
1) Enable chrome://flags/#per-method-can-make-payment-quota and restart the browser.
2) Open https://rsolomakhin.github.io/pr/
3) Observe the green text "Can make payment" or "Cannot make payment".
4) Open https://rsolomakhin.github.io/pr/bob/
5) Observe the green text "Can make payment" or "Cannot make payment". (If the flag in step 1 was not enabled, you would instead see red text "NotAllowedError".)
6) Open https://rsolomakhin.github.io/pr/type/credit/
7) Observe the red text "NotAllowedError". (This is unchanged from before the feature was implemented.)

> 5. Link to Test Plan:

Automated testing is sufficient.

> 6. Are there flags or setup are needed to enable this feature? Is it on by default?

Off by default, except in developer builds. Flag:
chrome://flags/#per-method-can-make-payment-quota

> 7. Are there any special points of interest from a testing perspective?

No.

> 8 Is the feature the same across all platforms?

Yes.

>   a. Is the user flow same across all platforms? (Answer if applicable to both Desktop and Mobile)

Yes.

>   b. Is the code flow/logic different on any specific platforms (i.e code branching or logic duplication)

No.
Desktop, iOS, and Android all point to the same code and have the same logic.

> 9. What's automated (Unit tests, Integration tests, API tests, Browser tests, E2E tests)? Please provide links to automated tests.

Unit tests, integration tests, and browser tests are automated.
https://cs.chromium.org/chromium/src/chrome/android/javatests/src/org/chromium/chrome/browser/payments/PaymentRequestPaymentAppCanMakePaymentQueryTest.java
https://cs.chromium.org/chromium/src/chrome/browser/ui/views/payments/payment_request_can_make_payment_browsertest.cc
https://cs.chromium.org/chromium/src/components/payments/core/can_make_payment_query_unittest.cc

> 10. What’s not automated that needs manual testing?

Nothing.

> 11. What is the crbug label(s) and/or component(s) for the feature?

UI>Browser>Payments

> 12. Are there any other team members or mailing lists that should be notified if issues are found?

paymentrequest@google.com

> 13. Rollout plan: 
>   a. Will this roll out on by default for 100% or will it be rolled out incrementally behind a finch experiment? Is it behind a finch flag even if it’s on by default?

The plan is to rollout “on” by default for 100% using a finch flag after a launch approval.

>   b. Is there a mechanism to turn off the feature if it breaks product functionality or performance?

Turn off feature “WebPaymentsPerMethodCanMakePaymentQuota” using fnch.

>   c. How will you monitor the stability of the feature and/or experiment groups? 

We are following crash metrics for any code in Chrome that includes the keyword “payment” in file path.

> 14. Confirm that there is no negative meaningful performance impact and how that was checked:

There’s no negative meaningful performance impact as determined by a manual review and check.

Test=NA for desktop. 

Mobile team can flip the test bit after reviewing the launch bug.

 rouslan@ Is this feature required manual testing for Android?

No.

Thanks Rouslan! 

qq - I see automation exists for Desktop and Android, is any coverage possible and/or needed for iOS?

Lindsay: iOS is covered by unit tests, which are cross-platform.

+Moe: Do we have integration tests for canMakePayment() on iOS?

We have ios/chrome/browser/ui/payments/payment_request_can_make_payment_egtest.mm

Awesome, thanks for the pointer!

Marking this as Test-NA since automation is in place and so specific manual coverage is needed in addition regression test as usual. Thanks!

The negative unit test cases in can_make_payment_query_unittest.cc seem to verify that the security guarantee is working. 

Automatic generating of FLT Launch data.

Updating this issue's FLT-Conversion label.
Please do not modify this value.

Bulk updating old OWP-Launch bugs to once again be public. OWP-Launch (previously used as public/transparent blink launch process) was not supposed to have been remapped to Type=Launch.

Preparing this issue to be converted back into the old format.

Will change Type back to 'Feature' after.

Post holiday ping. Can we can a Launch-Privacy review here? We're ready to launch and users have been asking for this feature.

LGTM for an origin trial; LGTM for a full rollout once we have a way to deal with potential abuse.