Compatibility check does not point out source of incompatibility in case of missing/disabled webaudio API

[mpeter50]

Steps to reproduce

1. I'm starting with a Firefox-based browser with no webpages open. It's dom.webaudio.enabled about:config settings has happened to be false
2. I have navigated to https://app.element.io/
3. The webapp tells there is a compatibility issue with my browser, but does not tell what is that
4. I click the "Continue anyway" button
5. The webapp shows the unsupported browser page, but does not tell why is that

Outcome

What did you expect?

A short (or longer, when more information would be useful) description that Element could not access the browser's WebAudio API. An error message you got could also be useful to be displayed for the generic case.

What happened instead?

The webapp did not tell the reason of incompatibility.

Additional information

According to #27864, you have already implemented such a feature, but it seems there may be something preventing it from working.
I have mentioned the issue there earlier, but did not get a response about whether this is expected or unexpected behavior, so I have opened this issue in the belief that this is unexpected behavior.

I expect that the incompatibility in this case is the missing WebAudio API, because if I enable it in about:config the webapp will load fine.

Operating system

Windows

Browser information

Firefox

URL for webapp

https://app.element.io/

Application version

No response

Homeserver

No response

Will you send logs?

No

[mpeter50]

Screenshots about how the webapp looks like at the 3rd and 5th points:

Compatibility warning page	Failure page

[t3chguy]

The designers explicitly did not want any UI to show exactly what feature is missing, nor can we realistically get translations for all the various things which can be missing.

[mpeter50]

The designers explicitly did not want any UI to show exactly what feature is missing

What is the reason behind that? Would it help if this information was only shown in a default-collapsed menu?

I think it would be useful to have this because it can be actionable by the user.
Incompatibility can not only be caused by old software, but also by disabled features, like this one. For example, if the user has disabled webaudio support because of the fingerprinting possibility on any website, with the understanding that they are fine without web calls, seeing that it causes a problem here can make them to consider to switch it on again, and to approach this fingerprintability problem in a different way.

This does not only apply to the current webaudio api thing, but generally to other incompatibility cases too.

nor can we realistically get translations for all the various things which can be missing.

I see. Do we need translations, though? I would expect that if the user does not immediately understand what "WebAudio API is not available" means and what to do to fix it, they would need to reach for external help to resolve such an issue anyway.
What I wanted to say is that I think it may not be useful to translate this, kind of similarly to log messages.

This way, the added value of this would be that the problem is unambiguous, and the user does not need to dive in the logs, where several other warnings, maybe error level messages too are visible. The external help would also not need to try to get the user to look at the logs, and forward them somehow, either.

[t3chguy]

I see. Do we need translations, though?

Yes, multiple customers require translatability for all parts of the app

[grinapo]

The usual solution is to have a non-intrusive button or link saying "technical information for developers" which does not require inner translation, especially if it spews obvsiously tech-looking things like a json. Except it would not be you developers but all of us out here.

The main point is not to inform the user but to offer the possibility for any IT people to help the user to determine what the problem may be. Maybe even you, developers, in the end.

(Funny that I wanted to say that maybe debug logs contain that information but realised that "Download logs" does exactly nothing, and definitely not downloading debug logs. Puzzling. So, I may mean a working debug logs output or even better an excerpt regarding the specific infompatibilities.)

[t3chguy]

(Funny that I wanted to say that maybe debug logs contain that information but realised that "Download logs" does exactly nothing, and definitely not downloading debug logs. Puzzling. So, I may mean a working debug logs output or even better an excerpt regarding the specific infompatibilities.)

They do, and if the button doesn't work for you then that sounds like an issue on your end. You can also visit your browser console to get at the same logs.

Screen.Recording.2024-11-07.at.09.46.19.mov

[grinapo]

sounds like an issue on your end

Issued separately, thank you. Please do not let that to distract you from this original issue.

[MarcWadai]

There also might be other browser settings that cause the webaudio to not work.
Will it be possible to add a check like new RTCPeerConnection() to see if it is even possible to start a call on the current user browser settings ?