New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 667248 link

Starred by 1 user
Status: Duplicate
Merged: issue 709282
Owner:
rouslan@chromium.org
Closed: Jun 2017
Cc:
█ zkoch@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: Bug



Sign in to add a comment

UI hanging when no PaymentRequestUpdateEvent subscribers

Reported by tom...@opera.com, Nov 21 2016 
Version: Latest Chrome Dev or Chromium built from master
OS: Android


What steps will reproduce the problem?
(1) Navigate to https://tommythorsen.github.io/webpayments-demo/merchants/eventbug/
(2) Click "Buy" on any of the items
(3) Select a shipping address


What is the expected result?

The new shipping address should become selected.


What happens instead?

Instead, the UI hangs and eventually times out, displaying a spinner and the text "Checking"

The reason for this is that the page does not subscribe to shippingaddresschange or shippingoptionchange. It is, however, legal to not subscribe to these events according to the specification. It is also legal to subscribe to these events, but not call the updateWith function. The UI should only block, awaiting an update from the merchant, if the merchant 1) subscribes to the event, and 2) calls updateWith from event handling method.

We need to change the logic that blocks the UI, so that it's somehow linked to the promise provided to updateWith.


If you agree with my analysis and proposed change, I don't mind taking a shot at fixing this. If so, feel free to reassign this back to me.

Comment 1 by rouslan@chromium.org, Nov 21 2016

Cc: zkoch@chromium.org
I think that subscribing to shippingaddresschange and shippingoptionchange events should be mandatory for any website that specifies "requestShipping: true" in options. The following examples are close to your test website:

https://googlechrome.github.io/samples/paymentrequest/shipping-options/

https://rsolomakhin.github.io/pr/multi/

+zkoch@ to double-check.

Comment 2 by zkoch@chromium.org, Nov 21 2016 

Hey tommyt, I'm not sure I understand your propose solution. Can you clarify it? What should happen in the UI?

Comment 3 by tom...@opera.com, Nov 21 2016 

@rouslan:

Making subscriptions mandatory when requestShipping is true, would make some sense, but I don't believe that's what is currently specified. The specification can very likely be changed, but I would prefer not to be the one to make that argument to the Working Group, as I personally slightly prefer the currently specified behavior.

@zkoch:

The current UI blocks immediately after posting an event and waits for updateWith to be called. I propose that the UI should only block if updateWith is called (with a promise that resolves with new payment details).

This would make it possible for a merchant to have static shipping options and no event listeners. It would also be possible for the merchant to listen to shipping option changes, but not call updateWith unless changes to the payment details are required.

Comment 4 by rsgav...@chromium.org, Jan 25 2017

Status: Assigned (was: Untriaged)

Comment 5 by rouslan@chromium.org, Jun 8 2017

Mergedinto: 709282
Status: Duplicate (was: Assigned)
►

Sign in to add a comment