Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot load an image of mime-type "application/x-msdownload;charset=UTF-8" #5679

Open
markusdd opened this issue Feb 4, 2025 · 4 comments · May be fixed by #5686
Open

Cannot load an image of mime-type "application/x-msdownload;charset=UTF-8" #5679

markusdd opened this issue Feb 4, 2025 · 4 comments · May be fixed by #5686
Labels
bug Something is broken

Comments

@markusdd
Copy link

markusdd commented Feb 4, 2025

I'm currently facing a problem in my program https://github.com/markusdd/EasyEDA_to_KiCAD_Lib_UI where I'm having to interface with a new image API. (using egui 0.30 for this as I cannot migrate to 0.31 yet because of a dependency, but I checked the relevant code, it has not changed)

Most older catalogue entries had URLs directly pointing to JPG files, like this one: https://assets.lcsc.com/images/lcsc/900x900/20230828_Megastar-ZX-PZ2-54-2-5PZZ_C7501276_back.jpg

Analyzing in browser it looks like this:

Image

Now, there is a new API like this: https://jlcpcb.com/api/file/downloadByFileSystemAccessId/8553684168530669568

Image

So the MIME-Type is designated as a download and only the disposition gives away that it is an image. This is common practice for images that are not getting displayed in the browser but directly being downloaded.

The issue is: The image loader currently fails because it does not recognize the MIME-Type and I have found no way through the API to tell it to ignore that.

What I have tried is locally patching the "is_supported_mime" function in src\loaders\image_loader.rs of egui-extras to do this:

if mime == "application/octet-stream" || mime == "application/x-msdownload;charset=UTF-8"

So I just 'bluntly' attached my requirement.

And it works perfectly, the images are being displayed again:

Image

But this is not a nice solution and I also cannot deploy my app like this, unless I switch to a fork of egui which I really want to avoid.

Any recommendations how to fix this properly or at least work around it for now?

@markusdd markusdd added the bug Something is broken label Feb 4, 2025
@YgorSouza
Copy link
Contributor

One way to avoid using a fork is to copy the default image loader to your project, change what you need to change, and add it to the Context using add_image_loader. I don't know if there is a more practical solution.

@markusdd
Copy link
Author

markusdd commented Feb 4, 2025

yeah that is essentially just as good as using a fork url in cargo.toml.

Question is how this could be solved more generally without adding like 500 mime-types to this check.

one clean way to solve this would actually be to look at the content disposition of the response header, as this one reveals cleanly that it is an image.

@lucasmerlin
Copy link
Collaborator

I think the best thing would be to open a PR and add application/x-msdownload;charset=UTF-8 to the whitelisted mime types (preferrably by replacing the if with something like if [mimes].contains(...))

Unfortunately we just did an egui release so itll take a while until the fix is released

markusdd added a commit to markusdd/egui that referenced this issue Feb 5, 2025
…nd appended encoding info

addresses Cannot load an image of mime-type "application/x-msdownload;charset=UTF-8" emilk#5679
@markusdd
Copy link
Author

markusdd commented Feb 5, 2025

created a PR, ready for review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something is broken
Projects
None yet
3 participants