[mediacapture-screen-share] Tab-Focus One-Way Hand-Off (Capturer -> Captured) (#165)

eladalon1983 has just created a new issue for https://github.com/w3c/mediacapture-screen-share:

== Tab-Focus One-Way Hand-Off (Capturer -> Captured) ==
Consider a capturing application in one tab, captured application in another tab. When the capture starts, should tab-focus switch to the captured app, or should it stay in the capturing app? Until now this topic was not address by the standard, meaning it was left to the user agent to decide.

I think that the capturing application is better positioned to make that decision. Furthermore, I think there are two scenarios:
1. Capturers that never/always want to hand-off focus to the captured application. (Constraints to gDM would suffice.)
2. Capturers that have a different preference depending on what is captured. (Constraints would not be useful.)

I will concentrate on the second type of apps, because the solution it requires is also usable by the first class of apps.

### Example Use Case
Assume a VC application is the capturer.

If the captured application is a known collaborating application, the two applications can [establish out-of-band communication upon capture-start](https://github.com/w3c/mediacapture-screen-share/issues/159#issuecomment-818041490). It then becomes unnecessary to switch focus to the captured tab, since user controls can immediately be displayed in the VC application, allowing the user to remotely control the captured application.

However, if a non-collaborating application is captured - maybe a non-collaborating productivity suite - then the VC application might decide the best thing for the user is for tab-focus to immediately shift to the captured app. That way, the user can immediately start flipping through the presentation, edit the shared document, or do whatever else it is the user wants with the captured app.

### Suggested Solution
1. Assume the user agent does **not** hand off tab-focus when capture starts. (For simplicity. Needs **not** be specified.)
2. Define an API for handing off tab-focus from capturing application to captured application. Call it `tabFocusHandOff()`.

The capturing application can call `tabFocusHandOff` never/always/conditionally as it sees fit.
If conditionally, it can use the addition of [this PR](https://github.com/w3c/mediacapture-screen-share/pull/163) in order to make an informed decision.

### Pseudo-code
`void tabFocusHandOff(MediaStreamTrack mst);`
* If the application calling this API is not in the currently active tab, throw an error.
* If (mst.kind != "video"), throw an error.
* If (mst.getSettings().displaySurface != "browser"), throw an error.
* If mst is not "live", throw an error. (TBD: What if it is muted or not enabled?)
* If any abuse-preventing condition does not hold (see below), throw an error.
* Switch focus to the captured tab.

### Preventing Abuse
* The first line of defense here is that this only works one-way from capturer to captured application.
* Block calls that involve tabs entangled in a cyclic capture (e.g. A captures B while B captures A).
* Worth considering if we want to limit `tabFocusHandOff` to a single activation.
* Worth considering if we want to limit `tabFocusHandOff` to being called only within N milliseconds of the capture starting. (Or some other user-gesture / transient-activation tie-in.)
* Worth considering mandating that user input (mouse-clicks, etc.) be ignored for a given duration immediately after the focus changes.

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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 12 April 2021 19:30:51 UTC