Web: audioDevicesUpdated/videoDevicesUpdated events are inconsistent between Desktop Chrome and Mobile Chrome

[eliaspuurunen]

Describe the bug
After permissions are granted by the user (call deviceManager.askDevicePermission), the desktop version of Chrome fires the audioDevicesUpdated and videoDevicesUpdated events. These events are not called when accessed from Mobile Chrome.

Expected behavior
Expected behavior is unclear from documentation. When should these events fire? Is a change defined as when a device is attached or when Azure Communication Services SDK learns of the device?

Desktop (please complete the following information):

• OS: Windows 10
• Browser Chrome
• Version 85.0.4183.121 (64-bit)

Smartphone (please complete the following information):

• Device: LG V30
• OS: Android 9
• Browser Chrome
• Version 85.0.4183.127

[RinaRish]

Hi @eliaspuurunen! Thanks for reporting the issue, we are looking into it

[mehrandvd]

We have the same problem here:

Desktop:

• OS: Windows 10
• Chrome: 87.0.4280.88 (Official Build) (64-bit)

Mobile:

• Xiaomi: Redmi 8A
• Chrome: 86.0.4240.198

And it's really annoying...

[chriswhilar]

Hi @eliaspuurunen,

I have tested this using the latest sdk on the following platforms, and this is the following behavior. I will document on our docs:
Chrome / Android / Galaxy Tab S7+
Chrome / Windows / Surface book 3
Edge chromium / Windows / Surface book 3
Safari / iOS / iPhone 12 Pro Max
Chrome / MacOs / Mac mini
Safari / MacOs / Mac mini
When the DeviceManager is created, at first it does not know about any devices if permissions have not been granted yet and so initially its local acs list of devices is empty. If we then call the DeviceManager.askPermission() API, the user is prompted for device access and if the user clicks on allow to grant the access, then the device manager will learn about the devices, update its local acs list of devices and fire the 'audioDevicesUpdated' and 'videoDevicesUpdated' events.

Lets say we then refresh the page and create device manager, the device manager will be able to learn about devices because user has already previously granted access, and so it will initially have its local acs list of devices filled and it will not emit 'audioDevicesUpdated' nor 'videoDevicesUpdated' events for this case. And even if at this point we call the DeviceManager.askPermission() API, user will not get a prompt becuase device access has already been previously granted for the site.

These events are also fired when plugging-in/unpluggin devices.

This was consistent across all browsers/platforms listed above.