Cannot upload audio-only .webm file

[foresto]

Description

Attempting to upload a .webm file fails, regardless of whether through drag-and-drop or clicking the paperclip icon. The "Upload files" dialog correctly appears, but when I confirm by clicking the "Upload" button, the "Uploading filename.webm" message remains forever stuck at "0 B / MB".

If I rename the same file to give it a .webmx suffix, uploading works.

Steps to reproduce

• Drop a .webm file onto Riot, or select it from the paperclip icon.
• Confirm that you want to upload the file.
• Watch it claim to be uploading, with no progress, ever.

This appeared in the Electron console log:

vendors~init.js:2 Starting load of AsyncWrapper for modal
vendors~init.js:2 Uncaught TypeError: Cannot read property 'type' of null
    at vendors~init.js:2
(anonymous) @ vendors~init.js:2

• Attempting to exit the program also fails while the stalled upload is still present. Canceling the upload allows the program to exit.

Version information

• Platform: desktop
• OS: Ubuntu 19.10
• Version: 1.6.8 (flathub)

[t3chguy]

Duplicate of #14328

[foresto]

@t3chguy Are you sure it's a dupe? That bug is about HEVC video encoding. This one is about an audio-only file, and the problem goes away when the same file has a different name.

[t3chguy]

Ah well then it's your browser saying its a video file yet refusing to generate a thumbnail for it i bet, will leave open until I can confirm

[foresto]

It's Electron, then. This is the desktop app.

[t3chguy]

So this is a browser bug where it says the File type for an audio-only webm file is

You can try it out yourself here: https://jsfiddle.net/dgw07tjh/1/

This boils down to a combination of

#7370 (Browser reports file type incorrectly)
and
#14328 (Chromium chokes differently [harder] than Firefox on trying to thumbnail an incompatible video/not a video)

The fix for #14328 might be to send as a regular file without being playable if not able to thumbnail, causing something like #7370 and #14330

There is no sane way to detect the file type ourselves in client-side JS and we can't use any services for it due to the privacy issues with that, especially for encrypted rooms.

I have reported it to
Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1105377
Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1652680

#14328 has the same symptom, same exception, so fixing that issue will likely fix this one too (unless the fix is from the browser)

[foresto]

There is no sane way to detect the file type ourselves in client-side JS

How about catching the exception and handling it gracefully? That could mean just retrying the upload as an opaque file without type information. If that's not possible, at least letting the user know that Element can't handle file names with certain suffixes would be helpful; much better than just getting stuck with an "uploading" message that never progresses.

[t3chguy]

Yup that is what I suggested as I said above.

The fix for #14328 might be to send as a regular file without being playable if not able to thumbnail, causing something like #7370 and #14330

Its not whether element can handle the suffixes, it's whether your browser can.

[foresto]

Its not whether element can handle the suffixes, it's whether your browser can.

My browser has nothing to do with it. This is the Element desktop app.

[t3chguy]

In which case it depends on the version of Chromium is used by Electron, which can vary depending on which repository you install the app from.

[DooMMasteR]

In my case it is also still broken on current Chrome :-(
86.0.4240.183

Btw. renaming the files wit the extension OGG is a also workaround, it is an OGG container after all.

[t3chguy]

The app now will fall back to uploading an m.file if the thumbnail generation fails