preferCurrentTab

[eladalon1983]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: preferCurrentTab
• Specification or proposal URL: https://eladalon1983.github.io/prefer-current-tab/
• Caniuse.com URL (optional):
• Bugzilla URL (optional):
• Mozillians who can provide input (optional):

Other information

We've previously discussed this as getCurrentBrowsingContextMedia. Chrome has conducted an Origin Trial of the API using this shape (a method). We're intending to ship this as a dictionary member called preferCurrentTab.

[annevk]

What happens if the document in the tab is navigated?

It's not entirely clear to me we should expose "tab" as a term as it doesn't really work across all devices.

[annevk]

cc @jan-ivar

[eladalon1983]

If you navigate the capturing document/frame or one of its parents, capturing stops, as it would with getDisplayMedia.
If you navigate an unrelated child frame, capturing proceeds uninterrupted, as it would with getDisplayMedia.

It's not entirely clear to me we should expose "tab" as a term as it doesn't really work across all devices.

I am open for suggestions. If there's a succinct term for tab-or-closest-equivalent-on-mobile I'd love to use it; if there isn't, maybe it would be good to mint such a term. (IMHO preferCurrentBrowserDisplaySurface would be as unpopular a name as getCurrentBrowsingContextMedia. I'd rather keep it short)

[annevk]

To me that sounds like (top-level) viewport capture, not tab capture.

[eladalon1983]

In Chrome, the user-facing UX distinguishes three types of surfaces - screen, window and tab.
This new dictionary member aims to say - of the category of of surfaces which Chrome refers to as "tabs," the app prefers the current one.
If there is a name that's more appropriate, I am happy to discuss and potentially adopt it.

Independently of naming, Mozilla's position about this API in its previous incarnations has been negative (@jan-ivar has more context). I would be happy if it has changed, but I have no reason to suspect so. This is a formal request for the formal position.

[jan-ivar]

We're intending to ship this as a dictionary member called preferCurrentTab.

Is there an "Intent to Ship"? This does not appear to be a standards-track document.

I doubt Mozilla would implement this since it directly defeats and contradicts the security requirements of getDisplayMedia: "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"

Safer alternatives have been proposed, such as w3c/mediacapture-screen-share-extensions#9 which appears to have some support.

[eladalon1983]

The spec now lives on https://wicg.github.io/prefer-current-tab/. An Intent-to-Ship is upcoming. I am contacting you for your formal position as your formal position is a required field in the Intent-to-Ship. I expect that your position is negative, as per our earlier discussions indeed. I just need it formally. :-)

…

On Tue, Jun 22, 2021 at 3:48 AM Jan-Ivar Bruaroey ***@***.***> wrote: We're intending to ship this as a dictionary member called preferCurrentTab. Is there an "Intent to Ship"? This does not appear to be a standards-track document. I doubt Mozilla would implement this since it directly defeats and contradicts the security requirements of getDisplayMedia <https://w3c.github.io/mediacapture-screen-share/#dom-mediadevices-getdisplaymedia>: *"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"* Safer alternatives have been proposed, such as w3c/mediacapture-screen-share-extensions#9 <w3c/mediacapture-screen-share-extensions#9> which appears to have some support <https://twitter.com/RickByers/status/1404270879815745537>. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#538 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFIX22DZ3I7ZOT5Q5APBFDLTT7TVHANCNFSM46LZ5T2Q> .

[jan-ivar]

Sure, I would consider this harmful.