Intent to Extend Experiment: getCurrentBrowsingContextMedia()

Elad Alon

unread,

Jul 2, 2021, 5:38:54 AM7/2/21

to blink-dev

Contact emails

elad...@chromium.org, h...@chromium.org, gui...@chromium.org, hu...@chromium.org

Explainer Repeated from I2E

bit.ly/3nnH9yL (We're extending the old version; do not follow the link to the new version.)

Specification Repeated from I2E

https://github.com/w3c/mediacapture-screen-share/pull/148

However, this feature is under active discussion in the WebRTC WG. The main point of contention is the security measures necessary to be adopted to unlock a confirmation-only flow. We intend to ship an explicit-selection flow first, which will be the fallback behavior for applications that do not fulfil the security requirements for the confirmation-only flow. Once the security measures of the confirmation-only flow are decided, specified and implemented, we will ship the confirmation-only flow, too.

Summary Repeated from I2E

We introduce a new API - navigator.mediaDevices.getCurrentBrowsingContextMedia(). This API allows capturing a MediaStream with the current tab's video (and potentially audio), similar to getDisplayMedia(). Unlike getDisplayMedia(), calling this new function will (eventually) present the user with a simple accept/reject dialog. If the user accepts, the current tab will be captured. In all other ways, getCurrentBrowsingContextMedia() will be identical to getDisplayMedia().

However, this feature is under active discussion in the WebRTC WG. The main point of contention is the security measures necessary to be adopted to unlock a confirmation-only flow. We intend to ship an explicit-selection flow first, which will be the fallback behavior for applications that do not fulfil the security requirements for the confirmation-only flow. Once the security measures of the confirmation-only flow are decided, specified and implemented, we will ship the confirmation-only flow, too.

TAG review status Repeated from I2E

Pending

Risks

Interoperability and Compatibility Updated from I2E

Gecko: Positive signals for the feature's general direction (current-tab-capture) but strong disagreement over the necessary security requirements. This led to a split of this feature into two - (a) getViewportMedia (still being debated), over which there is general agreement, and (b) prefer-current-tab, to which Mozilla objects.

WebKit: No signal

Web developers: Positive signals.

Goals for experimentation Repeated from I2E

Prove usefulness of the feature to early adopters (e.g. Google Workspace).

Receive feedback over changes necessary to the feature.

Pave way to additional features currently planned for development based on this feature. (E.g. region-capture.)

Reason this experiment is being extended New Field

Original intent-to-experiment

Google Docs and Slides were very happy with the new API and were using it extensively. However, while they had advanced notice, other web developers have not had sufficient time to hear about this experiment and set up code to use it. We intend to rectify this by posting a blog entry to web.dev and conducting more extensive developer outreach.

Experimental timeline New Field

Origin trial started at m90 and was scheduled to end with m92. For the reasons listed above, I am asking to extend. Since the new Chrome release timeline is a lot shorter, I am asking for this to be extended by 3 releases, so up to and including m95.

Ongoing technical constraints Repeated from I2E

As mentioned above at more length, we are currently only experimenting over the explicit-selection flow. The confirmation-only flow will be developed at a later time.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Repeated from I2E

No; only desktop platforms for the time being.

Is this feature fully tested by web-platform-tests? Repeated from I2E

No

Link to entry on the Chrome Platform Status Repeated from I2E

https://www.chromestatus.com/feature/5045313003847680

Yoav Weiss

unread,

Jul 8, 2021, 5:54:50 AM7/8/21

to blink-dev, Elad Alon

On Friday, July 2, 2021 at 11:38:54 AM UTC+2 Elad Alon wrote:

Contact emails
elad...@chromium.org, h...@chromium.org, gui...@chromium.org, hu...@chromium.org

Explainer Repeated from I2E
bit.ly/3nnH9yL (We're extending the old version; do not follow the link to the new version.)

Specification Repeated from I2E
https://github.com/w3c/mediacapture-screen-share/pull/148
However, this feature is under active discussion in the WebRTC WG. The main point of contention is the security measures necessary to be adopted to unlock a confirmation-only flow. We intend to ship an explicit-selection flow first, which will be the fallback behavior for applications that do not fulfil the security requirements for the confirmation-only flow. Once the security measures of the confirmation-only flow are decided, specified and implemented, we will ship the confirmation-only flow, too.

Summary Repeated from I2E
We introduce a new API - navigator.mediaDevices.getCurrentBrowsingContextMedia(). This API allows capturing a MediaStream with the current tab's video (and potentially audio), similar to getDisplayMedia(). Unlike getDisplayMedia(), calling this new function will (eventually) present the user with a simple accept/reject dialog. If the user accepts, the current tab will be captured. In all other ways, getCurrentBrowsingContextMedia() will be identical to getDisplayMedia().

However, this feature is under active discussion in the WebRTC WG. The main point of contention is the security measures necessary to be adopted to unlock a confirmation-only flow. We intend to ship an explicit-selection flow first, which will be the fallback behavior for applications that do not fulfil the security requirements for the confirmation-only flow. Once the security measures of the confirmation-only flow are decided, specified and implemented, we will ship the confirmation-only flow, too.

Blink component Repeated from I2E
Blink>GetDisplayMedia

Search tags Repeated from I2E
getDisplayMedia, capture, getCurrentBrowsingContextMedia, share, sharing

TAG review Updated from I2E
TAG review

TAG review status Repeated from I2E
Pending

Risks

Interoperability and Compatibility Updated from I2E

Gecko: Positive signals for the feature's general direction (current-tab-capture) but strong disagreement over the necessary security requirements. This led to a split of this feature into two - (a) getViewportMedia (still being debated), over which there is general agreement, and (b) prefer-current-tab, to which Mozilla objects.

WebKit: No signal

Any links?

Web developers: Positive signals.

Link?

Goals for experimentation Repeated from I2E
Prove usefulness of the feature to early adopters (e.g. Google Workspace).
Receive feedback over changes necessary to the feature.
Pave way to additional features currently planned for development based on this feature. (E.g. region-capture.)

Reason this experiment is being extended New Field
Original intent-to-experiment
Google Docs and Slides were very happy with the new API and were using it extensively. However, while they had advanced notice, other web developers have not had sufficient time to hear about this experiment and set up code to use it. We intend to rectify this by posting a blog entry to web.dev and conducting more extensive developer outreach.

Any other partners lined up to use this and/or excited by this API? A blog post would be great, but may not be sufficient on its own to get folks to experiment.

Elad Alon

unread,

Jul 8, 2021, 6:23:43 AM7/8/21

to blink-dev, yoav...@chromium.org, Elad Alon

WebKit "no signal" based on this unterminated thread on their mailing list. I have asked for the formal position, and they responded with questions but not official position was formalized by them after I gave my answers.

Web-developer positive signals I have from out-of-band discussions over VC with some partners. I have encouraged them to state their position publicly, hope they do so in the future.

Yoav Weiss

unread,

Jul 8, 2021, 7:50:31 AM7/8/21

to Elad Alon, blink-dev

On Thu, Jul 8, 2021 at 12:23 PM Elad Alon <elad...@google.com> wrote:

WebKit "no signal" based on this unterminated thread on their mailing list. I have asked for the formal position, and they responded with questions but not official position was formalized by them after I gave my answers.

Web-developer positive signals I have from out-of-band discussions over VC with some partners. I have encouraged them to state their position publicly, hope they do so in the future.

Are those partners likely to participate in the OT?

Elad Alon

unread,

Jul 8, 2021, 7:58:04 AM7/8/21

to Yoav Weiss, blink-dev

I think they might.

Yoav Weiss

unread,

Jul 12, 2021, 3:44:20 PM7/12/21

to Elad Alon, blink-dev

LGTM to continue experimenting M90-M95

Žanetta Berķe

unread,

Jul 12, 2021, 3:55:20 PM7/12/21

to Yoav Weiss, blink-dev, Elad Alon

SmS

чт, 8 июл. 2021 г., 12:54 Yoav Weiss <yoav...@chromium.org>:

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/620210e2-8202-4718-8b97-5b6beb862ebfn%40chromium.org.

Reply all

Reply to author

Forward