Re: [mediacapture-main] What is the purpose of requiring a successful gUM call before enumerateDevices? (#1019)

> TL;DR: please read my answer in [web-platform-tests/interop#849 (comment)](https://github.com/web-platform-tests/interop/issues/849#issuecomment-2489546740).
> 
> > Certainly. The issue is that the requirement of gUM before enumerateDevices is incompatible with the way many Web applications have been written for a long time, which was to assume enumerateDevices results (among other things) are gated by permissions.
> 
> This isn't accurate. AFAIK only labels were gated on permission in the old spec.
> 

Yes, when I say enumerateDevices, I actually mean full enumerateDevices results containing labels, useful for an in-app device picker. 
VC applications did nothing with the results without labels, so when we changed those to include empty device IDs and with no more than one device per class, no VC applications broke, as they did nothing with the pre-permissions eD results.

> > Chrome tried to deploy gUM-before-enumerateDevices and had to roll it back due to incompatibility with existing applications, hence this issue.
> 
> It might be time to try again.
> 

Maybe it's time to change the spec instead. 

> What existing applications? There must be some misunderstanding as I don't follow this at all. Firefox supports persistent permission through the `✅ Remember this decision` and I assure you we didn't need to do any of this, whatever this is.
> 

In your own words, by 2023, this was **Most video conferencing sites**.

More specifically, you [literally said in 2023](https://github.com/w3c/mediacapture-main/issues/928#issue-1570623869):

_Most video conferencing sites offer a smoother user experience to returning Chrome users than to returning users in other browsers, because they basically ignore past non-persisted permissions entirely._

You even specifically mentioned whereby.com and indicated this code pattern:

```
const perm = await navigator.permissions.query({name: "camera"});
if (perm.state == "prompt") {
  nagTheUserAboutEnablingPermission();
}
```

This matches our observations as well, so we are in full agreement here.

Chrome certainly does not want to break the smoother user experience persistent permissions provide.

> > gUM-before-eD does not give any interoperability assurances over permissions-before-eD.
> 
> Of course it does. It's the predominant video conferencing model that works in all browsers. Most users don't have multiple cameras facing them. So websites ask for the default camera (or remember the previously one) and add a ⚙️ settings page for making changes.
> 
I meant conceptually. If Firefox switches to permissions-before-eD-with-labels it will be interoperable with Chrome and Safari.  Safari does not need to change anything because in their case permissions-before-eD-with-labels is the same as gUM-before-eD-with-labels.

> A website can prime for permission just once in Chrome, and assume device ennumeration on pageload works forevermore.

This is not accurate. The user can revoke permissions at any time, so permissions are not "forevermore" in Chrome.
Chrome is also experimenting with optional ephemeral permissions.
Therefore, applications cannot assume device eD on pageload will always return full results just because they got permission in the past.
What applications normally do is something similar to the code snippet you presented, which consists of a permission check to decide if a gUM call to request permissions is necessary or not.

> 
> > The reason Safari has not seen any compatibility problems due to gUM-before-eD is that their permissions are non-persistent, so applications know they have to call gUM.
> 
> Why has Firefox not seen any compatibility issues?
> 
No idea. But I'm a bit confused. 

[Just yesterday](https://github.com/web-platform-tests/interop/issues/849#issuecomment-2489546740) you said:

* Google Voice tripped over a related [change to permissions.query](https://bugzilla.mozilla.org/show_bug.cgi?id=1928216) in 132, for which an intervention is already in place, and they've promised a fix this week

* Slack huddles broke [before](https://bugzilla.mozilla.org/show_bug.cgi?id=1923194#c1) Firefox 132 shipped the measure. That website still requires firefox users to persist permission to microphone and then refresh the page_

In 2023 you said **Most video conferencing sites offer a smoother user experience to returning Chrome users**, which means a worse experience for Firefox users. Have you confirmed that most video conferencing sites now offer the smoother experience for Firefox users as well?

And you also said yesterday that there is a  "huge interoperability issue"?

But today you say Firefox has not seen any compatibility issues. If there are no such issues, then what is the "huge" part? 

Note also that any application written against the new spec will work fine with Chrome, as permissions-before-eD-labels is forwards-compatible with gUM-before-eD-labels. So Chrome is not preventing applications to move to the new spec, but it will not risk breaking compatibility to force such a move.

> > The problem is not the various permission models browsers implement and modify over time. The problem is that existing applications break with gUM-before-eD because they were written against the previous spec which stated permissions-before-eD.
> 
> I'd like to see these existing applications.
> 

Last year you said they were ** Most video conferencing sites** and you mentioned whereby.com.
That matches our observations.

Yesterday you said Slack huddles requires some workaround, which I presume is not necessary with Chrome and Safari (both of which implement permissions-before-eD-with-labels).

> The previous spec never specified permissions-before-eD, it specified permissions-before-eD-with-labels. You didn't need permission for eD. So any compatibility issue tied to permission seems homemade.

When I said permissions-before-eD I meant permissions-before-eD-with-labels, which is indeed what the old spec said,  is exactly what Chrome implements, and is what most applications are written to.  eD has always returned some result when called without permissions, with both the old and new specs.

I said permissions-before-eD just to make it shorter, since the pre-permissions results without labels were unused by VC applications but were useful for trackers in the old spec. The PING changes Chrome implemented kept the pre-permissions results useless for VC applications but also made them useless for trackers.


-- 
GitHub Notification of comment by guidou
Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/1019#issuecomment-2492404424 using your GitHub account


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

Received on Thursday, 21 November 2024 21:47:15 UTC