[w3c/payment-request] Reject promise if document becomes not fully active (#872)

There are multiple places in the spec today that requires any outstanding promises to be rejected if the document becomes not fully active, e.g. [show()], [retry()], [complete()].

[show()]: https://w3c.github.io/payment-request/#show-method
[retry()]: https://w3c.github.io/payment-request/#retry-method
[complete()]: https://w3c.github.io/payment-request/#complete-method

In Blink, this turns out to be difficult to implement because there is no hook to inform the `blink::PaymentRequest` object that its associated context is about to be destroy. The only hook is after the context is destroyed. This is too late, as any rejection queue then will not actually be executed. So from web developer's perspective, the promise gets into a limbo state, and never rejects nor resolves (http://crbug.com/941271).

Where this causes a real problem for web developers is when a `show()` promise is created from a `PaymentRequest` in one context (e.g. an iframe) and passed to a second context (e.g. a parent frame), and the first context navigates away. If the parent frame relies on the promise to resolve or reject to control its UI, it will hang.

@domenic you suggested the following on the [platform-architecture-dev thread] regarding this issue:

> make resolve/reject a no-op if the promise's relevant Realm's global object is a Window, and that Window's associated Document is not fully-active. And then, I guess, remove all uses of rejected promises to signal failures due to document inactivity, like the one opening this thread.

[platform-architecture-dev thread]: https://groups.google.com/a/chromium.org/d/msg/platform-architecture-dev/BszBZqcPcuk/SgTinm_KAQAJ

I'm not sure I fully follow what you mean. Can you clarify how this solves the problem?

In the end, I think there are two options out of this problem:

1. Change Payment Request API spec to not require outstanding promises be rejected when the document becomes not fully active. I'm not sure how to address the parent frame in limbo question.
2. Figure out a way to solve this problem in Blink. Based on a discussion I had with @aestes, WebKit doesn't have this problem because there is a hook just before the context is destroyed. So perhaps Blink can introduce a similar hook.

Any thoughts? @marcoscaceres @domenic @aestes @rsolomakhin @ianbjacobs 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-request/issues/872