Need to specify behavior for Clients.openWindow

[rsolomakhin]

The spec currently raises an issue that a ServiceWorker should be able to open a window for the payment app webpage, so the user can interact with the payment app to complete the transaction. Let's write the spec language for this, so we can have interoperable implementations.

[tommythorsen]

@ianbjacobs: I think the comment that you added to the specification along with the link to this issue, is spot on. There are some open questions here that we should answer, and while it's not great to have the specification dictating how the UI should be implemented, I think it needs to say something more than just leaving everything up to the User Agent implementors.

My impression, after having talked with potential Payment App implementors, is that just calling clients.openWindow() feels a bit uncertain. The current implementations of clients.openWindow() in various browsers are not all suitable for showing Payment Apps. In Chromium for Android, for instance, this function results in opening a new tab. This kind of behavior would make the Payment App somewhat disconnected from the Payment Request dialog which would still be sitting and waiting in the original tab. The user could jump back and mess around with the tab that has the payment request dialog (and even close it altogether), and there's a lot of potential for confusion.

It seems necessary for User Agents, then, to supply a specialized implementation of clients.openWindow() for use by Payment Apps. Do we think that User Agent implementors will do this, even if it is not required by the specification? Even if we think that they will, it may be hard for Payment App implementors, who would like to have a certain level of guaranteed user-friendliness, to be able to trust that all implementations of clients.openWindow() will be satisfactory.

One potential outcome of this, could be that Payment App implementors, in an attempt to keep things under control, start filtering clients on User Agent Strings, only allowing registration and payments by User Agents that have been tested and proven to have an acceptable implementation of clients.openWindow(). User Agent String filtering by web sites is typically a very negative thing for smaller browsers such as Opera, and we'd like to make sure this doesn't happen.

So, is it possible for us to say something about the expectations of the implementation of clients.openWindow() that does not inhibit the User Agent implementors' choices in UI implementation, but still gives some basic assurances to the Payment App implementors?

[ianbjacobs]

Hi Tommy,

Let's discuss this at tomorrow's call:
https://lists.w3.org/Archives/Public/public-payments-wg/2017Jan/0006.html

Ian

[jenan-stripe]

still gives some basic assurances to the Payment App implementors?

I'll be on a plane tomorrow and can't make the call, but I am very much in favor of this!

[ianbjacobs]

At the 4 January call, Rouslan took an action to find out to what extent discussion of progressive web apps here could be useful:
https://www.w3.org/2017/01/04-apps-minutes.html#item05

Ian

[tommythorsen]

I see this issue is on the agenda for today's meeting. I'm not sure if Rouslan's efforts have been fruitful, but I just want to make sure we consider the option of resurrecting the PaymentWindow API that existed in the very first versions of the service worker payment apps text. Although there's added spec complexity in defining this API, which necessarily needs to copy a lot of the spec text from clients.openWindow(), I believe it does address very well the current uncertainty w.r.t. the suitability of clients.openWindow().

It can also help us solve another problem which we haven't yet discussed, but which I have had feedback about from a payment app implementor; namely the difficulty of closing a window opened by clients.openWindow(). See this and this stackoverflow post for more information. Basically, if a window has been opened by a serviceworker using clients.openWindow(), it may be tricky to close it again programmatically. If we have a specialized API for opening and closing payment windows, we can sidestep all of these potential problems.

[jenan-stripe]

As a follow up to this morning's call: a new tab is not going to be sufficient for payment app implementors. I think the spec needs to be strong enough on this point to let payment apps feel confident that they can build an "Apple Pay on the Web"-like interaction (at the very least). That is, it needs to be capable of overlaying the current page.

On mobile, new tabs have historically had some issues with certain UAs (e.g. SFSafariViewController does not work with tabs). Payment apps will want to be full frame and ideally be capable of building a partial-height UI with the host page visible in the background.

On desktop, new tabs are a jarring user experience and force payment apps to render a full screen of UI even if all they want a small frame.

As a payment app implementor, here is what I would need to feel comfortable building against this spec:

• same window/tab
• full frame or partial frame at my choosing, regardless of zoom/scroll position
• indication of the origin of the payment app to the user

Ex desktop:

Ex mobile:

[ianbjacobs]

Thanks, Jenan.

I updated the spec after today's call:
https://w3c.github.io/webpayments-payment-apps-api/#payment-app-display

The new text in 10.4 says:

"To support scenarios that involve visual display and user interaction, user agents MUST allow payment apps to call the clients.openWindow() method defined in [SERVICE-WORKERS]. Because user agents can determine from event type that the window is part of a payment flow, the user agent SHOULD render the window in a way that is consistent with the flow and not confusing to the user. For example, we recommend that the payment app not be opened in a new browser tab, as this is too dissociated from the checkout context."

How does that sound? Would you suggest we amend it to mention "full or partial frame" as a sort of good practice hint?

Regarding origin: We do not currently have a requirement that the payment app must display its own origin to hte user. Do you think that should be a requirement or strong suggestion?

Thanks!

[ianbjacobs]

Some notes:

• I plan to add to the spec a recommendation that browsers display app origin. Rouslan indicated he thought browsers would do this (anyway) so ok to include a recommendation.
• Although the spec text has been updated, issue 97 also addresses this topic, and there's
  another approach that's being discussed. That issue might lead to more changes in the text.
  Different approaches to opening windows #97

Ian

[jenan-stripe]

👍 Excited about the updates. Strong rec for displaying origin sounds reasonable.

[marcoscaceres]

This is a possible duplicate of #97

[ianbjacobs]

Update: Marcos and Tommy have agreed to work together on a proposal for a new openClientWindow method.

[ianbjacobs]

Duplication of 97 so closing
#97