Add capture handle feature #2904
Conversation
github-actions
bot
added
the
feature definition
| @@ -1,5 +1,4 @@ | |||
| draft_date: 2024-09-09 | |||
| name: Capture Handle - Bootstrapping Collaboration when Screensharing | |||
| name: Capture handle | |||
There was a problem hiding this comment.
Per https://github.com/web-platform-dx/web-features/blob/main/docs/guidelines.md we use sentence case for feature names, even though this sometimes looks funny. There's some discussion of it in #548.
| @@ -1,5 +1,4 @@ | |||
| draft_date: 2024-09-09 | |||
| name: Capture Handle - Bootstrapping Collaboration when Screensharing | |||
| name: Capture handle | |||
| description: TODO | |||
There was a problem hiding this comment.
Suggested description:
Expose custom metadata to Web applications that capture this application using getDisplayMedia().
There was a problem hiding this comment.
When it makes sense (I'm not versed enough in this feature to be sure), it's nice when the description name checks the entry point into the feature (i.e., the thing the developer types to "get" that feature). So maybe something like this?
The
navigator.mediaDevices.setCaptureHandleConfig()method exposes metadata about the application, if the application is captured by another usinggetDisplayMedia().
There was a problem hiding this comment.
The API requires using both navigator.mediaDevices.setCaptureHandleConfig() on the captured side and track.getCaptureHandle() on the capturing side. If we also want to mention getDisplayMedia(), that's a bit much IMHO.
How about:
The capture handle API allows you to share a custom handle (a string) from a web application being captured by
getDisplayMedia()to the capturing web application.
It seems like the communication channel is through changing the handle, but that would be a one-way channel from the captured to capturing side. I don't understand how https://w3c.github.io/mediacapture-handle/identity/#use-case-1 is achieved, which would require a channel in the other direction.
@eladalon1983 is there something useful the description could say about the communication channel that capture handle establishes? And is it one-way from captured to capturing?
There was a problem hiding this comment.
Yes, I like what you're thinking here. I like the idea about being more direct about what exactly is passing between the two applications:
The capture handle API shares a string from a screen-captured web application with the capturing application.
I think part of the problem here is that the spec introduces some new terminology (a "handle"), which is hard to accommodate in a short description like this—we're not really in a position to teach a developer a new term, so it's probably best if we avoid it outside the feature's name, which basically means avoiding the API's names in general.
There was a problem hiding this comment.
Either of your descriptions works for me.
The use case you're asking about, @foolip, can be explained more easily with examples:
- Assume meet.google.com captures docs.google.com. They can communicate using pre-existing means, but without Capture Handle, how would Meet know (i) that it's capturing docs.google.com rather than foo.bar.com, or (ii) which of many open docs.google.com tabs the user chose? Cue Capture Handle...
- Assume dual-use.com/capturer is capturing dual-use.com/capturee-827273. It is able to communicate with a BroadcastChannel, but what is the name of the BC where the captured tab is expecting to be contacted?
- Assume another capturer/capturee pair where the capturer advertises the address of some cloud service, and an unguessable token that it knows only a capturer would be able to read, which it will require as part of the custom handshake protocol.
That is, the use case assumes the collaborating capturer/capturee need some help for the handshake, but the communication itself will happen outside of Capture Handle.
No description provided.