⚠️ #Tusky ⚠️, some #CustomEmoji in posts are being animated despite having them disabled in Tusky's preferences.
Just came across one of the fast paced flashing blob emojis (blob_rave) through scrolling and spotted it. Searching that emoji "blob_rave", most rightly aren't being animated, but there are a few that are popping up for me being animated, specifically a post containing that emoji that also is in #MastoAdmin & #FediAdmin tags.
Even after logging out, clearing cache and logging back in still has the issue with the animated emoji not respecting the preferences. It's not that post in particular itself, in which the emoji correctly doesn't animate from a different instance, but it is for some reason on my account on this instance here.
Probably not even actually anything new from v32 I just came across it by chance.
I'll see if a different account on here has the same issue with the same post
Okay I've confirmed that same exact post with the offending emoji that's escaping the Tusky preference specifically here on .art also happens on a different .art account in Tusky.
What the actual hell is this bug that's caused this lmfao.
It's the blob_rave in this post that's not respecting my setting:
https://pouet.space/@lodart/114823178792280901
Again it's only happening here on .art though with that post, haven't found any other post that's animating despite having animated emojis off.
Désolé pour le petit downtime, mais on est en 4.4 :blob_rave: #MastoAdmin #FediAdmin
@jase this looks like it's a Mastodon bug we fixed last year: https://github.com/mastodon/mastodon/pull/34337
the custom emoji would need to be re-processed by mastodon.art, unfortunately there is no interface to force that to happen; the emoji can also be deleted by an admin from the admin interface, which will remove it from all existing posts from pouet.space, and new posts using it will use a newly-processed version
@ClearlyClaire thanks Claire. So okay the issue from what you mention then was the cached emoji not having any static version resulting in the gif version being used, and that being a lingering from when masto had the bug.
Definitely would be very valid then clients implementing a safety net that rejects that from being allowed for emojis if the user's preference is animated emojis being disabled.. so it would of in that case only showed the short code text instead of the file.
@jase no, the issue is basically that the “static” version served by Mastodon was the original unmodified animated version, because of a bug in our code that copied while skipping conversion
clients may be able to prevent such images from animating, but that's generally more difficult to do, which is why Mastodon works by serving two versions
@ClearlyClaire yea, had thought in the addition of animated to the PNG format opted for say .pnga, then it would of been a .pnga in the static folder not the expected .png that clients in that vase be explicitly expecting say.. that'd of prevented. But we aren't in that timeline that media format creators thought of these things of what if the expectation of this format is static and someone learns the hard way it can also be animated.
Just it HAD to be a flashing emoji here didn't it omg lol
Claire (testing!!)