nextcloud-libraries / nextcloud-libraries/nextcloud-viewer

Editing a GIF, BMP, ICO or SVG writes PNG bytes under the original name

Open
#48 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

AI assisted status: triage type: bug
Dominant language
TypeScript
Stars
1
Forks
0
Avg merge
6h 19m
Merged PRs (30d)
43

Description

images.ts:94 sets canEdit: true for the whole image handler, so the Edit button is offered on all 13 mimes it registers: image/apng, image/bmp, image/gif, image/jpeg, image/png, image/svg+xml, image/webp, image/x-icon, and image/heic, image/heif, image/tiff, image/x-xbitmap, image/emf where the server generates previews for them.

@nextcloud/image-editor can only write three. ExportOptions.format is typed 'image/png' | 'image/jpeg' | 'image/webp', and the viewer narrows it further at lib/components/ImageEditor.vue:46:

const exportOptions = computed<ExportOptions>(() => {
	if (props.file.mime === 'image/jpeg' || props.file.mime === 'image/webp') {
		return { format: props.file.mime, quality: 0.9 }
	}
	return { format: 'image/png' }
})

So editing a GIF produces PNG bytes, and onSave PUTs them to props.file.encodedSource, which is the original name. holiday.gif afterwards contains a PNG. Same for BMP, ICO, APNG (which loses its animation on the way through the canvas), TIFF, HEIC and, worst of the set, SVG, where a vector file comes back as a raster one under a .svg name.

ExportResult already carries mimeType, and the save path ignores it.

[!NOTE]
I have read this off the code path rather than reproduced it against a server, so the exact behaviour per mime is worth confirming before picking a fix.

Roughly, the options are to stop offering the edit where the format cannot be written back (narrow canEdit to the three, or make it per-mime rather than per-handler), or to save under a new name with the extension that matches what was actually encoded and leave the original alone. The second keeps the feature for more files but turns a save into a create, which the user should be told about rather than discover.


Second thing, same lines. The quality: 0.9 above overrides the quality matching in the editor's export. Left alone, qualityFor(source) reads the source's own quantization tables and writes the new file at the quality the old one was written at, held between 0.75 and 0.97. Passing an explicit 0.9 defeats that for every JPEG and WebP the viewer saves: a photo written at 0.95 loses more than it needs to, one written at 0.80 is re-saved larger than it needs to be. Dropping the quality key restores the matching, since options.quality is only consulted when set.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at images.ts:94 and lib/components/ImageEditor.vue:46, then trace onSave through ExportResult and props.file.encodedSource. Confirm the behavior for the listed MIME types before choosing whether unsupported formats should lose editing or be saved under a new matching name. Done means edits cannot write incompatible bytes under the original name and JPEG/WebP quality matching is preserved.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
frontend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
50/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.