If both are available, consume delegated fullscreen capability and transient activation in one step

[vinhill]

In reference to #37, I suggest to make the monkey patch to the Fullscreen API more similar to the one for the Payment Request API in one way:

• Do not consume both transient activation and delegated capability, rather consume only the former if available. This is analogous to the behavior for Payment Request API.
• Consume the delegated capability at the same time where the transient activation would be consumed and not in parallel with returning a promise. This avoids race conditions.

[vinhill]

I'm not aware of there being a test for this. If this PR is welcome, I can create a test to ensure fullscreen can be requested twice if both transient activation and delegated capability are available.

[michaelwasserman]

Thanks for the PR!

• Do not consume both transient activation and delegated capability, rather consume only the later if available

The updated text actually consumes user activation, and leaves the delegated capability signal active, when both are available. I'm not entirely sure which is preferable, but the Payment Request change does also seem to prefer consuming user activation. Consider updating the PR title and first comments description to match the proposed algorithm changes.

I also left a comment on #37, it might help to think through use cases and security considerations before changing the consumption of both signals to one or the other.

[mustaqahmed]

I finally replied in #37, sorry for taking so long. May I ask for an update here based on that?

[vinhill]

@mustaqahmed thanks for your reply, resetting both transient activation and delegated capability in one step seems good to me. I updated the PR.

[zcorpan]

We're planning to implement this change in Gecko. @mustaqahmed PTAL

[mustaqahmed]

Awesome, thanks for the update. Please give me a few days to catch up with the discussion in #37 and complete this review.