Intent to Ship: preferCurrentTab

324 views
Skip to first unread message

Elad Alon

unread,
Jul 22, 2021, 11:51:22 AM7/22/21
to blink-dev

Contact emails

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

Explainer

https://github.com/WICG/prefer-current-tab/blob/main/README.md

Specification

https://wicg.github.io/prefer-current-tab/

Summary

We introduce a dictionary member to MediaStreamConstraints called preferCurrentTab. It's a boolean defaulting to false. When getDisplayMedia() is called with preferCurrentTab=true, the browser should offer the current tab as the most prominent capture source.



Blink component

Blink

Search tags

getDisplayMedia, capture, getCurrentBrowsingContextMedia, preferCurrentTab, share, sharing

TAG review

https://github.com/w3ctag/design-reviews/issues/625

TAG review status

Pending

Risks



Interoperability and Compatibility



Gecko: Harmful (https://github.com/mozilla/standards-positions/issues/538)

It is worth mentioning that Firefox does not support tab-capture. The new dictionary member, preferCurrentTab, is therefore irrelevant for this browser, and will be silently ignored by Firefox with no adverse consequences.

WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2021-June/031886.html)

Apple did not complete our interaction on their mailing list and did not provide an official position.
It is worth mentioning that Safari does not support tab-capture. The new dictionary member, preferCurrentTab, is therefore irrelevant for this browser, and will be silently ignored by Safari with no adverse consequences.

Web developers: Strongly positive (https://github.com/WICG/proposals/issues/32)

Strong public support from Emil Ivov (Jitsi), Arnaud Budkiewicz (RingCentral) and Sergio Garcia Murillo (Millicast). Strong positive support from Google Meet, Google Slides and Google Docs.


Debuggability

This change does not merit any modifications to DevTools.



Is this feature fully tested by web-platform-tests?

No. getDisplayMedia is covered by WPT. The addition of preferCurrentTab is not feasible to test by WPT as it involves the UX the browser displays to the user. Support for automatic testing exists in the form of --auto-accept-this-tab-capture and --auto-reject-this-tab-capture.

Philip Jägenstedt

unread,
Jul 23, 2021, 8:58:45 AM7/23/21
to Elad Alon, Anne van Kesteren, Jan-Ivar Bruaroey, blink-dev
This is a non-trivial tradeoff, where another vendor (Mozilla) thinks this is a bad idea, while there are web developers expressing strong interest in this.

For me, the balance tilts in the direction of "ship it" for a few reasons.

First, the feature is really a UI hin with minimal web-exposed surface, a new dictionary member. The mere support of a dictionary member can be detected, but it takes extra work and isn't something I've ever seen content depend on. In other words, future site compat issues for other browsers that don't support this are very unlikely.

Second, we have multiple web developers working on different web properties saying that this would be valuable to them. It's much stronger web developer feedback than we usually have. (It was requested, so it's not accidental, but still.) I think this will also be used on some Google web property, but it has wider usefulness.


+Anne van Kesteren isn't sure about exposing the "tab" terminology. I agree that's novel in an unfortunate way, but the term (top-level) browsing-context isn't exposed to web developers now either. I think we could go along with any name here, given concrete suggestions.

+Jan-Ivar Bruaroey points to the requirements of Screen Capture: "The user agent MUST let the end-user choose which display surface to share out of all available choices every time, and MUST NOT use constraints to limit that choice. ... This prevents an application from influencing the selection of sources." The point of preferCurrentTab is indeed to influence the selection, but it doesn't use constraints to limit the selection. I don't think this is quite a willful violation, but still worth calling out, so I've filed this issue. (Note that a willful violation could be OK, I'm not saying that we should take the requirement of Screen Capture as gospel.)

The UI changes for this will also or perhaps have already gone through security review, I'm not making any evaluation of that.

LGTM1

--
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/CAMO6jDPdovQG_CCBNP1dNNfM-amYt_Cdk88iBbrsVVVcnvv2SQ%40mail.gmail.com.

Yoav Weiss

unread,
Jul 28, 2021, 9:26:26 AM7/28/21
to blink-dev, Philip Jägenstedt, blink-dev, Elad Alon, Anne van Kesteren, Jan-Ivar Bruaroey
LGTM2 for similar reasons to those Philip outlined.

On Friday, July 23, 2021 at 2:58:45 PM UTC+2 Philip Jägenstedt wrote:
This is a non-trivial tradeoff, where another vendor (Mozilla) thinks this is a bad idea, while there are web developers expressing strong interest in this.

For me, the balance tilts in the direction of "ship it" for a few reasons.

First, the feature is really a UI hin with minimal web-exposed surface, a new dictionary member. The mere support of a dictionary member can be detected, but it takes extra work and isn't something I've ever seen content depend on. In other words, future site compat issues for other browsers that don't support this are very unlikely.

