PaymentApp: Implement PaymentAppProvider for LayoutTest.

PaymentApp: Implement PaymentAppProvider for LayoutTest.

This CL is implementing LayoutTestPaymentAppProvider class. The implementation
is binded with testRunner and then provides the following APIs.
 - getAllPaymentAppIDs(): Get all IDs of registered SWs for payment app.
 - invokePaymentApp(): Invoke the specified payment app.
This change is used by another CL[1] to test the behavior of invokePaymentApp().

[1] https://codereview.chromium.org/2646313002/

BUG=661608

[zino, 2017-01-23 08:00:48]

Description was changed from

==========
PaymentApp: Implement PaymentAppProvider for LayoutTest.

BUG=
==========

to

==========
PaymentApp: Implement PaymentAppProvider for LayoutTest.

This CL is implementing LayoutTestPaymentAppProvider class. The implementation
is binded with testRunner and then provides the following APIs.
 - getAllPaymentAppIDs(): Get all IDs of registered SWs for payment app.
 - invokePaymentApp(): Invoke the specified payment app.
This change is used by another CL to test the behavior of invokePaymentApp().

BUG=661608
==========

[zino, 2017-01-23 08:03:56]

Description was changed from

==========
PaymentApp: Implement PaymentAppProvider for LayoutTest.

This CL is implementing LayoutTestPaymentAppProvider class. The implementation
is binded with testRunner and then provides the following APIs.
 - getAllPaymentAppIDs(): Get all IDs of registered SWs for payment app.
 - invokePaymentApp(): Invoke the specified payment app.
This change is used by another CL to test the behavior of invokePaymentApp().

BUG=661608
==========

to

==========
PaymentApp: Implement PaymentAppProvider for LayoutTest.

This CL is implementing LayoutTestPaymentAppProvider class. The implementation
is binded with testRunner and then provides the following APIs.
 - getAllPaymentAppIDs(): Get all IDs of registered SWs for payment app.
 - invokePaymentApp(): Invoke the specified payment app.
This change is used by another CL[1] to test the behavior of invokePaymentApp().

[1] https://codereview.chromium.org/2646313002/

BUG=661608
==========

[zino, 2017-01-23 08:03:57]

jinho.bang@samsung.com changed reviewers:
+ mkwst@chromium.org, rouslan@chromium.org, tommyt@opera.com

[zino, 2017-01-23 08:04:43]

jinho.bang@samsung.com changed reviewers:
+ tsepez@chromium.org
- mkwst@chromium.org

[zino, 2017-01-23 08:06:58]

jinho.bang@samsung.com changed reviewers:
+ pfeldman@chromium.org

[zino, 2017-01-23 09:27:40]

PTAL

pfeldman@ for components and content
Tom Sepez@ for mojom
rouslan@ and tommyt@ for payments

[please use gerrit instead, 2017-01-23 13:28:07]

https://codereview.chromium.org/2647243002/diff/1/content/public/DEPS
File content/public/DEPS (right):

https://codereview.chromium.org/2647243002/diff/1/content/public/DEPS#newcode4
content/public/DEPS:4: "+components/payments/payment_app.mojom.h",
This dependency seems unnecessary.

https://codereview.chromium.org/2647243002/diff/1/content/public/browser/paym...
File content/public/browser/payment_app_provider.h (right):

https://codereview.chromium.org/2647243002/diff/1/content/public/browser/paym...
content/public/browser/payment_app_provider.h:12: #include
"components/payments/payment_app.mojom.h"
This include seems unnecessary.

https://codereview.chromium.org/2647243002/diff/1/content/shell/browser/layou...
File content/shell/browser/layout_test/layout_test_payment_app_provider_impl.cc
(right):

https://codereview.chromium.org/2647243002/diff/1/content/shell/browser/layou...
content/shell/browser/layout_test/layout_test_payment_app_provider_impl.cc:23:
std::vector<int64_t> ids;
#include <vector>

