SVG optimization/conversion fails in Firefox

[Wohma]

Describe the bug
When using Mazanoke to optimize/convert SVGs in Firefox or Zen Browser, it fails with "OffscreenCanvas.convertToBlob: Cannot get blob from empty canvas."

To Reproduce
Steps to reproduce the behavior:

1. Open Mazanoke in Firefox/Zen
2. Upload an SVG file (seems to be regardless of settings)
3. No image is produced, error in console is thrown

Expected behavior
Image gets optimized and is ready for download.

Screenshots

Desktop (please complete the following information):

• OS: Fedora 42
• Browser Firefox/Zen (tested in both)
• Version 140.0 / 1.14.2b

Additional context
Conversion in Chrome seems fine.
Example svg that fails: https://dev.w3.org/SVG/tools/svgweb/samples/svg-files/adobe.svg

On a side note:

• It would be great to list supported browsers
• If the conversion fails, it should not fail silently but at least some error should be displayed to the user.

Thanks in advance!

[civilblur]

Thanks for reporting the error, I was able to reproduce it on my end.

It would be great to list supported browsers

That's a good idea to include in the README, I'll take note of it. The intention has always been to support all the major browsers.

If the conversion fails, it should not fail silently but at least some error should be displayed to the user.

I completely agree. I have some TODO comments hinting this in the code, but admittedly, I prioritized adding new features and image file type support over implementing proper error handling.

Edit: Fix text formatting

[civilblur]

Haven't had time to fully investigate the issue yet, but here's what I've observed from my casual testing (this is more of a note-to-self):

It is related to SVG files that don't have width or height specified in their outer container, such as <svg ...> opposed to e.g. <svg width="200" ...>. When the SVG is ingested and painted onto a canvas object, the canvas is likely not being properly rendered due to missing width or height, thus it can't be read and fails.

[Wohma]

Makes sense, so maybe a good approach would be to show UI elements for specifying width and height (for vector inputs only?), pre-populate them where specified in the SVG and provide some sane defaults for other cases?

[civilblur]

To try to preserve the same user flow regardless of the file type selected, I've drifted mainly towards the idea of using a fallback value when there isn't a width or height set.

My assumption is that 80% of the use cases won't require a larger image dimension (either width or height) than 2048px, which is twice the size of the app store icon specification and sufficient for most general applications. SVG conversions tend to also be more limited to specific scenarios.

If 2048px is too large for the user, it is still possible to reduce size via the "Limit dimensions" option.

In case you have any thoughts and ideas surrounding this, let me know.

[Wohma]

The trouble with SVGs is that it could be anything as small as an icon, and as large as a complex diagram. In any case, I think 2048px is an alright default and can always be changed via limit dimensions, so this all sounds great :)
Thank you!

[civilblur]

Great! I've been limited on time lately, but I'll likely try to include this for the next release.