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

> > If the same-origin use case turns out to be non-existent, then it seems to me that we don't have a real world use case that would depend on the current spec behavior.
> 
> In Firefox at least, this causes the payment sheet closes if the iframe or top-level browsing context that created the request navigates. That’s obviously quite important for us, otherwise the sheet would continue to show if the underlying document is navigated to a new origin.

I'm thinking we can just remove step 3 from the "If document stops being fully active..." section, leaving the following:
```
If document stops being fully active while the user interface is being shown, or no longer is by the time this step is reached, then: 

1. Close down the user interface.
2. Set request's payment-relevant browsing context's payment request is showing boolean to false.
```
This way Firefox can still close the payment sheet. In fact, Chromium needs this as well, the only thing we can't do is reject the promise because the event loop is already stopped.

> Without changing the tests, we could make the argument to the W3C Director that this is interoperable, because at least the payment sheet closes when the creator context navigates (even if promises are left in a pending state, which is not very clean but  ).

What about changing the test such that instead of waiting for the promise to reject, the test will create another payment request in the main frame? We can use whether the main frame request succeeds in calling show() to check if the payment sheet triggered from the iframe is dismissed as expected.

> @domenic, do you have any concerns wrt this?

Copying over what @demenic said on the [chromium-dev] thread:

> My message was based on the premise that the spec as-is is broken. It's asking to do something that's basically impossible (*), because you can't reject a promise in an inactive document (since the event loop, which is responsible for promise rejections, does not run).
>
> So my suggestion was that specs should: (1) stop doing impossible things purposefully, i.e. remove the reject-after-inactive requirements; (2) also get a blanket update so that even if they try to do impossible things accidentally, nothing bad happens.
>
> To expand on (2): you can imagine that there are tons of conditions throughout specs like "If the fetch fails, then reject the promise". To be more correct, we would have to edit every spec to say "If the fetch fails, and the promise's global object's associated Document is active, then reject the promise." This is burdensome to do, and even more burdensome to remember to do, for all future spec updates. Instead we should just make it automatic that "If the fetch fails, then reject the promise" implicitly does nothing when it doesn't work.
>
> (*) 'basically' impossible: I am still pretty sure a document could become active again after transitioning out of bfcache...

[chromium-dev]: https://groups.google.com/a/chromium.org/d/msg/chromium-dev/xltDJUtxrmQ/F0zpSAuGDAAJ


I think this is consistent with my suggestion above.



-- 
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#issuecomment-512026722