https://codereview.chromium.org/2647243002/diff/1/content/shell/browser/layou...
content/shell/browser/layout_test/layout_test_payment_app_provider_impl.cc:40:
std::move(request));
#include <utility>

[zino, 2017-01-23 17:31:08]

Thank you for review.

https://codereview.chromium.org/2647243002/diff/1/content/public/DEPS
File content/public/DEPS (right):

https://codereview.chromium.org/2647243002/diff/1/content/public/DEPS#newcode4
content/public/DEPS:4: "+components/payments/payment_app.mojom.h",
On 2017/01/23 13:28:07, rouslan wrote:
> This dependency seems unnecessary.

Done.

https://codereview.chromium.org/2647243002/diff/1/content/public/browser/paym...
File content/public/browser/payment_app_provider.h (right):

https://codereview.chromium.org/2647243002/diff/1/content/public/browser/paym...
content/public/browser/payment_app_provider.h:12: #include
"components/payments/payment_app.mojom.h"
On 2017/01/23 13:28:07, rouslan wrote:
> This include seems unnecessary.

Done.

https://codereview.chromium.org/2647243002/diff/1/content/shell/browser/layou...
File content/shell/browser/layout_test/layout_test_payment_app_provider_impl.cc
(right):

https://codereview.chromium.org/2647243002/diff/1/content/shell/browser/layou...
content/shell/browser/layout_test/layout_test_payment_app_provider_impl.cc:23:
std::vector<int64_t> ids;
On 2017/01/23 13:28:07, rouslan wrote:
> #include <vector>

Done.

https://codereview.chromium.org/2647243002/diff/1/content/shell/browser/layou...
content/shell/browser/layout_test/layout_test_payment_app_provider_impl.cc:40:
std::move(request));
On 2017/01/23 13:28:07, rouslan wrote:
> #include <utility>

Done.

[please use gerrit instead, 2017-01-23 17:48:57]

payments lgtm

[zino, 2017-01-23 17:50:19]

The CQ bit was checked by jinho.bang@samsung.com to run a CQ dry run

[commit-bot: I haz the power, 2017-01-23 17:50:43]

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-01-23 17:55:38]

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

[commit-bot: I haz the power, 2017-01-23 17:55:39]

Dry run: Try jobs failed on following builders:
  android_arm64_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...)
  android_compile_dbg on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...)
  android_cronet on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_cron...)
  android_n5x_swarming_rel on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_n5x_...)
  cast_shell_android on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/cast_shell_a...)
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_compile_dbg_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[pfeldman, 2017-01-23 18:04:28]

pfeldman@chromium.org changed reviewers:
+ esprehn@chromium.org

[pfeldman, 2017-01-23 18:05:28]

@esprehn: do you think layout test is the right approach here? there is fair
amount of harness code being introduced to support it.

[Tom Sepez, 2017-01-23 18:26:47]

lgtm

[esprehn, 2017-01-23 23:59:52]

Please don't add new testRunner features. You want to use mojo mocks in JS like
Web Share does. You shouldn't need any of this plumbing.

[please use gerrit instead, 2017-01-24 15:10:37]

Also see an example of mojo mocks in web payments:
https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/payments/...

[zino, 2017-01-24 15:58:05]

On 2017/01/24 15:10:37, rouslan wrote:
> Also see an example of mojo mocks in web payments:
>
https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/payments/...

Hi, all

Thank you for your review.

I’m not expert at the mojo JS binding. So, my understanding might be something
wrong.
I tried to hack the mojo JS binding way today and I found many examples. (e.g.
Web Share, PaymentRequest and so on)
But I’m not sure if the way is what I really want.

According the sequence diagram[1], the payment request event is initiated by
user interaction on payment request UI. (like notificationclick event in
Notification feature.)
In the flow, since the mojom interface corresponds to
ServiceWorkerEventDispatcher, we probably should write a mock implementation
using the JS binding version of the interface.

