search

WICG / capability-delegation

An API to allow developers transfer the ability to use restricted APIs to any target window in the frame tree.
Other
14 stars 7 forks source link

When does a delegated Payment Request capability expire? #8

Open mustaqahmed opened 3 years ago

mustaqahmed commented 3 years ago

The proposed monkey-patch to Payment Request spec needs to clarify when a delegated payment request capability expires.

The current text seems to suggest the same expiry time as transient user activation through the link from "expired" to HTML spec, but technically it doesn't really work because we are talking about a different timestamp field here.

@stephenmcgruer Before I change it, does "the same expiry time as transient user activation" make sense to Payment Request team? Or you want a different expiry?

stephenmcgruer commented 3 years ago

Can you help me understand why it doesn't really work? Is it because the last user activation is per-frame?

Using the same overall timespan as transient user activation makes sense to me initially, as we are still seeking to align user expectation between 'I clicked' and 'a thing happened', so extending the timespan seems wrong. But I will raise this on the PaymentRequest side as well.

mustaqahmed commented 3 years ago

Let me elaborate the diff:

  1. The "expiry" link is related to last activation timestamp in Window.
  2. Our monkey-patch talks about a different timestamp in Window: DELEGATED_CAPABILITY_TIMESTAMPS["payment"]. When this Window does not have any user activation, we want to check the time passed since delegation.

If the same expiry makes sense, I will replace the "expiry" with something like: "...transient activation duration has passed since the delegation timestamp".

annevk commented 3 years ago

We should probably serialize the last activation timestamp in the message so you cannot double the allowed time, right?

mustaqahmed commented 3 years ago

Regarding serializing the timestamp: I think keeping absolute timestamps isolated per process is better to avoid any cross-process time-diffs. But whether we can practically achieve that isolation depends on the possible time-doubling problem you are sensing. I am lost there, could you please elaborate?

annevk commented 3 years ago

That's a good point. Hmm. So say you have 5s today. It seems to me that if the parent messages near the end of the 5s, say at 4s, the child receiving the message will have another 5s as it starts from scratch and there's no shared concept of time. I.e., it has 9s in total. (Edit: to avoid the problem you mention you could serialize 4s so the child knows there's 5s - 4s left.)