• Welcome to the Chevereto User Community!

    Here, users from all over the world come together to learn, share, and collaborate on everything related to Chevereto. It's a place to exchange ideas, ask questions, and help improve the software.

    Please keep in mind:

    • This community is user-driven. Always be polite and respectful to others.
    • Support development by purchasing a Chevereto license, which also gives you priority support.
    • Go further by joining the Community Subscription for even faster response times and to help sustain this space
  • Chevereto Support CLST

    Support response

    Support checklist

    • Got a Something went wrong message? Read this guide and provide the actual error. Do not skip this.
    • Confirm that the server meets the System Requirements
    • Check for any available Hotfix - your issue could be already reported/fixed
    • Read documentation - It will be required to Debug and understand Errors for a faster support response

Uploading doesn't work anymore without WebAssembly

Version
4.3.6
PHP version
8.3.23
Database driver
MariaDB
Database version
10.6.22
Web browser
LibreWolf, IronFox, Firefox
user_28c0a

user_28c0a

Chevereto Member
I just noticed that I can no longer upload images to my Chevereto site with WebAssembly disabled. This affects hardened browsers that ship with WebAssembly disabled by default, as well as standard Firefox with it disabled using about:config. There's not even some form of error handling implemented that would show a popup telling the user that WebAssembly is required. Instead, it looks like the upload is taking forever and stuck at 0%. Only the Javascript Console reveals the error related to WebAssembly.

There are very good reasons why users may choose to disable WebAssembly, see here: https://github.com/stevespringett/disable-webassembly Therefore I really want my site to also work without WebAssembly. There are multiple ways how the current situation can be improved:
1. Add a setting for site owners that allows to disable the WebAssembly-related functionality so that uploads work completely without it (preferred)
2. Add a fallback so that uploads still work without the WebAssembly-related functionality if it is detected that the browser doesn't support it (might be implemented instead of 1. or additionally to it)
3. If you don't bother fixing it, please at least add a message showing the user what went wrong instead of letting them wait forever (not a real solution,really prefer 1. or 2. or both)

Reproduction steps

1. Open LibreWolf or Firefox, visit about:config
2. Set javascript.options.wasm to false
3. Restart the browser
4. Visit a Chevereto site
5. Try uploading a image

Unexpected result

"Uploading x files (0% complete)" stays forever, no progress is being made, no error message is shown to the user.

Error log message

Error hashing file: ReferenceError: WebAssembly is not defined
 
Sort by date Sort by votes
Hello,

Chevereto WASM usage is for replacing systems that became too slow for JS, in particular this is because the xxh64 algorithm used to fingerprint files, introduced in 4.3.0. When I implemented that sign the performance for JS-only solutions was abysmal.

Rodolfo

Thread 'Deprecate MD5 file checksum in favor of XXH64'

Describe your feature request
The MD5 file checksum hashing is O(n) and when we started to support big files you can notice a very abysmal performance. A 5GB file can easy take up to 20s to compute the hash. This RFC is for updating the file hashing function, which is used only to detect duplicates.

The xxh64 algo is way faster and collision resistant, it is natively supported by PHP and we can also easily add it to JavaScript (wasm) which is really fast in the browser.

1745846012182.png

^ The XXH64 algo is 16X faster than MD5.

Where did you see this?
I was lurking at...
  • Like

If you find a faster JS-only library for handling larger files let us know.
 
Upvote 0 Downvote
I took the time to experiment with pure-JS xxhash64 solutions a bit. There aren't so many implementations that work in the browser, most target NodeJS instead. I noticed that js-xxhash has a open pull request that replaces the custom big int implementation with native Javascript BigInt, which should improve performance, see here: https://github.com/pierrec/js-xxhash/pull/24

I modified the script a little bit to work in the browser, support data in Uint8Array format and support an empty seed. You can find the result here: https://paste.js.org/McQ6zQ1-K3lD
I also made a small HTML page where the code can be tested, source code here: https://paste.js.org/7balGsvP1Ux8

The code is blazing fast with small files. With bigger files, it gets slower. A file with 512MB took 24 seconds in a local test, 4.2GB took more than 3 minutes. I should add, however, that a good portion of the waiting time might also be caused by reading the data from my good old hard disk.

The JS-only solution might still be slower than WebAssembly, but for me it's fast enough. It could be implemented as a fallback that is only used if WebAssembly is unsupported. Longer wait times are better than having the upload not work at all. Also consider that not all sites are dealing with very huge files. I, personally, have no interest in hosting/allowing files larger than a few MB on my image sharing website.

Another possible solution, if you don't want to implement two client-side hashing functions, would be skipping it entirely if WebAssembly is unavailable. From what I understand, the files are hashed on the server-side in PHP anyway, so the client could skip calculating the hash, upload the file anyway and then use the hash from the server.

@warg Yes, the issues of WebAssembly are design choices, they still exist and will never be solved. Running random binary blobs that you can't check for safety and which may be non-free software is the whole point of WebAssembly, but it has downsides and some people (myself included) may not want to run that on their computer.
 
Upvote 0 Downvote
The hash on the client side is required for preventing big file dupes, to avoid filling up too much space on the /tmp dir as the payload needs to be stored somewhere. Since 4.3 any upload greater than 16MB goes to this process and is the client side (web browser) which hashes the file and sends that hint before the server accepts the rest of the upload payload.

I picked xxh64 because that was the baseline available on web browsers as unfortunately xxh128 and xxh3 aren't available. PHP supports all algos, this is not a backend limitation.

Any technology can be wrongly used to do stuff you don't want to, but the tech is not to blame for but people.

In this case, if you feel bad about this particular component, you can investigate the source on your own here. If you still feel unsure you can fork it and bundle it yourself into your Chevereto installation. Here's the build command and here is where you want to place it in Chevereto: content/legacy/themes/Peafowl/lib/js/xxhash-wasm.js and here the command ro re-build JS: app/bin/legacy -C js

In Chevereto I manually review all JS code, versioned. We now have our own fork/copy of that component, just like everything else.
 
Upvote 0 Downvote
Thanks for pointing me to the command for rebuilding the JS. That was the missing puzzle piece for solving the problem locally. I replaced the WebAssembly stuff with the JS-only solution I posted above on my Chevereto server, now I can finally upload images again.

I still think there should be a proper fallback directly in Chevereto, or at the very least a error message shown to the user, instead of having the Upload load forever, but for me personally the problem is now solved.
 
Upvote 0 Downvote
You must log in or register to reply here.
Back
Top