Re: [mediacapture-handle] Expose a MessagePort using Capture Handle (#70)

> It should be required for capturer to know the captured origin to do postMessage.

Code that cares about the target's origin would look like this:

```js
if (track.getCaptureHandle().origin == myExpectedOrigin) {
  // postMessage() and so on.
}
```

The comparison fails for any "real" value of `myExpectedOrigin` if `.origin` is `undefined`. I don't understand what we'd gain from forcing the origin to be exposed, let along why it's _important_. Could you please explain?

> The fact capture handle is exposed at the track but not at controller level is something we should think of.

Maybe we could expose on the controller **in addition** to the track. But I think it's important to retain the API surface that's already on the track, because tracks are transferrable, and CaptureControllers are not. A receiver of a transferred track might be interested in learning that the track represents a capture of a tab tuned to a specific origin. It would NOT be possible to learn that if exposure is only on the controller, because message passing is async and the information might be out of date by the time the controller's iframe responds (e.g. navigation).

> `// Should it be named DisplayCaptureController?`

1. I prefer shorter names.
2. I think it produces potential for confusion - someone could mistake it as only controlling screens.
3. Renaming would break existing Web apps that already make use of this interface. What gains offset this cost?

> ```webidl
> partial interface CaptureController {
>   ...
>   undefined postMessage(...);
>   ...
> }

I think it's undesirable to expose postMessage on the controller, again because the track is transferable and the controller is not. If an iframe ORIGINAL_CAPTURER initiates the capture and the transfers the track to iframe IFRAME_X, why should IFRAME_X need to keep on bothering ORIGINAL_CAPTURER with requests to relay messages to the capturee on its behalf?

In fact, I now think I've not gone far enough to begin with. I think we should expose the port-getter on the track itself or on the capture handle. Even if we were to make the controller transferrable, it would not be enough, because tracks are cloneable, and clones might be posted to different targets.

> but would allow capturer to span captures with '*'

When the top-level is navigated, the new capturee needs to register a new listener, and it should only get messages sent expressly to it. My proposal ensures that, by killing off the old port and forcing the capturer to set up a new one.

> If capturee did not opt-into CaptureHandle (but registered the event listener), should capturer be able to postMessage events?

No, it should error. Sending messages to someone that cannot receive them is an app-error, and the app should be made aware, so that its developers may fix the issue. I believe my proposal addresses that through `supportsMessagePort`.

> If capturer and capturee relationship is fully broken (capture stopped say), what should be the behavior? Should postMessage continue to work? Should it silently fail? Should it fire to the new capturee if same origin?

It should stop loudly. I believe my proposal addresses that through `NewCapturerEvent{type: "stopped"}` and the killing off of the port.

> If capturer and capturee relationship is paused (user changed capturee surface), what should be the behavior? Should postMessage continue to work? Should it silently fail? Should it fire to the new capturee if same origin?

That's a new issue. I think it's orthogonal to other design decisions facing as atm. If you agree (do you?), I propose tackling it after we settle other issues.

-- 
GitHub Notification of comment by eladalon1983
Please view or discuss this issue at https://github.com/w3c/mediacapture-handle/issues/70#issuecomment-1433291641 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 16 February 2023 15:42:34 UTC