W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > February 2023

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

From: Elad Alon via GitHub <sysbot+gh@w3.org>
Date: Thu, 16 Feb 2023 16:45:14 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-1433386204-1676565912-sysbot+gh@w3.org>
One lens to look at things through is - if a track is cloned, and the clones are transferred to two different iframes IF_A and IF_B, then:
* Those two iframes should be allowed to communicate to the captured content independently.
* Messages arriving from either should be clearly distinct in the receiver, even if IF_A and IF_B are same-origin.
* Neither IF_A nor IF_B should need to ask the original initiator of the session (who owns the singular CaptureController instance) to do anything more on their behalf.
  * And recall that the capturee could be navigated, which invalidates MessagePorts the original capturer might have produced on behalf of IF_A and IF_B. We don't want IF_A and IF_B to ask the initiator iframe to help each time this happens.
* Anything IF_A sends to the captured content, should not be delivered if the tab was navigated, changed, etc.
* If IF_A tries to send a message to a target that could not possibly receive it, that's an app-bug, and should result in an exception. (Timing issues notwithstanding.)

I believe my proposal addresses all of these, modulo that I need to change:
```webidl
partial interface CaptureController {
  MessagePort getMessagePort();
}
```

To:
```webidl
partial interface MediaStreamTrack {
  MessagePort getMessagePort();
}
```

(Or possibly make CaptureHandle an interface rather than a dictionary, and expose it there.)

-- 
GitHub Notification of comment by eladalon1983
Please view or discuss this issue at https://github.com/w3c/mediacapture-handle/issues/70#issuecomment-1433386204 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 16:45:16 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:20:00 UTC