Attach 'payment request is showing boolean' to top-level browsing context

[marcoscaceres]

closes #809

The following tasks have been completed:

• Confirmed there are no ReSpec errors/warnings.
• Modified Web platform tests
• Modified MDN Docs (link)

Implementation commitment:

• Safari (link to issue)
• Chrome
• Firefox
• Edge (public signal)

Optional, impact on Payment Handler spec?

Yes. Payment Handlers might need to have a means of keeping track of open payment sheets.

---

Preview | Diff

[marcoscaceres]

@ianbjacobs, you want to give this first read?

@rsolomakhin, we will need to consider more fully what it means for Payment Handlers. I was a bit unsure if I should file a separate bug for Handlers itself.

[rsolomakhin]

A payment handler is able to enumerate all of its own windows through the Clients API in service worker, so it can take the appropriate actions inside of the 'paymentrequest' event to either abort the current payment, abort other ongoing payments, or allow multiple ongoing payments. We should not need to add anything else to the payment handler spec for now. Does that make sense?

[marcoscaceres]

Perfect! Thanks @rsolomakhin!

Next big question: willing to change Chrome to match Firefox? :)

[rsolomakhin]

Yes, sir! From what I understand, you're proposing that each browser tab have ability to show its own payment sheet. I would be willing to enable this in Chrome.

[marcoscaceres]

Awesome! Ok, cool. I think we have all we need to move forward on this 🥳

I’ll get a review from Domenic, just to make sure I didn’t miss anything.

[marcoscaceres]

@rsolomakhin when possible, could you provide a link to a Chrome bug. No hurry, I know you all are on vacation next few days.

[rsolomakhin]

Linked in description.

[domenic]

Needs more precision. "The top-level browsing context" is never correct; there are many of them per UA, which is why we're making this change, after all. So pick specific JS objects (presumably the PaymentRequest/PaymentResponse instances) and navigate from them to top-level BCs.

[domenic]

"the top-level browsing context" is not well-defined. Consider a same-origin popup window (i.e. two separate top-level windows which can synchronously access each other). Then call window1.PaymentRequest.prototype.show.call(window2PaymentRequestInstance). Which top-level BC is this algorithm talking about in that case? The popup window or the original window?

You want "this PaymentRequest's relevant global object's browsing context's top-level browsing context". Maybe make a definition to shorten that (e.g. "payment-relevant browsing context of obj" or "payment request is showing in the same browsing context as obj").

And, if you're feeling evil, write tests for the case I described ^_^.

[marcoscaceres]

Thanks! I had a bad feeling about "top-level browsing context"... the suggestion is great. I'll definitely add the test 😼.

[marcoscaceres]

window1.PaymentRequest.prototype.show.call(window2PaymentRequestInstance)

@domenic, just to make sure I got this right.

Both of these would theoretically show the payment sheet in the popup:

button.onclick = () => {
    const popup = window.open("some.html");
    await new Promise(resolve => (popup.onload = resolve));
    const r = new popup.PaymentRequest(methods, details);
    await r.show();
}

And:

button.onclick = () => {
    const popup = window.open("some.html");
    await new Promise(resolve => (popup.onload = resolve));
    const r = new popup.PaymentRequest(methods, details);
    await PaymentRequest.prototype.show.call(r);
}

Is that correct? ....

And then could go from popup.opener, and show a payment sheet in the opener from the popup.

I've put up an initial set that use just an iframe:
#811

[marcoscaceres]

Err, sorry, copypasta, tests are here web-platform-tests/wpt#14297
(I've not run them - so probably buggy)

[domenic]

Both of these would theoretically show the payment sheet in the popup:

Yeah, that's right!

And then could go from popup.opener, and show a payment sheet in the opener from the popup.

I don't quite understand what you mean here.

I've put up an initial set that use just an iframe:

I'll take a look, but iframes are not as good a test here, as they aren't top-level browsing contexts. The payment-relevant browsing context of a PaymentRequest created inside an iframe is its parent browsing context. Popups are special because they are top-level; they don't have a parent, just an opener.

[marcoscaceres]

And then could go from popup.opener, and show a payment sheet in the opener from the popup.

@domenic, imagine the following situation:

// this is actually a new browser tab...
const popupTab = window.open("tab.html");

// in which tab does the sheet show? In the popup tab or in opener tab? 
await new popupTab.PaymentRequest(method, details).show();

I guess "implementation detail"...

Similarly, consider this one (little window):

// We make a little window... imagine, without toolbars, etc.
const popupWindow = window.open("window.html", "width=100,height=100,...");

// in which window does the sheet show? In the little window or in opener? 
await new popupWindow.PaymentRequest(method, details).show();

Similarly, I guess "implementation detail"?... don't think we can do much in the spec, but just wanted to point this out.

[ianbjacobs]

Hi @marcoscaceres,

Editorial suggestion for the above

    ....showing</dfn> boolean to support <a>user agent</a> management of payment UI display. For example,
   a <a>user agent</a> might choose to show only one payment UI at a time.

[marcoscaceres]

Appreciate this suggestion, but it doesn't quite capture what we are trying to restrict here (don't show two payment UI in the same browser tab). I'll add a note describing what you are saying above.

[marcoscaceres]

Initial test set: web-platform-tests/wpt#14297

[marcoscaceres]

Sent an updated batch of tests for this pull request. Hope to merge this soon.

[rsolomakhin]

This still looks good to me. Do you need anything else from us?

[marcoscaceres]

@rsolomakhin no, it's all good from the spec side (appreciate you rechecking!). It was mostly on the test side of things. I was worried because I couldn't get the tests to run in Chrome... will follow up on the WPT side.