Add Actions section from January WebRTC interim

[jan-ivar]

Fixes https://github.com/WICG/capture-handle/issues/6. @eladalon1983 @youennf PTAL.

I tried to stay faithful to the API shown at the January WebRTC interim slides, with the following deviations:

1. I added an oncaptureaction event handler instead of setCaptureActionsHandler, to avoid the w3c design principle: don't invent event-like. Since (unlike the Media WG who decided to overload listening with registration in Media Session) we defined a separate setSupportedCaptureActions — which would have been two methods to call back-to-back BTW: one to register actions, and another to set the handler for those actions (what happens if you do one and not the other?) — there's no overload happening of event listeners and the guidance says we should use them.
2. I added consumed transient activation to sendCaptureAction in line with intended use to limit abuse.
3. setSupportedCaptureActions cannot be called multiple times, in line with https://github.com/WICG/capture-handle/issues/11.
4. sendCaptureAction returns a promise. This was unclear in the slides since no WebIDL was shown. LMK if that was your intent.

[jan-ivar]

I see there's no PR Preview in this repo, so I've put up a preview here (does not include any of the other PRs). [Updated]

[jan-ivar]

And @eladalon1983 sorry it took me so long to provide this PR (I know we had discussed trying to get this integrated ahead of the call for adoption, which might have been smoother).

[eladalon1983]

Quick question before I do an in-depth review - is anybody planning to implement this within the next 2 years?

• Chromium (Google): No such plans at the moment.
• Chromium (Microsoft): Any plans you're aware of, @aboba?
• Firefox (Mozilla): Any plans to implement this, @jan-ivar?
• Safari (Apple): Any plans to implement this, @youennf?

I think it's important to figure out if this is worth our effort to continue debating. I propose that we find a minimum of one planned implementation before we proceed. It can be anyone, but there has to be someone. Because (i) our time is valuable, and (ii) unimplemented specifications have negative value.

(Edit: Modulo this comment. If we can all just agree on this without spending months debating it, it might be worth merging. But if it delays other APIs that do have implementations scheduled...)

[alvestrand]

FWIW, I disagree with tying "action" to a particular UI interaction on the sending side. If the receiving side offers a sequence of actions, the sending side should be free to compose its own UI that may bundle, sequence or pace those actions at will.

I also disagree with restricting the set of actions to only be set once and remain unchanged forever. This seems like an unwarranted restriction of the way that applications can offer their services.

I do agree that knowing an action has been delivered is useful; it is possible for the recipient of the action to decide whether or not to execute the result synchronously or by queueing a task that is executed later.

I'll repeat my point that this newly invented mechanism, while it can be extremely powerful and useful for loosely coupled applications, is still very early in its development cycle, and TAG review + input from people with experience in similar attempts (WebActions for instance) can still fundamentally alter the design.

It belongs in its own document.

[eladalon1983]

@alvestrand

I do agree that knowing an action has been delivered is useful; it is possible for the recipient of the action to decide whether or not to execute the result synchronously or by queueing a task that is executed later.

"Has been delivered" seems tricky. It requires synchronization with the recipient's event loop, to ensure that it still supports the to-be-delivered action by the time it is delivered. (Also - navigation.) Knowing when the capturee's event loop got around to handling a specific event sounds like it should be undertaken with care. I'd prefer to avoid this in the initial version and revisit later.

[alvestrand]

This is OBE and will be closed when #28 merges.

[eladalon1983]

This is OBE and will be closed when #28 merges.

Order of the British Empire? Why I never... At any rate - shall this be closed now?

[dontcallmedom]

28 got merged, closing

(OBE stands here for "overtaken by events", no knighthood involved :)