1469419 - Figure out and implement what should happen when there are two active calls to PaymentRequest.show

Status: NEW

(Core :: DOM: Web Payments, enhancement, P1)

Description

[Blake Kaplan (:mrbkap) (inactive)]

In bug 1442453 I removed some code that was attempting to enforce the constraint that: "there should only be one active call to PaymentRequst.show() per tab at any given time."

The current behavior, as it stands after the patches for bug 1442453 is not great: we'll allow one active show call per process. That would lead to (from the user's point of view) random tabs refusing to open a second payment dialog.

It would be relatively easy to re-implement the "one active request per tab" behavior or even a "only one request allowed globally" policy or anything in between.

Comment 1

[Chris Mills [:cmills]]

This ought to be documented.

Comment 2

[Matthew N. [:MattN]]

We'll use this bug to track the post-M3 long term solution while bug 1478740 will handle the short-term solution (app-modal).

Comment 3

[Matthew N. [:MattN]]

On the front-end we have now landed our tab-modal dialog (see bug 1435871 and meta bug 1433047) so we'd like to switch to allowing multiple simultaneous Payment Request dialogs to be shown for separate tabs. It's very confusing to click a checkout button in one window or tab but have it not show the dialog just because one tab is already showing one.

Comment 4

[Marcos Caceres [:marcosc]]

> It's very confusing to click a checkout button in one window or tab but have it not show the dialog just because one tab is already showing one.

Understood. We can definitely support this for now, but we should keep in mind that we might need to revert back in the future if we need to rely on biometric verification for payments (where the verification challenge will likely be bound to a particular payment request instance).

Comment 5

[Matthew N. [:MattN]]

Yeah, that's a possibility but I also think it's possible to have a UX where you can support multiple simultaneous requests and not have ambiguous confirmations.

Comment 6

[Marcos Caceres [:marcosc]]

(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #5)
> Yeah, that's a possibility but I also think it's possible to have a UX where
> you can support multiple simultaneous requests and not have ambiguous
> confirmations.

Agree. Let's deal with the basic card case for now (one-per-tab is great!).

Comment 7

[Eric Shepherd [:sheppy]]

So to be clear, we are intentionally going against the specification, which specifically says that only one payment panel should be displayed at once, yes? As per the spec:

'It is not possible to show multiple PaymentRequests at the same time within one user agent. If a PaymentRequest is already showing, calling show() —from any Web site— will return a promise rejected with an "AbortError" DOMException.

I have no complaint about that necessarily; I just want to be sure we're going in with both eyes open. This also introduces some interesting documentation things to figure out. :)

Comment 8

[Matthew N. [:MattN]]

Yes, that's correct. See bug 1478740 comment 4 where I mentioned the wilful violation.

Comment 9

[Marcos Caceres [:marcosc]]

(In reply to Eric Shepherd [:sheppy] from comment #7)
> So to be clear, we are intentionally going against the specification, which
> specifically says that only one payment panel should be displayed at once,
> yes? As per the spec:
> 
> 'It is not possible to show multiple PaymentRequests at the same time within
> one user agent. If a PaymentRequest is already showing, calling show() —from
> any Web site— will return a promise rejected with an "AbortError"
> DOMException.

I've sent a PR to fix this in the spec :) 
https://github.com/w3c/payment-request/pull/811

 
> I have no complaint about that necessarily; I just want to be sure we're
> going in with both eyes open. This also introduces some interesting
> documentation things to figure out. :)

So, if the PR gets accepted (which I think it will), it will be up to the payment handler (e.g., basic-card) to control this. In which case, we can implement showing multiple payment sheets and no longer in violation of the spec.

Comment 10

[Eric Shepherd [:sheppy]]

I've added a note to the show() page saying that browsers may not follow the spec on this, but more importantly, I'm subscribed to that PR so that if/when it's accepted, I can update the docs accordingly.

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.