[w3c/browser-payment-api] Define expected behavior when no 'shippingaddresschange ' event listener is defined (#507)

At the moment the Chrome implement has an edge case that results in a bad user experience:

If the developer requires shipping details and doesn't set a shippingaddresschange event listener, the following happens:

1. The Payment Request sheet opens up.
1. The user adds or changes address
1. A spinner is shown (where it's waiting for event.updateWith() to be called)
1. The API times out and rejects the request.show() promise.

One of two things should be happening:

1. The API *requires* a `shippingaddresschange` event listener be defined and if it's not the case and `shipping` is required, an error should be thrown when `show()` is called.
1. The API doesn't require an event listener, but if there is no listener defined, allow the user to define any address (basically allowing the developer to skip validating the address or shipping option).

I'm in favor of the listener *not* being required just for developer ergonomics and allowing the developer to move this check to the very end of the checkout flow after the `show()` promise has resolved (i.e. not ideal for a user experience but could be the only option for developers).

The relevant spec section is https://www.w3.org/TR/payment-request/#updatewith-method 

> 7. If target.[[updating]] is true, then throw an "InvalidStateError" DOMException.
> 8. Set event's stop propagation flag and stop immediate propagation flag.
> 9. Set event.[[waitForUpdate]] to true.
> 10. Set target.[[updating]] to true.

I think a step needs to be added after 7 which consists of "If no event listener is defined, the user agent will XYZ", where XYZ will be either allow the changes from the user OR throw another "InvalidStateError".

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/browser-payment-api/issues/507