Second, we have multiple web developers working on different web properties saying that this would be valuable to them. It's much stronger web developer feedback than we usually have. (It was requested, so it's not accidental, but still.) I think this will also be used on some Google web property, but it has wider usefulness.


+Anne van Kesteren isn't sure about exposing the "tab" terminology. I agree that's novel in an unfortunate way, but the term (top-level) browsing-context isn't exposed to web developers now either. I think we could go along with any name here, given concrete suggestions.

+Jan-Ivar Bruaroey points to the requirements of Screen Capture: "The user agent MUST let the end-user choose which display surface to share out of all available choices every time, and MUST NOT use constraints to limit that choice. ... This prevents an application from influencing the selection of sources." The point of preferCurrentTab is indeed to influence the selection, but it doesn't use constraints to limit the selection. I don't think this is quite a willful violation, but still worth calling out, so I've filed this issue. (Note that a willful violation could be OK, I'm not saying that we should take the requirement of Screen Capture as gospel.)

The UI changes for this will also or perhaps have already gone through security review, I'm not making any evaluation of that.

LGTM1

On Thu, Jul 22, 2021 at 5:51 PM 'Elad Alon' via blink-dev <blin...@chromium.org> wrote:
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Chris Harrelson

unread,
Jul 29, 2021, 3:29:16 PM7/29/21
to Yoav Weiss, blink-dev, Philip Jägenstedt, Elad Alon, Anne van Kesteren, Jan-Ivar Bruaroey
LGTM3

On Wed, Jul 28, 2021 at 6:26 AM Yoav Weiss <yoav...@chromium.org> wrote:
LGTM2 for similar reasons to those Philip outlined.

On Friday, July 23, 2021 at 2:58:45 PM UTC+2 Philip Jägenstedt wrote:
This is a non-trivial tradeoff, where another vendor (Mozilla) thinks this is a bad idea, while there are web developers expressing strong interest in this.

For me, the balance tilts in the direction of "ship it" for a few reasons.

First, the feature is really a UI hin with minimal web-exposed surface, a new dictionary member. The mere support of a dictionary member can be detected, but it takes extra work and isn't something I've ever seen content depend on. In other words, future site compat issues for other browsers that don't support this are very unlikely.

Second, we have multiple web developers working on different web properties saying that this would be valuable to them. It's much stronger web developer feedback than we usually have. (It was requested, so it's not accidental, but still.) I think this will also be used on some Google web property, but it has wider usefulness.


+Anne van Kesteren isn't sure about exposing the "tab" terminology. I agree that's novel in an unfortunate way, but the term (top-level) browsing-context isn't exposed to web developers now either. I think we could go along with any name here, given concrete suggestions.

+Jan-Ivar Bruaroey points to the requirements of Screen Capture: "The user agent MUST let the end-user choose which display surface to share out of all available choices every time, and MUST NOT use constraints to limit that choice. ... This prevents an application from influencing the selection of sources." The point of preferCurrentTab is indeed to influence the selection, but it doesn't use constraints to limit the selection. I don't think this is quite a willful violation, but still worth calling out, so I've filed this issue. (Note that a willful violation could be OK, I'm not saying that we should take the requirement of Screen Capture as gospel.)

The UI changes for this will also or perhaps have already gone through security review, I'm not making any evaluation of that.

LGTM1

On Thu, Jul 22, 2021 at 5:51 PM 'Elad Alon' via blink-dev <blin...@chromium.org> wrote:
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/CAMO6jDPdovQG_CCBNP1dNNfM-amYt_Cdk88iBbrsVVVcnvv2SQ%40mail.gmail.com.

--
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/e307f81a-b6c5-4fa4-a620-1c220749a9e9n%40chromium.org.

Elad Alon

unread,
Aug 10, 2021, 1:00:16 PM8/10/21
to blink-dev, Chris Harrelson, blink-dev, Philip Jägenstedt, Elad Alon, Anne van Kesteren, Jan-Ivar Bruaroey, yoav...@chromium.org
My apologies - I have neglected to mention that I request this to be a gapless transition. Please let me know if gapless-ness is approved, and/or if I need to do anything in addition in order to exercise it.

Chris Harrelson

unread,
Aug 16, 2021, 12:33:48 PM8/16/21
to Elad Alon, blink-dev, Philip Jägenstedt, Anne van Kesteren, Jan-Ivar Bruaroey, yoav...@chromium.org
LGTM to ship gapless. There is clear evidence of developer feedback on the Origin Trial leading to an improved final solution. (FYI you don't have to wait for 3 LGTMs for this part.)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9452c80f-b717-4885-8b55-470a54717823n%40chromium.org.
Reply all
Reply to author
Forward
0 new messages