Marijn: Do you know whether Blink code in PaymentRequest.cpp has the ability to check whether an event listener for PaymentRequest.shippingaddresschange is registered?

EventTarget does have a hasEventListeners(eventType) method, so yes, it is possible to check that. Having said that, is this really the expected behavior? It doesn't seem to be something that is currently specified in the spec?

Matt: can you put this in the spec, please?

In the meantime, we can print a console warning in this situation.

 Issue 667248  has been merged into this issue.

Marcos: Is my reading of https://w3c.github.io/payment-request/#dom-paymentrequestupdateevent correct in that the web developer must handle 'shippingaddressupdate' event? (Otherwise, the UI will be blocked until a timeout.)

WIP @ https://crrev.com/c/684655 (no need to review until Marcos's answer)

> Marcos: Is my reading of https://w3c.github.io/payment-request/#dom-paymentrequestupdateevent correct in that the web developer must handle 'shippingaddressupdate' event? (Otherwise, the UI will be blocked until a timeout.)

It's the other way around: the UI MUST block only if .updateWith() is *immediately* called... otherwise, it MUST NOT block. Please see also the examples:
https://w3c.github.io/payment-request/#updatewith()-method

Which describes precisely this case. I'm concerned if this is still not clear in the spec - and I apologize if it's not clear.

Consider how credit card selection works in the payment sheet: a user can change credit cards as many times as they like. The user selecting a credit card is reflected immediately in the UI because no event is sent to the page. 

Now, consider changing a shipping address: this notifies the page, allowing the merchant to check if the new address is ok. However, if the merchant doesn't care, they shouldn't need to register a listener. If no listener is registered, and updateWith() is not called, then the payment sheet must not lock up (it must reflect the user's new chosen address, even if that address was not checked by the merchant).

Hope that helps! 

Marcos: To clarify, if the merchant listens to the change events, but does not call updateWith(), that should not block UI, correct? (A la https://rsolomakhin.github.io/pr/ko/updatewith/)

> Marcos: To clarify, if the merchant listens to the change events, but does not call updateWith(), that should not block UI, correct? 

That is correct. 

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

commit a9ff9281d5c4ead62b89427baa7bf3e011b33dce
Author: Rouslan Solomakhin <rouslan@chromium.org>
Date: Tue Oct 31 21:58:05 2017

[Payments] Handle absence of updateWith() call.

Before this patch, a failure to call updateWith() in the handlers for
'shippingaddresschange' and 'shippingoptionchange' events with
requestShipping: true option would cause timeouts in spinner of the
payments UI, when the user changed their shipping address or shipping
option.

This patch fires the events synchronously instead async and checks
whether the web developer called updateWith(). The events are originated
from the browser process and arrive in the renderer asynchronously via
mojo, so the asyncness of the events is preserved. If the web developer
did not call updateWith(), then Chrome hides the spinner and unblocks UI
to allow user interaction. Chrome also prints a warning message to the
developer noting that the user may be looking at outdated line items and
total price when this happens.

After this patch, a failure to call updateWith() in the handlers for
'shippingaddresschange' and 'shippingoptionchange' events with
requestShipping: true option would not cause timeouts in UI.

TBR=mek@chromium.org

Bug:  709282 
Change-Id: Ieb7f06d0668af1fe713d9b632090b16af0908d8d
Reviewed-on: https://chromium-review.googlesource.com/684655
Commit-Queue: Rouslan Solomakhin <rouslan@chromium.org>
Reviewed-by: anthonyvd <anthonyvd@chromium.org>
Reviewed-by: Mathieu Perreault <mathp@chromium.org>
Reviewed-by: Ganggui Tang <gogerald@chromium.org>
Cr-Commit-Position: refs/heads/master@{#512968}
[modify] https://crrev.com/a9ff9281d5c4ead62b89427baa7bf3e011b33dce/chrome/android/java/src/org/chromium/chrome/browser/payments/PaymentRequestFactory.java
[modify] https://crrev.com/a9ff9281d5c4ead62b89427baa7bf3e011b33dce/chrome/android/java/src/org/chromium/chrome/browser/payments/PaymentRequestImpl.java
[modify] https://crrev.com/a9ff9281d5c4ead62b89427baa7bf3e011b33dce/chrome/android/java_sources.gni
[add] https://crrev.com/a9ff9281d5c4ead62b89427baa7bf3e011b33dce/chrome/android/javatests/src/org/chromium/chrome/browser/payments/PaymentRequestNoUpdateWithTest.java
[add] https://crrev.com/a9ff9281d5c4ead62b89427baa7bf3e011b33dce/chrome/browser/ui/views/payments/payment_request_no_update_with_browsertest.cc
[modify] https://crrev.com/a9ff9281d5c4ead62b89427baa7bf3e011b33dce/chrome/test/BUILD.gn
[modify] https://crrev.com/a9ff9281d5c4ead62b89427baa7bf3e011b33dce/components/payments/content/payment_request.cc
[modify] https://crrev.com/a9ff9281d5c4ead62b89427baa7bf3e011b33dce/components/payments/content/payment_request.h
[modify] https://crrev.com/a9ff9281d5c4ead62b89427baa7bf3e011b33dce/components/payments/content/payment_request_spec.cc
[modify] https://crrev.com/a9ff9281d5c4ead62b89427baa7bf3e011b33dce/components/payments/content/payment_request_spec.h
[add] https://crrev.com/a9ff9281d5c4ead62b89427baa7bf3e011b33dce/components/test/data/payments/no_update_with.js
[add] https://crrev.com/a9ff9281d5c4ead62b89427baa7bf3e011b33dce/components/test/data/payments/payment_request_no_update_with_test.html
[modify] https://crrev.com/a9ff9281d5c4ead62b89427baa7bf3e011b33dce/third_party/WebKit/Source/modules/payments/PaymentRequest.cpp
[modify] https://crrev.com/a9ff9281d5c4ead62b89427baa7bf3e011b33dce/third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.cpp
[modify] https://crrev.com/a9ff9281d5c4ead62b89427baa7bf3e011b33dce/third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.h
[modify] https://crrev.com/a9ff9281d5c4ead62b89427baa7bf3e011b33dce/third_party/WebKit/public/platform/modules/payments/payment_request.mojom

Tested on Samsung Galaxy J52016(SM-J510MN)/MMB29M

Re-tested this fix with below steps:
change your shipping address on 
https://rsolomakhin.github.io/pr/ko/no-listener/ and https://rsolomakhin.github.io/pr/ko/updatewith/ 
Observed behavior:the payment sheet should not timeout with a "Loading..." spinner.