Implement PaymentRequestUpdateEvent

Implement PaymentRequestUpdateEvent

When onShippingAddressChange or onShippingOptionChange event fires, the
event type should be PaymentRequestUpdateEvent with an updateWith()
method.

 - The updateWith() method lets the merchant update the shipping options
   and the total price.

 - The updateWith() method cannot be called twice for the same event.

 - The updateWith() method can be called only when the event is being
   dispatched.

 - Dispatching a PaymentRequestUpdateEvent created in JavaScript is a
   no-op.

https://w3c.github.io/browser-payment-api/specs/paymentrequest.html#idl-def-paymentrequestupdateevent

BUG=607705
Committed: https://crrev.com/84234b56d641a989f709976793cff331b5488684
Cr-Commit-Position: refs/heads/master@{#392002}

[please use gerrit instead, 2016-04-29 04:27:33]

Patchset #1 (id:1) has been deleted

[please use gerrit instead, 2016-04-29 19:29:00]

Description was changed from

==========
Implement PaymentRequestUpdateEvent

When PaymentRequest.onShippingAddressChange or
PaymentRequest.onShippingOptionChange event fires, the event type should
be PaymentRequestUpdateEvent with a method updateWith(). This method
should allow the merchant to update the shipping options and the total
price.

https://w3c.github.io/browser-payment-api/specs/paymentrequest.html#idl-def-p...

BUG=607705
==========

to

==========
Implement PaymentRequestUpdateEvent

When PaymentRequest.onShippingAddressChange or
PaymentRequest.onShippingOptionChange event fires, the event type should
be PaymentRequestUpdateEvent with a method updateWith(). This method
should allow the merchant to update the shipping options and the total
price.
https://w3c.github.io/browser-payment-api/specs/paymentrequest.html#idl-def-p...

If the merchant provides NULL shipping options, the merchant needs a
shipping address to calculate shipping costs. The UI requires the user
to make an address selection and passes that information to the
merchant.

If the merchant provides non-NULL shipping options, the merchant does
not need shipping address to calculate shipping costs. The UI selects
the default shipping address, but does not send it to the merchant until
the user clicks "Pay".

BUG=607705
==========

[please use gerrit instead, 2016-04-29 19:29:47]

Patchset #1 (id:20001) has been deleted

[please use gerrit instead, 2016-04-29 20:49:41]

Patchset #1 (id:40001) has been deleted

[please use gerrit instead, 2016-04-29 21:53:18]

Patchset #1 (id:60001) has been deleted

[please use gerrit instead, 2016-04-30 00:10:11]

Patchset #1 (id:80001) has been deleted

[please use gerrit instead, 2016-04-30 00:10:23]

Patchset #1 (id:100001) has been deleted

[please use gerrit instead, 2016-05-01 20:52:19]

Patchset #1 (id:120001) has been deleted

[please use gerrit instead, 2016-05-01 20:52:29]

Patchset #1 (id:140001) has been deleted

[please use gerrit instead, 2016-05-01 20:52:40]

Patchset #1 (id:160001) has been deleted

[please use gerrit instead, 2016-05-01 20:52:49]

Patchset #1 (id:180001) has been deleted

[please use gerrit instead, 2016-05-01 20:53:04]

Patchset #1 (id:200001) has been deleted

[please use gerrit instead, 2016-05-01 20:53:14]

Patchset #1 (id:220001) has been deleted

[please use gerrit instead, 2016-05-01 20:53:30]

Patchset #1 (id:240001) has been deleted

[please use gerrit instead, 2016-05-01 20:53:39]

Patchset #1 (id:260001) has been deleted

[please use gerrit instead, 2016-05-01 20:53:50]

Patchset #1 (id:280001) has been deleted

[please use gerrit instead, 2016-05-02 16:16:48]

Description was changed from

==========
Implement PaymentRequestUpdateEvent

When PaymentRequest.onShippingAddressChange or
PaymentRequest.onShippingOptionChange event fires, the event type should
be PaymentRequestUpdateEvent with a method updateWith(). This method
should allow the merchant to update the shipping options and the total
price.
https://w3c.github.io/browser-payment-api/specs/paymentrequest.html#idl-def-p...

If the merchant provides NULL shipping options, the merchant needs a
shipping address to calculate shipping costs. The UI requires the user
to make an address selection and passes that information to the
merchant.

If the merchant provides non-NULL shipping options, the merchant does
not need shipping address to calculate shipping costs. The UI selects
the default shipping address, but does not send it to the merchant until
the user clicks "Pay".

BUG=607705
==========

to

==========
Implement PaymentRequestUpdateEvent

When PaymentRequest.onShippingAddressChange or
PaymentRequest.onShippingOptionChange event fires, the event type should
be PaymentRequestUpdateEvent with a method updateWith(). This method
should allow the merchant to update the shipping options and the total
price.
https://w3c.github.io/browser-payment-api/specs/paymentrequest.html#idl-def-p...

BUG=607705
==========

[please use gerrit instead, 2016-05-02 16:16:59]

Description was changed from

==========
Implement PaymentRequestUpdateEvent

When PaymentRequest.onShippingAddressChange or
PaymentRequest.onShippingOptionChange event fires, the event type should
be PaymentRequestUpdateEvent with a method updateWith(). This method
should allow the merchant to update the shipping options and the total
price.
https://w3c.github.io/browser-payment-api/specs/paymentrequest.html#idl-def-p...

BUG=607705
==========

to

==========
Implement PaymentRequestUpdateEvent

When PaymentRequest.onShippingAddressChange or
PaymentRequest.onShippingOptionChange event fires, the event type should
be PaymentRequestUpdateEvent with a method updateWith(). This method
should allow the merchant to update the shipping options and the total
price.

https://w3c.github.io/browser-payment-api/specs/paymentrequest.html#idl-def-p...

BUG=607705
==========

[please use gerrit instead, 2016-05-02 16:43:09]

Patchset #1 (id:300001) has been deleted

[please use gerrit instead, 2016-05-02 17:40:52]

Patchset #1 (id:320001) has been deleted

[please use gerrit instead, 2016-05-02 17:42:59]

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

[please use gerrit instead, 2016-05-02 17:43:00]

dfalcantara@, ptal chrome/android/.

mek@, ptal third_party/WebKit/Source/modules/payments/.

Please ignore the trybot failures. This patch has dependencies that trybots do
not pick up.

[please use gerrit instead, 2016-05-02 17:44:21]

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

[please use gerrit instead, 2016-05-02 17:44:22]

palmer@, ptal payment_request.mojom.

[palmer, 2016-05-02 22:37:27]

lgtm

[please use gerrit instead, 2016-05-02 23:18:45]

mek@ and dfalcantara@: I am rebasing on top of the landed patches and applying
your general comments from other code reviews here.

[gone, 2016-05-03 05:32:47]

Has the rebase happened yet?  Didn't see it uploaded.

[haraken, 2016-05-03 12:34:35]

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

[haraken, 2016-05-03 12:34:36]

Binding implementation in modules/ LGTM.

https://codereview.chromium.org/1931233002/diff/340001/third_party/WebKit/Sou...
File third_party/WebKit/Source/modules/payments/PaymentRequest.cpp (right):

https://codereview.chromium.org/1931233002/diff/340001/third_party/WebKit/Sou...
third_party/WebKit/Source/modules/payments/PaymentRequest.cpp:401:
m_showResolver.clear();

Don't you want to call cleanUp()?

[gone, 2016-05-03 17:28:20]

https://chromiumcodereview.appspot.com/1931233002/diff/360001/chrome/android/...
File
chrome/android/javatests/src/org/chromium/chrome/browser/payments/PaymentRequestTestBase.java
(right):

https://chromiumcodereview.appspot.com/1931233002/diff/360001/chrome/android/...
chrome/android/javatests/src/org/chromium/chrome/browser/payments/PaymentRequestTestBase.java:85:
clickPaymentUIView("option line", R.id.payments_selectable_option);
Won't this break if you have multiple selectable options?  Are you relying on
only ever having one?

[Marijn Kruisselbrink, 2016-05-03 17:57:28]

https://chromiumcodereview.appspot.com/1931233002/diff/360001/third_party/Web...
File third_party/WebKit/Source/modules/payments/PaymentRequest.cpp (right):

https://chromiumcodereview.appspot.com/1931233002/diff/360001/third_party/Web...
third_party/WebKit/Source/modules/payments/PaymentRequest.cpp:368:
ASSERT_UNUSED(success, success);
According to the deprecation comments in wtf/Assertions.h you should be using
"DCHECK() and ALLOW_UNUSED_LOCAL()" instead of ASSERT_UNUSED()

https://chromiumcodereview.appspot.com/1931233002/diff/360001/third_party/Web...
File third_party/WebKit/Source/modules/payments/PaymentRequestTest.cpp (right):

https://chromiumcodereview.appspot.com/1931233002/diff/360001/third_party/Web...
third_party/WebKit/Source/modules/payments/PaymentRequestTest.cpp:239:
((mojom::blink::PaymentRequestClient*)request)->OnPaymentResponse(std::move(response));
static_cast (also in the rest of the file)

https://chromiumcodereview.appspot.com/1931233002/diff/360001/third_party/Web...
File third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.cpp
(right):

https://chromiumcodereview.appspot.com/1931233002/diff/360001/third_party/Web...
third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.cpp:95:
return new PaymentRequestUpdateEvent(type);
You should probably pass the EventInit to the constructor so it can be passed to
Event's constructor.

https://chromiumcodereview.appspot.com/1931233002/diff/360001/third_party/Web...
third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.cpp:105:
promise.then(UpdatePaymentDetailsFunction::createFunction(scriptState,
m_updater),
This seems to be missing the various checks from the spec that can result in an
InvalidStateError, as well as setting the stop propagation flags.

https://chromiumcodereview.appspot.com/1931233002/diff/360001/third_party/Web...
File third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.h
(right):

https://chromiumcodereview.appspot.com/1931233002/diff/360001/third_party/Web...
third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.h:26:
static PaymentRequestUpdateEvent* create(const AtomicString& type);
Do you actually need a create method that takes a type but no Init dictionary?
Other events with similar constructor signature seem to be able to get away with
only having a create() and a create(type, init) method.

[please use gerrit instead, 2016-05-03 21:26:31]

Description was changed from

==========
Implement PaymentRequestUpdateEvent

When PaymentRequest.onShippingAddressChange or
PaymentRequest.onShippingOptionChange event fires, the event type should
be PaymentRequestUpdateEvent with a method updateWith(). This method
should allow the merchant to update the shipping options and the total
price.

https://w3c.github.io/browser-payment-api/specs/paymentrequest.html#idl-def-p...

BUG=607705
==========

to

==========
Implement PaymentRequestUpdateEvent

When onShippingAddressChange or onShippingOptionChange event fires, the
event type should be PaymentRequestUpdateEvent with an updateWith()
method.

 - The updateWith() method lets the merchant update the shipping options
   and the total price.

 - The updateWith() method cannot be called twice for the same event.

 - The updateWith() method can be called only when the event is being
   dispatched.

https://w3c.github.io/browser-payment-api/specs/paymentrequest.html#idl-def-p...

BUG=607705
==========

[please use gerrit instead, 2016-05-03 21:38:33]

dfalcantara@ & mek@, ptal patch 4.

haraken@, see my answer to your question below.

https://chromiumcodereview.appspot.com/1931233002/diff/340001/third_party/Web...
File third_party/WebKit/Source/modules/payments/PaymentRequest.cpp (right):

https://chromiumcodereview.appspot.com/1931233002/diff/340001/third_party/Web...
third_party/WebKit/Source/modules/payments/PaymentRequest.cpp:401:
m_showResolver.clear();
On 2016/05/03 12:34:35, haraken wrote:
> 
> Don't you want to call cleanUp()?

Should not call cleanUp() here, because the merchant website still needs to
process the payment and call response.complete(true/false). This allows the
payment UI to display either "Payment processed" or "Failed to process payment"
message. I've added a comment to clarify this.

https://chromiumcodereview.appspot.com/1931233002/diff/360001/chrome/android/...
File
chrome/android/javatests/src/org/chromium/chrome/browser/payments/PaymentRequestTestBase.java
(right):

https://chromiumcodereview.appspot.com/1931233002/diff/360001/chrome/android/...
chrome/android/javatests/src/org/chromium/chrome/browser/payments/PaymentRequestTestBase.java:85:
clickPaymentUIView("option line", R.id.payments_selectable_option);
On 2016/05/03 17:28:20, dfalcantara wrote:
> Won't this break if you have multiple selectable options?  Are you relying on
> only ever having one?

I am indeed relying on having only one in the integration test. When I write
more advanced tests, I will figure out how to click the first, second, or third
option. Are you OK with this approach?

https://chromiumcodereview.appspot.com/1931233002/diff/360001/third_party/Web...
File third_party/WebKit/Source/modules/payments/PaymentRequest.cpp (right):

https://chromiumcodereview.appspot.com/1931233002/diff/360001/third_party/Web...
third_party/WebKit/Source/modules/payments/PaymentRequest.cpp:368:
ASSERT_UNUSED(success, success);
On 2016/05/03 17:57:28, Marijn Kruisselbrink wrote:
> According to the deprecation comments in wtf/Assertions.h you should be using
> "DCHECK() and ALLOW_UNUSED_LOCAL()" instead of ASSERT_UNUSED()

Done.

https://chromiumcodereview.appspot.com/1931233002/diff/360001/third_party/Web...
File third_party/WebKit/Source/modules/payments/PaymentRequestTest.cpp (right):

https://chromiumcodereview.appspot.com/1931233002/diff/360001/third_party/Web...
third_party/WebKit/Source/modules/payments/PaymentRequestTest.cpp:239:
((mojom::blink::PaymentRequestClient*)request)->OnPaymentResponse(std::move(response));
On 2016/05/03 17:57:28, Marijn Kruisselbrink wrote:
> static_cast (also in the rest of the file)

Done.

https://chromiumcodereview.appspot.com/1931233002/diff/360001/third_party/Web...
File third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.cpp
(right):

https://chromiumcodereview.appspot.com/1931233002/diff/360001/third_party/Web...
third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.cpp:95:
return new PaymentRequestUpdateEvent(type);
On 2016/05/03 17:57:28, Marijn Kruisselbrink wrote:
> You should probably pass the EventInit to the constructor so it can be passed
to
> Event's constructor.

Done.

https://chromiumcodereview.appspot.com/1931233002/diff/360001/third_party/Web...
third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.cpp:105:
promise.then(UpdatePaymentDetailsFunction::createFunction(scriptState,
m_updater),
On 2016/05/03 17:57:28, Marijn Kruisselbrink wrote:
> This seems to be missing the various checks from the spec that can result in
an
> InvalidStateError,

Now checking:
 - The event is being fired.
 - updateWith() is called only once.

> as well as setting the stop propagation flags.

Done.

https://chromiumcodereview.appspot.com/1931233002/diff/360001/third_party/Web...
File third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.h
(right):

https://chromiumcodereview.appspot.com/1931233002/diff/360001/third_party/Web...
third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.h:26:
static PaymentRequestUpdateEvent* create(const AtomicString& type);
On 2016/05/03 17:57:28, Marijn Kruisselbrink wrote:
> Do you actually need a create method that takes a type but no Init dictionary?
> Other events with similar constructor signature seem to be able to get away
with
> only having a create() and a create(type, init) method.

Done.

[Marijn Kruisselbrink, 2016-05-03 22:28:51]

https://chromiumcodereview.appspot.com/1931233002/diff/400001/third_party/Web...
File third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.cpp
(right):

https://chromiumcodereview.appspot.com/1931233002/diff/400001/third_party/Web...
third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.cpp:101:
DCHECK(m_updater);
This can't just be a DCHECK, you need to actually handle m_updater being null (a
javascript created PaymentRequestUpdateEvent won't have an updater set).

https://chromiumcodereview.appspot.com/1931233002/diff/400001/third_party/Web...
third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.cpp:113:
stopPropagation();
I think calling just stopImmediatePropagation() is enough, as in blink that
implies also stopPropagation.

https://chromiumcodereview.appspot.com/1931233002/diff/400001/third_party/Web...
File
third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEventTest.cpp
(right):

https://chromiumcodereview.appspot.com/1931233002/diff/400001/third_party/Web...
third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEventTest.cpp:16:
#include <utility>
probably just my fault, but I don't see where this header is used?

[please use gerrit instead, 2016-05-03 22:39:38]

Description was changed from

==========
Implement PaymentRequestUpdateEvent

When onShippingAddressChange or onShippingOptionChange event fires, the
event type should be PaymentRequestUpdateEvent with an updateWith()
method.

 - The updateWith() method lets the merchant update the shipping options
   and the total price.

 - The updateWith() method cannot be called twice for the same event.

 - The updateWith() method can be called only when the event is being
   dispatched.

https://w3c.github.io/browser-payment-api/specs/paymentrequest.html#idl-def-p...

BUG=607705
==========

to

==========
Implement PaymentRequestUpdateEvent

When onShippingAddressChange or onShippingOptionChange event fires, the
event type should be PaymentRequestUpdateEvent with an updateWith()
method.

 - The updateWith() method lets the merchant update the shipping options
   and the total price.

 - The updateWith() method cannot be called twice for the same event.

 - The updateWith() method can be called only when the event is being
   dispatched.

 - Dispatching a PaymentRequestUpdateEvent created in JavaScript is a
   no-op.

https://w3c.github.io/browser-payment-api/specs/paymentrequest.html#idl-def-p...

BUG=607705
==========

[gone, 2016-05-04 02:01:03]

java stuff lgtm

https://chromiumcodereview.appspot.com/1931233002/diff/360001/chrome/android/...
File
chrome/android/javatests/src/org/chromium/chrome/browser/payments/PaymentRequestTestBase.java
(right):

https://chromiumcodereview.appspot.com/1931233002/diff/360001/chrome/android/...
chrome/android/javatests/src/org/chromium/chrome/browser/payments/PaymentRequestTestBase.java:85:
clickPaymentUIView("option line", R.id.payments_selectable_option);
On 2016/05/03 21:38:33, Rouslan wrote:
> On 2016/05/03 17:28:20, dfalcantara wrote:
> > Won't this break if you have multiple selectable options?  Are you relying
on
> > only ever having one?
> 
> I am indeed relying on having only one in the integration test. When I write
> more advanced tests, I will figure out how to click the first, second, or
third
> option. Are you OK with this approach?

Yeah, sounds good.

https://chromiumcodereview.appspot.com/1931233002/diff/400001/chrome/test/dat...
File chrome/test/data/android/payments/payment_request_need_address_test.html
(right):

https://chromiumcodereview.appspot.com/1931233002/diff/400001/chrome/test/dat...
chrome/test/data/android/payments/payment_request_need_address_test.html:46:
{'requestShipping' : true});
nit: indentation looks weird here

[please use gerrit instead, 2016-05-05 04:55:03]

Patchset #5 (id:420001) has been deleted

[please use gerrit instead, 2016-05-05 04:57:47]

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

[please use gerrit instead, 2016-05-05 04:57:48]

mek@, ptal patch 5.

asvitkine@, ptal histograms.xml in patch 5.

dfalcantara@, fyi, the integration tests are removed from this patch due to the
strict mode issue.

https://codereview.chromium.org/1931233002/diff/400001/chrome/test/data/andro...
File chrome/test/data/android/payments/payment_request_need_address_test.html
(right):

https://codereview.chromium.org/1931233002/diff/400001/chrome/test/data/andro...
chrome/test/data/android/payments/payment_request_need_address_test.html:46:
{'requestShipping' : true});
On 2016/05/04 02:01:03, dfalcantara wrote:
> nit: indentation looks weird here

Removed integration tests from this patch.

https://codereview.chromium.org/1931233002/diff/400001/third_party/WebKit/Sou...
File third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.cpp
(right):

https://codereview.chromium.org/1931233002/diff/400001/third_party/WebKit/Sou...
third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.cpp:101:
DCHECK(m_updater);
On 2016/05/03 22:28:51, Marijn Kruisselbrink wrote:
> This can't just be a DCHECK, you need to actually handle m_updater being null
(a
> javascript created PaymentRequestUpdateEvent won't have an updater set).

Done.

https://codereview.chromium.org/1931233002/diff/400001/third_party/WebKit/Sou...
third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.cpp:113:
stopPropagation();
On 2016/05/03 22:28:51, Marijn Kruisselbrink wrote:
> I think calling just stopImmediatePropagation() is enough, as in blink that
> implies also stopPropagation.

Done.

https://codereview.chromium.org/1931233002/diff/400001/third_party/WebKit/Sou...
File
third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEventTest.cpp
(right):

https://codereview.chromium.org/1931233002/diff/400001/third_party/WebKit/Sou...
third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEventTest.cpp:16:
#include <utility>
On 2016/05/03 22:28:51, Marijn Kruisselbrink wrote:
> probably just my fault, but I don't see where this header is used?

You're right. It's not used in this file. It was an artifact of copying from
PaymentRequest.cpp to bootstrap.

Removed this include and verified the other includes are used in this file.

[Marijn Kruisselbrink, 2016-05-05 16:39:30]

lgtm

[Alexei Svitkine (slow), 2016-05-05 17:27:56]

lgtm

[please use gerrit instead, 2016-05-05 17:44:25]

The CQ bit was checked by rouslan@chromium.org

[please use gerrit instead, 2016-05-05 17:44:26]

The patchset sent to the CQ was uploaded after l-g-t-m from palmer@chromium.org,
haraken@chromium.org, dfalcantara@chromium.org, mek@chromium.org
Link to the patchset: https://codereview.chromium.org/1931233002/#ps460001
(title: "Rebase")

[commit-bot: I haz the power, 2016-05-05 17:45:09]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1931233002/460001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1931233002/460001

[commit-bot: I haz the power, 2016-05-05 22:56:28]

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

[commit-bot: I haz the power, 2016-05-05 22:56:30]

Try jobs failed on following builders:
  win_chromium_rel_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[please use gerrit instead, 2016-05-05 23:02:22]

The CQ bit was checked by rouslan@chromium.org

[commit-bot: I haz the power, 2016-05-05 23:02:52]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1931233002/460001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1931233002/460001

[commit-bot: I haz the power, 2016-05-06 01:28:04]

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

[commit-bot: I haz the power, 2016-05-06 01:28:06]

Failed to apply patch for third_party/WebKit/Source/core/frame/UseCounter.h:
While running git apply --index -3 -p1;
  error: patch failed: third_party/WebKit/Source/core/frame/UseCounter.h:1154
  Falling back to three-way merge...
  Applied patch to 'third_party/WebKit/Source/core/frame/UseCounter.h' with
conflicts.
  U third_party/WebKit/Source/core/frame/UseCounter.h

Patch:       third_party/WebKit/Source/core/frame/UseCounter.h
Index: third_party/WebKit/Source/core/frame/UseCounter.h
diff --git a/third_party/WebKit/Source/core/frame/UseCounter.h
b/third_party/WebKit/Source/core/frame/UseCounter.h
index
432275a9999d44379407a3ac9188b7dafadb46b5..fa941da4f79bf4b3d569b5c779e56078dde928ac
100644
--- a/third_party/WebKit/Source/core/frame/UseCounter.h
+++ b/third_party/WebKit/Source/core/frame/UseCounter.h
@@ -1154,6 +1154,7 @@ public:
         During_Microtask_Print = 1336,
         During_Microtask_Prompt = 1337,
         During_Microtask_SyncXHR = 1338,
+        DocumentCreateEventPaymentRequestUpdateEvent = 1339,
 
         // Add new features immediately above this line. Don't change assigned
         // numbers of any item, and don't reuse removed slots.

[please use gerrit instead, 2016-05-06 01:51:43]

The CQ bit was checked by rouslan@chromium.org

[please use gerrit instead, 2016-05-06 01:51:44]

The patchset sent to the CQ was uploaded after l-g-t-m from
haraken@chromium.org, palmer@chromium.org, mek@chromium.org,
asvitkine@chromium.org, dfalcantara@chromium.org
Link to the patchset: https://codereview.chromium.org/1931233002/#ps480001
(title: "Rebase")

[commit-bot: I haz the power, 2016-05-06 01:52:11]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1931233002/480001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1931233002/480001

[commit-bot: I haz the power, 2016-05-06 04:23:06]

Committed patchset #7 (id:480001)

[commit-bot: I haz the power, 2016-05-06 04:25:05]

Description was changed from

==========
Implement PaymentRequestUpdateEvent

When onShippingAddressChange or onShippingOptionChange event fires, the
event type should be PaymentRequestUpdateEvent with an updateWith()
method.

 - The updateWith() method lets the merchant update the shipping options
   and the total price.

 - The updateWith() method cannot be called twice for the same event.

 - The updateWith() method can be called only when the event is being
   dispatched.

 - Dispatching a PaymentRequestUpdateEvent created in JavaScript is a
   no-op.

https://w3c.github.io/browser-payment-api/specs/paymentrequest.html#idl-def-p...

BUG=607705
==========

to

==========
Implement PaymentRequestUpdateEvent

When onShippingAddressChange or onShippingOptionChange event fires, the
event type should be PaymentRequestUpdateEvent with an updateWith()
method.

 - The updateWith() method lets the merchant update the shipping options
   and the total price.

 - The updateWith() method cannot be called twice for the same event.

 - The updateWith() method can be called only when the event is being
   dispatched.

 - Dispatching a PaymentRequestUpdateEvent created in JavaScript is a
   no-op.

https://w3c.github.io/browser-payment-api/specs/paymentrequest.html#idl-def-p...

BUG=607705

Committed: https://crrev.com/84234b56d641a989f709976793cff331b5488684
Cr-Commit-Position: refs/heads/master@{#392002}
==========

[commit-bot: I haz the power, 2016-05-06 04:25:07]

Patchset 7 (id:??) landed as
https://crrev.com/84234b56d641a989f709976793cff331b5488684
Cr-Commit-Position: refs/heads/master@{#392002}