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

Clarifying the behavior for consuming the user activation and delegated capability #37

Open EdgarChen opened 5 months ago

EdgarChen commented 5 months ago

For the APIs that would consume the user activation and delegated capability, Fullscreen and Payment, they have different behavior. If the global has both valid transient activation and delegated capability, the Payment API only consumes the transient activation, which means the Payment API is allowed to be called again because of the delegated capability is still valid; however Fullscreen API seems to consume both. Is this intentional?

vinhill commented 3 months ago

Currently for fullscreen, this spec consumes the delegated capability in step 10 when a promise was already returned in current step 7, so there could be race conditions. Maybe the monkey patch to fullscreen spec should be made more similar to the one for payment request spec?

michaelwasserman commented 2 months ago

Fixing any race by consuming signals before returning the promise is probably a good idea.

I think fullscreen was aiming for conservative usable security properties by consuming both signals. It might be okay to only consume one signal, in order to permit some other activation-consuming API call before (or after?) requesting fullscreen. I suggest thinking through use cases and security considerations before making the actual change.

vinhill commented 2 months ago

My impression is that when the monkey patch for Fullscreen was written, the intended behavior was for the capability only to be consumed if there is no transient activation.

Maybe I am missing something. With the current monkey patch for Fullscreen, both are consumed. The reason for this is that in step 6 of requestFullscreen, we consume the transient activation and then the following check is always false, right?

  1. If this’s relevant global object does not have transient activation, then clear the map entry DELEGATED_CAPABILITY_TIMESTAMPS["fullscreen"] in this’s relevant global object.

The monkey patch was added in commit https://github.com/WICG/capability-delegation/commit/bc6a169c45328540b8bf3d2470c474a7e3e90600. Here is the snapshot of the Fullscreen spec at that point, there the API did require but not consume transient activation. Back then, the delegated capability is only consumed if there is no transient activation.

So at that point, Fullscreen and Payment Requests had the same behavior. If there is transient activation, the delegated capability is not consumed. Maybe the monkey patch should have been updated once https://github.com/whatwg/fullscreen/commit/b3bab96cbf515585dcea70ebc9299b891f01efbe ensured requestFullscreen consumes the transient activation. #38 would restore this original behavior.

The question remains whether this is the right choice, though I think this is a separate issue.

mustaqahmed commented 2 months ago

Thanks @EdgarChen for the catch, and @vinhill for looking into a fix. Sorry I missed this discussion for a while.

Maybe I am missing something. With the current monkey patch for Fullscreen, both are consumed.

Yes both are consumed, and I agree with @michaelwasserman that "consuming both" was determined to be the best/safest behavior. However, the monkey-patch still needs attention...

... at that point ... the (Fullscreen) API did require but not consume transient activation.

That's correct: consumption of user activation at requestFullscreen() had compat implications so the spec changed relatively recently, and our monkey-patch here needs to be cleaned up accordingly. I think resetting both states in a single step would be the best but I will let @vinhill decide in the PR.

the Payment API is allowed to be called again because of the delegated capability is still valid; however Fullscreen API seems to consume both. Is this intentional?

"Yes and no"...let me explain: