Profile image: "Couldn't read the image: bad image" #317

New issue

Closed

opened 2026-10-23 19:03:18 +00:00 by littlefox · 1 comment

littlefox commented

2026-10-23 19:03:18 +00:00

Owner

Reported by the user: uploading a profile image (a 200×200 orange and white chevron on black) fails with "Couldn't read the image: bad image".

"bad image" comes from app/src/image_pick.rs: the webview's <img> fired onerror on the picked file, before NeoKOM looked at it.

Checked: WebKitGTK 2.4x (the desktop CI image), on a page from a custom scheme like the app's, loads a picked PNG through a blob: URL, a data: URL and createImageBitmap. So it is something about this file (its format or type), not how the picker loads files.

Needs the file (needs/user). Whatever the cause, the message should say what kind of file it was and that NeoKOM can't read that kind, not "bad image".

Reported by the user: uploading a profile image (a 200×200 orange and white chevron on black) fails with "Couldn't read the image: bad image". "bad image" comes from `app/src/image_pick.rs`: the webview's `<img>` fired `onerror` on the picked file, before NeoKOM looked at it. Checked: WebKitGTK 2.4x (the desktop CI image), on a page from a custom scheme like the app's, loads a picked PNG through a `blob:` URL, a `data:` URL and `createImageBitmap`. So it is something about this file (its format or type), not how the picker loads files. Needs the file (`needs/user`). Whatever the cause, the message should say what kind of file it was and that NeoKOM can't read that kind, not "bad image".

littlefox added the

needs/user

kind/bug

labels

2026-10-23 19:03:18 +00:00

littlefox referenced this issue from a pull request that will close it,

2026-10-24 06:32:07 +00:00

Pictures on the desktop: read the file from the event, not the page #326

littlefox referenced this issue from a commit

2026-10-24 06:32:08 +00:00

Pictures on the desktop: read the file from the event, not the page

littlefox closed this issue

2026-10-24 07:08:49 +00:00

littlefox commented

2026-10-24 07:47:36 +00:00

Author

Owner

Fixed in #326; main green (run #593).

The file was fine: fox.png is a plain 200x200 RGBA PNG. Dioxus desktop opens its own file dialog and gives the page's input an empty stand-in (new File([], path)), which the picker read, so every picture picked on the desktop failed. The bytes now come from the change event (FileData::read_bytes); pasted and dropped images are read in the page.

Checked:

fox.png picked through a real file dialog in WebKitGTK (the desktop CI image, page on a custom scheme): blob, data URL and createImageBitmap all load it.
images, paste, profile and post-image specs on the web.

Not automated: the desktop's xdg-portal dialog isn't in the headless CI image. The user is testing the app.

Fixed in #326; main green (run #593). The file was fine: fox.png is a plain 200x200 RGBA PNG. Dioxus desktop opens its own file dialog and gives the page's input an empty stand-in (`new File([], path)`), which the picker read, so every picture picked on the desktop failed. The bytes now come from the change event (`FileData::read_bytes`); pasted and dropped images are read in the page. Checked: - fox.png picked through a real file dialog in WebKitGTK (the desktop CI image, page on a custom scheme): blob, data URL and createImageBitmap all load it. - images, paste, profile and post-image specs on the web. Not automated: the desktop's xdg-portal dialog isn't in the headless CI image. The user is testing the app.

littlefox removed the

needs/user

label

2026-10-24 07:47:47 +00:00