compat: MB14: enumeration of mediaDevices times out

there are a number of prefs (MB defaults in both 13 + 14)

• media.navigator.enabled - default false
• media.peerconnection.enabled - default true
• media.devices.enumerate.legacy.enabled - default false
• RFP default true

the nav pref makes no difference, if peer pref is enabled, we expose mediaDevices in navigator, and enumeration of those is protected by RFP. However, this has never seemed to cause any issues, but we should probably enable it so engineering works as expected (our config is probably not really supported, is a likely footgun) - cc @pierov . The legacy pref upstream was flipped to false in FF130 (99% sure)

So MB13 works perfectly, MB14 has a timeout error which is not good from a compat perspective. I'm not doing anything special with TZP code that I'm aware of (even if it was my code it's still a compat issue! change my mind!). I have tested FF 115 thru 130 with and without any and all of nav, RFP, legacy pref changes and cannot replicate. This seems to only be a MB14 issue. All tests done on HTTPS and each test done on a new tab with the old tab closed

obligatory pic

added 14.0 stable Fingerprinting labels

If I understand correctly, action item is flip media.navigator.enabled to true?

Will we need https://bugzilla.mozilla.org/show_bug.cgi?id=1899736 first?

It hasn't been landed upstream, but maybe they will uplift to 128 on their side when done (or we can ask to).

Otherwise, since it hasn't been too much time, it should be feasible to backport.

flipping media.navigator.enabled to true is one thing we could do, but it doesn't solve the timeout which only started in 14

I see.

However, timeout is a thing you implemented in TZP, the APIs will throw some exceptions. I think that in a way or another, promiseRaceFulfilled silences the error.

I wanted to check if maybe there was something in the console, but I don't have the problem on Linux. Let me try in a Windows VM.

Oh, well, I'm very slow today. It's expected: #320 (closed), as a workaround for tor-browser#42758 (moved).

OK, so it's a manifestation of --disable-webrtc. Setting media.peerconnection.enabled to false (and media.navigator.enabled must also be false) avoids the timeout with this build flag

So closing as wontfix - just get a wriggle on then fixing webrtc in windows @jwilde et al - until then TZP all websites enumerating media devices will suck on windows with MB

PS: also JFC on the beta translation - so annoying and it misbehaves somewhat MOAR terribly than normal with spoof english

Ideally upstream show return both prefs as false in code if --disable-webrtc - @pierov do you want to create an issue upstream?

I don't know if --disable-webrtc is a supported configuration. So, upstream would probably take a patch if we provided one, but I can't investigate right now.

closed

mentioned in issue tor-browser#43135 (closed)