However, unfortunately, the SWED doesn’t have JS version binding because it was
defined as |cpp_only = true| in BUILD.gn[3]

Even if it is not |cpp_only = true|, can we simulate user interaction like event
sender or notification click event?
We should allow clients.openWindow() in the payment request event but I'm not
sure if the JS mock implementation can do like that because the
allowWindowInteraction()[4] will be called in cpp side code only.

[1] Payment Invocation:
https://drive.google.com/open?id=0B6zWycIQV6zHa2R2U3JfVkllc0U
[2] Payment Invocation with this patch:
https://drive.google.com/open?id=0B6zWycIQV6zHZ0FGbWNwY0c3S28
[3]
https://cs.chromium.org/chromium/src/content/common/BUILD.gn?dr=C&q=content%5...
[4]
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/servic...

[zino, 2017-01-24 16:00:48]

Could you please give me any guides? (and if my understanding is wrong, please
correct me.)

Thank you.

[esprehn, 2017-01-25 04:23:40]

esprehn@chromium.org changed reviewers:
+ rbyers@chromium.org

[esprehn, 2017-01-25 04:23:41]

rbyers@ might be able to help you there. I think you need to add a way to get a
fake user gesture in the tests. That might need to be an internal API. That
should be separate from the fake payment bits though.

[zino, 2017-01-26 03:13:48]

On 2017/01/25 04:23:41, esprehn wrote:
> rbyers@ might be able to help you there. I think you need to add a way to get
a
> fake user gesture in the tests. That might need to be an internal API. That
> should be separate from the fake payment bits though.

Hi Rick,

Do you have any idea?
Please help me :)

BTW, what's the internal API exactly?
Is it the following link?
  -
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/testing/I...
If so, I have an experience doing it when working on canvas2d.
But I'm not sure if we can simulate a event initiated from browser side.
We might simulate a event initiated from renderer side. (and write browser tests
additionally?)

[pfeldman, 2017-02-23 01:17:00]

pfeldman@chromium.org changed reviewers:
- pfeldman@chromium.org

[esprehn, 2017-04-07 10:27:25]

esprehn@chromium.org changed reviewers:
+ dglazkov@chromium.org
- esprehn@chromium.org

[Rick Byers, 2017-04-07 17:26:52]

rbyers@chromium.org changed reviewers:
+ mustaq@chromium.org

[Rick Byers, 2017-04-07 17:38:19]

On 2017/01/26 03:13:48, zino wrote:
> On 2017/01/25 04:23:41, esprehn wrote:
> > rbyers@ might be able to help you there. I think you need to add a way to
get
> a
> > fake user gesture in the tests. That might need to be an internal API. That
> > should be separate from the fake payment bits though.
> 
> Hi Rick,
> 
> Do you have any idea?
> Please help me :)
> 
> BTW, what's the internal API exactly?
> Is it the following link?
>   -
>
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/testing/I...
> If so, I have an experience doing it when working on canvas2d.
> But I'm not sure if we can simulate a event initiated from browser side.
> We might simulate a event initiated from renderer side. (and write browser
tests
> additionally?)

Sorry I missed this!  +mustaq who owns user gestures and is on the input team (I
don't do much input stuff anymore myself):

There are a variety of different ways of generating a user gesture from tests
depending on the type of test.  This style of test is new to me, so I'm not sure
offhand which approach is best.  You probably want to survey to existing
approaches and see which one fits best into this style of test.  Here's some
pointers:

LayoutTests - use EventSender to generate fake input, eg.
LayoutTests/fast/events/*
A browser test when running some JS:
RenderFrameHost::ExecuteJavascriptWithUseGestureForTests
A browser test by simulating input: eg. SimulateMouseClick in
browser_test_utils.cc
Browser tests of features which provide their own testing hook: eg.
SafeBrowsingNavigationObserverManager::RecordUserGestureForWebContents

Hope this helps!