W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2022

[mediacapture-screen-share] Allow applications to opt-out of source-change (#223)

From: Elad Alon via GitHub <sysbot+gh@w3.org>
Date: Fri, 29 Apr 2022 15:23:09 +0000
To: public-webrtc@w3.org
Message-ID: <issues.opened-1221077189-1651245787-sysbot+gh@w3.org>
eladalon1983 has just created a new issue for https://github.com/w3c/mediacapture-screen-share:

== Allow applications to opt-out of source-change ==
### Problem statement
User who share one display surface often wish to make a **quick** transition to sharing another.

### Example 1
* The user prepares to deliver a presentation over VC.
* Before the call starts, the user sets up N tabs, each pre-navigated to a specific location, relevant application already set up. Note that some setup might be involved here. Maybe the user has set up some of these applications to a very specific state.
* The user begins call over a VC application.
* The user interacts with VC application, then with browser's dialog, to share the first tab.
* The user interacts with the first shared tab.
* The user wishes to switch to second tab.
* **What now?** The user has to reactivate the VC tab, re-engage screensharing, etc. **Very suboptimal!**

### Example 2
Same thing, but now that user is recording a lecture using something like Loom.

### Chrome's current solution
Chrome currently offers an extension API that presents a `Share this tab instead` button.

![Screenshot 2022-04-29 at 17 12 45](https://user-images.githubusercontent.com/22117736/165973324-4f53957c-4e8f-455b-ac1d-6dd236048215.png)

The user just hops to the next tab, presses the button, and continues the presentation.
0 beats skipped.
This solution is implementable by user agents without any API changes. **In theory.**

### But...
Not all applications are able to smoothly deal with a change of source. What about applications that rely on tight-coupling with the captured tab? A change of source breaks that connection. The capturing application can detect that using Capture Handle, but what can it do then? Inform the user why some features suddenly disappear?!

The user is **not interested** in excuses.
The user is **not interested** in the distinction between application and browser.
The user protests: **"If I was not supposed to press that button - why did you ever show it to me?"**

### Solution
The browser should not guess whether a share-this-tab-instead button, **or any other UA-specific mechanism for switching sources**, should be presented to the user. The application should.

So how about:
enum SystemAudioPreferenceEnum {

dictionary DisplayMediaStreamConstraints {
  SourceChangePreferenceEnum sourceChange;

### Is this safe?
With the right kind of wording, this is an opt out mechanism. I would NOT give the application control over changing the source. It would not even mean that the user agent would be forced to give the user the option to change the source. Rather, this gives browsers that support source-change to let applications opt-out of source-change.

Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/223 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 29 April 2022 15:23:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 29 April 2022 15:23:11 UTC