GIF images do not get rendered properly

littlefox commented

2026-10-27 18:08:28 +00:00

Owner

Animated GIFs only render one image and all GIFs, both animated and still only render as a black square instead of a full image.

littlefox added the

kind/bug

area/ui

labels

2026-10-27 18:08:29 +00:00

littlefox added this to the 0.8: Administration milestone

2026-10-28 09:08:42 +00:00

littlefox commented

2026-10-28 09:20:38 +00:00

Author

Owner

Tried on the test server, in Chromium (desktop, Android profile) and WebKit (iPhone profile), with a spec (e2e/tests/gif.spec.ts on branch issue-359-gif):

A small still GIF (64×48) posted from the composer: shown, right colours.
A small animated GIF: shown, and it animates (the spec samples the picture until it has seen both frames).
A big animated GIF (480×360, 200 kB): posted as a still JPEG. Anything over the server's text limit (lyskomd's default is 128 KiB) or over 1 600 px is redrawn on a canvas and saved as JPEG, which keeps only the first frame. That is one cause of "only one image", and NeoKOM doesn't say it happens. Also, a GIF that fits the limit but is wider than 1 600 px is converted when it needn't be.

What I can fix now: keep a GIF as it is whenever it fits the limit, and when it doesn't, say in the composer that the animation is lost ("För stor för servern: skickas som stillbild"). A browser can't re-encode an animated GIF smaller.

The black square I could not reproduce. In dark mode, an image the browser fails to decode shows as NeoKOM's dark checkered background, which may look like a black square, so I think the picture data itself is broken somewhere. To find where:

Where did you see it: the web app (which browser) or the desktop app (Linux/WebKitGTK, Windows, macOS)?
Were the GIFs posted from NeoKOM, or by another client (Emacs, jskom)? If they are on kom.lysator.liu.se, a text number or two would let me look at exactly what is stored. Reading them there needs a login, so I'd need your OK for that (D-007).
Does "Spara bilden" under the black square give a working GIF file?

Tried on the test server, in Chromium (desktop, Android profile) and WebKit (iPhone profile), with a spec (`e2e/tests/gif.spec.ts` on branch `issue-359-gif`): - A small still GIF (64×48) posted from the composer: shown, right colours. - A small animated GIF: shown, and it animates (the spec samples the picture until it has seen both frames). - A big animated GIF (480×360, 200 kB): **posted as a still JPEG**. Anything over the server's text limit (lyskomd's default is 128 KiB) or over 1 600 px is redrawn on a canvas and saved as JPEG, which keeps only the first frame. That is one cause of "only one image", and NeoKOM doesn't say it happens. Also, a GIF that fits the limit but is wider than 1 600 px is converted when it needn't be. What I can fix now: keep a GIF as it is whenever it fits the limit, and when it doesn't, say in the composer that the animation is lost ("För stor för servern: skickas som stillbild"). A browser can't re-encode an animated GIF smaller. **The black square I could not reproduce.** In dark mode, an image the browser fails to decode shows as NeoKOM's dark checkered background, which may look like a black square, so I think the picture data itself is broken somewhere. To find where: 1. Where did you see it: the web app (which browser) or the desktop app (Linux/WebKitGTK, Windows, macOS)? 2. Were the GIFs posted from NeoKOM, or by another client (Emacs, jskom)? If they are on kom.lysator.liu.se, a text number or two would let me look at exactly what is stored. Reading them there needs a login, so I'd need your OK for that (D-007). 3. Does "Spara bilden" under the black square give a working GIF file?

littlefox added the

needs/user

label

2026-10-28 09:20:46 +00:00

littlefox referenced this issue from a commit

2026-10-28 09:48:52 +00:00

Spec: GIFs, still and animated, are shown as they are

littlefox referenced this issue from a commit

2026-10-28 09:48:52 +00:00

GIFs that fit the server are posted as they are

littlefox referenced this issue

2026-10-28 09:49:04 +00:00

GIFs that fit the server are posted as they are (#359) #385

littlefox referenced this issue from a commit

2026-10-28 10:25:39 +00:00

Merge pull request 'GIFs that fit the server are posted as they are (#359)' (#385) from issue-359-gif into main

littlefox referenced this issue

2026-10-28 12:40:52 +00:00

Roadmap: 0.8's answered backlog done #390

littlefox referenced this issue from a commit

2026-10-28 12:40:52 +00:00

Roadmap: 0.8's answered backlog done, but #359's black square

littlefox commented

2026-10-28 13:48:25 +00:00

Author

Owner

The gif was posted by a user using neokom. it may be the case that the image that was saved was just black. Instead of trying to debug this much further, we should instead focus on informing the user how their images and media are altered to fit the data limit of a lyskomd text.

1. The gif was posted by a user using neokom. it may be the case that the image that was saved was just black. Instead of trying to debug this much further, we should instead focus on informing the user how their images and media are altered to fit the data limit of a lyskomd text.

littlefox removed the

needs/user

label

2026-10-28 13:48:35 +00:00

littlefox referenced this issue from a commit

2026-10-28 13:58:48 +00:00

Say how a picture is changed to fit the server

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

2026-10-28 13:58:52 +00:00

Say how a picture is changed to fit the server (#359) #391

littlefox closed this issue

2026-10-28 14:23:06 +00:00

littlefox referenced this issue from a commit

2026-10-28 14:23:07 +00:00

Merge pull request 'Say how a picture is changed to fit the server (#359)' (#391) from issue-359-say-changes into main

littlefox commented

2026-10-28 14:25:49 +00:00

Author

Owner

Done in PR #391 (D-072), main run #749 green. When a picture is redrawn to fit, the composer, the chat's reply field and the profile editor now list what changed under it: the original's size against the server's limit, pixels before and after, format and JPEG quality, transparent parts turned white, and a lost animation (GIF frames counted; animated PNG and WebP recognised). A picture that goes as it is says nothing. The black square isn't chased further.

Verified: unit tests for the frame counting; e2e gif.spec (a half-transparent 2000 px PNG and a too-big animated GIF show their lists; a small GIF shows none) plus compose, profile and thread-chat specs, 51/51 in desktop, Android and iPhone profiles.

Done in PR #391 (D-072), main run #749 green. When a picture is redrawn to fit, the composer, the chat's reply field and the profile editor now list what changed under it: the original's size against the server's limit, pixels before and after, format and JPEG quality, transparent parts turned white, and a lost animation (GIF frames counted; animated PNG and WebP recognised). A picture that goes as it is says nothing. The black square isn't chased further. Verified: unit tests for the frame counting; e2e gif.spec (a half-transparent 2000 px PNG and a too-big animated GIF show their lists; a small GIF shows none) plus compose, profile and thread-chat specs, 51/51 in desktop, Android and iPhone profiles.

littlefox referenced this issue

2026-10-28 15:15:35 +00:00

Release 0.8.0 #392

littlefox referenced this issue from a commit

2026-10-28 15:15:37 +00:00

Release 0.8.0

Rows
Columns

GIF images do not get rendered properly #359