Suggest changing a shape of openWindow()

[romandev]

Introduction

Currently, there are some known issues in openWindow() API.

• First, when window client's focus state is changed, it's not clear how it works.
  • Tab switching
  • Explicit windowClient.focus() calls
• Second, in SW side, there is no way to detect that opened window's state is changed.
  • The pagevisibilitychange, beforeunload events are unhelpful. (Normative what happens when users closing the window opened by PaymentRequestEvent.openWindow #299)
  • For example, when users click X button, if the opened window can not send a response to SW, then respondWith()'s input promise may be pending forever during SW life time.
• Third, when users click refresh button, the input data (coming from SW to window) may be lost.
  • For example, users might unintentially use pull to refresh during scrolling page on Chrome mobile. In the opened window, PH authors can try to store the receive data to persistent storage(e.g. Indexed DB) but the refresh might happen before finishing to store the data.

Proposal

I'd suggest changing a shape of openWindow API. (based on #97)

Before

Promise<WindowClient> openWindow(USVString url);

After

Promise<PaymentHandlerResponse> openWindow(USVString url, optional object data);

Additionally, we will have to define the following interfaces to use in opened window.

partial interface Navigator {
  [SecureContext, SameObject] readonly attribute PaymentHandlerContainer paymentHandler;
};

[SecureContext, Exposed=Window]
interface PaymentHandlerContainer {
    readonly attribute object data;
    void providerResponse(PaymentHandlerResponse response);
};

• PaymentHandlerContainer should be exposed to opened window only.
• PaymentHandlerContainer.data should be synced with the data passed in when calling openWindow().
• PaymentHandlerContainer.providerResponse() is only allowed in opened window and when it is called, should resolve openWindow()'s result promise.

Example

SW side

self.addEventListener('paymentrequest', e => {
  e.respondWith(e.openWindow('...', {
    id: 'xxxxx',
    param1: 'param1',
    param2: 'param2',
  }));
});

Opened window

window.addEventListener('load', e => {
  assert 'xxxxx' === navigator.paymentHandler.data.id;
  assert 'param1' === navigator.paymentHandler.data.param1;
  assert 'param2' === navigator.paymentHandler.data.param2;

  ...

  navigator.paymentHandler.provideResponse({
    method: 'basic-card',
    data: {}
  });
});

WDYT?

/cc @rsolomakhin, @gogerald

[gogerald]

Not sure I understand how this solves the second problem. Opened window still needs to know when to call 'navigator.paymentHandler.provideResponse', right?

For the third problem, could we let opened window to contact SW to get payment request data every time after refresh ('load') so as not to cache payment request data?

[ianbjacobs]

/cc @anthonyvd, @DurgaTheHutt

[romandev]

@gogerald Thank you for your feedback. I left some comments.

Not sure I understand how this solves the second problem. Opened window still needs to know when to call 'navigator.paymentHandler.provideResponse', right?

The key difference is:
The original API resolves a return promise when a new window is created. On the other hand, the new API will resolve a return promise when the opened window is closed.

For the original API, openWindow() resolves a return promise with WindowClient as soon as a new window is created. After that, there is no opportunity to notify that the opened window is closed because openWindow() is already done. So, postMessage() is a unique way to notify that. But it’s not easy to determine when postMessage should be called even if using beforeunload or pagevisibilitychange events.

For the new API, it is not until the opened window is closed that openWindow() will not resolve(or reject) a return promise with PaymentHandlerResponse.

• If the window is not closed, the return promise is still pending.
• If the window is closed after calling navigator.paymentHandler.provideResponse(), the return promise will be resolved with PaymentHandlerResponse passed to provideResponse().
• If the window is closed without calling provideResponse(), the result promise is rejected with DOMException such as AbortError.

For the third problem, could we let opened window to contact SW to get payment request data every time after refresh ('load') so as not to cache payment request data?

Yes, we could but we aren't sure that navigator.serviceWorker.controller is always payment handlers SW. For example, if a payment handler site has two service workers as follows:

• XXX pay directory structures

/payment-handler/handler.js    // SW for payment handler
/payment-handler/register.html
/payment-handler/window/payment-ui.html
/payment-handler/window/cache-controller.js    // SW for UI Cache

The handler.js is a service worker for payment handler. Its scope is /payment-handler/. So, it can control register.html and payment-ui.html. BTW, for a performance reason, PaymentHandler author want to cache UI resources using some JS library(e.g. work box). So, the site also has a different service worker for UI resources caching.

In that case, The navigator.servicwWorker.controller in payment-ui.html will be cache-controller.js SW. Also, navigator.servicwWorker.controller.postMessage() in payment-ui.html will send the message to cache-controller.js SW.

Ideally, it would be better to combine the two SWs into a single SW but it's not easy to combine them that has each different purposes. I think it's unlikely that someone writes a general purpose SW util that can handle both cache and payment at the same time.

[gogerald]

Thanks for explanation, much more clear to me.

Got a question, do we support multiple active service workers for a page? From the spec (https://w3c.github.io/ServiceWorker/#serviceworkerglobalscope-interface), it looks we can have only one active service worker for a page. Then, the case you mentioned shouldn't exist, right?

Otherwise, can we have ServiceWorkerContainer.controllers.matchAll (similar like clients.matchAll) to find out the service worker at any time. This looks simpler.

[gogerald]

Just looked the service worker interfaces a little bit more, it looks we can get the service worker from the opened window through "ServiceWorkerContainer.getRegistration(scope).then(function(ServiceWorkerRegistration) { ServiceWorkerRegistration.active })"
or
"ServiceWorkerContainer.getRegistrations()"

[romandev]

Just looked the service worker interfaces a little bit more, it looks we can get the service worker from the opened window through "ServiceWorkerContainer.getRegistration(scope).then(function(ServiceWorkerRegistration) { ServiceWorkerRegistration.active })"
or
"ServiceWorkerContainer.getRegistrations()"

@gogerald, Thank you for your comment.
Yeah, it works. But I wanted that the opened window is not exposed as WindowClient.
For example, after finding WindowClient for the opened window using clients.matchAll(), calling windowClient.focus() is not clear what web-platform should do.

Okay, I don't want to be a blocker :) So, we can separate this issue from second issue.
I think we still need to resolve the second issue preferentially.

Do you agree with the following change (without data parameter)?

Before

Promise<WindowClient> openWindow(USVString url);

After

Promise<PaymentHandlerResponse> openWindow(USVString url);

partial interface Navigator {
  [SecureContext, SameObject] readonly attribute PaymentHandlerContainer paymentHandler;
};

[SecureContext, Exposed=Window]
interface PaymentHandlerContainer {
    void providerResponse(PaymentHandlerResponse response);
};

[gogerald]

Agreed that we should clear what windowClient.focus() should do for payment handler opened window. For 'providerResponse', it looks a little redundant to me since the service worker spec allows service worker and its controlled window to contact each other at any moment and developers may have been familiar with it. So I would not introduce new things to keep our spec and implementation simple, and less diverted.

[romandev]

For 'providerResponse', it looks a little redundant to me since the service worker spec allows service worker and its controlled window to contact each other at any moment and developers may have been familiar with it. So I would not introduce new things to keep our spec and implementation simple, and less diverted.

I have a better idea. If we just make openWindow()'s return promise wait to close the opened window, we can resolve the second issue easily with minimal change. I'll make a patch in Chromium/Blink quickly and then show you.

Before

Promise<WindowClient> openWindow(USVString url);

After

Promise<void> openWindow(USVString url);

Example

var paymentResult;

self.addEventListener('message', e => {
  if (!e.data) return;

  if (e.data.action === 'init') {
    e.source.postMessage({ ... });
  } else if (e.data.action === 'response') {
    paymentResult = e.data.responseData;
  }
});

self.addEventListener('paymentrequest', e => {
  e.waitUntil(async() => {
    // The following code should wait to close the opened window
    await e.openWindow("...");

    // If paymentResult is undefined, payment request will be aborted in merchant side.
    // If paymentResult has correct data, payment request will be succeeded.
    await e.respondWith(paymentResult);
  });
});

[dlongley]

It seems a little odd that the Promise for openWindow would resolve once the window is closed.

If it becomes important in the future to have access to the WindowClient for some reason, another option would be to introduce a waitUntilClosed or waitForClose method on WindowClient that returns a promise when the window is closed. This doesn't resolve some of the other issues, of course, but it may avoid painting into a corner.

[dlongley]

Example:

let paymentResult;

self.addEventListener('message', e => {
  if (!e.data) return;

  if (e.data.action === 'init') {
    e.source.postMessage({ ... });
  } else if (e.data.action === 'response') {
    paymentResult = e.data.responseData;
  }
});

self.addEventListener('paymentrequest', e => {
  e.waitUntil(async () => {
    const windowClient = await e.openWindow("...");
    // The following code should wait until the window is closed
    await windowClient.waitUntilClosed();

    // If paymentResult is undefined, payment request will be aborted in merchant side.
    // If paymentResult has correct data, payment request will be succeeded.
    await e.respondWith(paymentResult);
  });
});

Something more complicated could be cooked up if a close event could be listened for.

[rsolomakhin]

Payment handler partners have told us that it's difficult to accurately detect whether the window is opened by a payment handler. So window.paymentHandler would be useful for this. Can we find a good use for promises here? For example:

if (window.paymentHandler) {
  // This browser has support for payment handlers.
  window.paymentHandler.then(request => {
  // This window was opened by a payment handler.
    request.respondWith(new Promise((accept, reject) => {
      // Do things.
      accept({method: "https://bobpay.xyz", data: {transactionId: "12345"}});
    }));
  });
}

[romandev]

@rsolomakhin,
The window what you mentioned is a global Window object(not WindowClient) to be opened by openWindow(), isn't it? If so, I like this. Your example looks similar to my suggestion. The only difference thing is that PaymentHandler object should be navigator instead of window in general.

[rsolomakhin]

@romandev: It's the global Window object, you're right. What's the reasoning for placing objects in navigator or window? This would be good for me to learn :-)

[romandev]

@rsolomakhin As far as I know, placing new APIs in Window object is no longer preferred. It can cause global namespace pollution and so name conflicts with JS library.
For example, if someone writes a JS library for payment and defines paymentHandler in Window object, then the browser's paymentHandler will not work.

[rsolomakhin]

Thank you for the explanation, @romandev. Let's use navigator.