Bug: mux-uploader 'success' immediately triggered when selecting file in Safari

[cgs]

Is there an existing issue for this?

• I have searched the existing issues

Which Mux Elements/Packages does this apply to? Select all that apply

mux-uploader

Which browsers are you using?

Safari

Which operating systems are you using?

macOS

Description

Using mux-uploader. I have a 4.5 GB .mov file that when selected via the file browser (or using drag/drop) immediately triggers the 'success' event and the file is not actually uploaded:

Screen.Recording.2024-04-03.at.9.58.15.AM.mov

This only happens with this specific file and in Safari. There are no errors in the console. It works ok in Chrome. Here are the video specs:

Here is the video file: https://www.dropbox.com/scl/fo/a3abqnobqroiaomuv1u1r/h?preview=Daily+Meditation_v2.mov&rlkey=w39tdtitdux7thftzpxjd6od3&dl=0

Reduced test case

No response

Steps to reproduce

1. Download the file linked above
2. In a bare-bones mux-uploader implementation, drag or select the file in Safari

Current Behavior

'success' immediately triggered and "Upload Complete" shown, but file not actually uploaded. See video above

Expected Behavior

File should upload normally

Errors

There are no console errors.

What version of the package are you using?

1.0.0-beta.15

[cjpillsbury]

Hey @cgs sorry for the slow response! This is is sadly due to a bug in WebKit (https://bugs.webkit.org/show_bug.cgi?id=272600). We're hoping to eventually implement an "opt in" (sub-optimal) fallback, but in the interim, I've made some updates to at least appropriately notify the state with some default guidance for the user. Given the browser-based nature of this bug, do you think this will hold you over for your use case until either WebKit fixes it or we get that "less than ideal" workaround in place?

[cgs]

Hey @cgs sorry for the slow response! This is is sadly due to a bug in WebKit (https://bugs.webkit.org/show_bug.cgi?id=272600). We're hoping to eventually implement an "opt in" (sub-optimal) fallback, but in the interim, I've made some updates to at least appropriately notify the state with some default guidance for the user. Given the browser-based nature of this bug, do you think this will hold you over for your use case until either WebKit fixes it or we get that "less than ideal" workaround in place?

Yes, I think a descriptive error is better than no error! Thanks for investigating this.