Revisit: Sticky source

[eladalon1983]

The spec reads:

The source of a MediaStreamTrack MUST NOT change.

Why not? why should the user agent not exposes a "share this tab instead" button?

[eladalon1983]

Relevant: w3c/mediacapture-screen-share#223

[jan-ivar]

Why not?

• It might violate expectations of the app, which thinks it's still capturing itself.
• It might break region capture.

We've treated self-capture like a different beast so far, with different use cases. E.g.

1. record a meeting, or
2. join a call from a presentation.

why should the user agent not exposes a "share this tab instead" button?

• Because doing so seems to presume a specific use case (2 above), when all the abstract says is: "This document defines how a browser viewport can be used as the source of a media stream using getViewportMedia" which is all we know about what web developers will use this API for.
• Because getDisplayMedia is already just one in-content button away? What advantages does it offer?
• The security and privacy characteristics between the two APIs are quite different
• If we Revisit: Persisting permissions #10, users may have different security expectations when they initiate generic screen capture from an in-browser button.

That's my best attempt at answering the questions posed here. I'm not opposed to discussing new use cases and features, but would like to start with why, not why not.

[jan-ivar]

One "non-stick" use case might be a presenter wanting to follow a link in their presentation — which would need to open in a new tab for obvious reasons — and capture that somehow. But how that would work with UX I'm not sure.

[eladalon1983]

• It might violate expectations of the app, which thinks it's still capturing itself.

Does that mean you're ready to come around on w3c/mediacapture-screen-share#223? That will ensure that only applications that are able to handle the switch from self-capture to non-self-capture, would ever experience it.

• It might break region capture.

We'll need to clarify how Region Capture behaves in this environment, but I trust we'll find something that works just fine.

Because getDisplayMedia is already just one in-content button away? What advantages does it offer?

For a truly delightful experience, that keeps users on the Web platform, one extra click matters.

would like to start with why, not why not.

Makes sense. See my previous point in this very message, then. And your own message.

One "non-stick" use case might be a presenter wanting to follow a link in their presentation — which would need to open in a new tab for obvious reasons — and capture that somehow. But how that would work with UX I'm not sure.

Link opens new tab and focuses it, as usual. Share-this-tab-instead button presented on that button, as Chrome does with the extension API. User clicks that button - the capture devolves into a gDM-like capture wrt to capture. We can enshrine that in spec-language by ensuring that gVM-derived tracks have a distinct type, and all special power-features we give gVM-derived captures reference that new track type.