- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Fri, 03 Feb 2023 08:43:35 +0000
- To: public-webrtc-logs@w3.org
> That way, apps have `targetOrigin` to deal with navigation in the capturee. Adding `targetOrigin` would allow to decorrelate the two APIs, but would allow capturer to span captures with '*'. There are a couple of questions in that area that would help driving the exact algorithms and API shapes: - If capturee did not opt-into CaptureHandle (but registered the event listener), should capturer be able to postMessage events? - 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? - 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? I think we have ways to build whatever we want there. I would tend to be strict in an initial version, and think about relaxing the rules progressively. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/mediacapture-handle/issues/70#issuecomment-1415366828 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 3 February 2023 08:43:36 UTC