The attached GIF is transformed into a static image

[softvision-sergiulogigan]

Browser / Version Chrome 71

Operating System Windows 10

Prerequisites:

• Login to webcompat.com

Steps to reproduce:

1. Navigate to: https://webcompat.com/issues/new
2. Report an issue with an attached GIF.
3. Observe the GIF rendering.

Expected Behavior: The gif is animated.

Actual Behavior: The gif is static.

Notes:

1. See https://github.com/webcompat/web-bugs/issues/25033

Watchers: @softvision-oana-arbuzov @softvision-sergiulogigan @cipriansv

sv;

[softvision-sergiulogigan]

Might be related to #2719

[karlcow]

Maybe not the same issue. GIF and Pillow are not good friends and I guess this is the issue from #2719

but here you seem to get a static GIF like if the original image had been converted to a simple GIF. The original GIF you were trying to post is massive. 7,054.19 KB (7,223,486 bytes)

And I guess then it is being reduced by… @miketaylr client side script (as we have 4MB limit for the form), in the process, it destroys the animated gif and make it just a simple gif.

[karlcow]

I will assign this one to @miketaylr and I will take the other one.

[miketaylr]

A 7MB GIF is too big, I would say this is probably expected behavior given its size. I wonder if there's something we could do with UX here to at least communicate the implications for a large GIF.

[marimeireles]

@miketaylr what do you think of adding an ìf` here:

https://github.com/webcompat/webcompat.com/blob/1c8c93d4fef2c75a71786b8f9a3fdd4a6892a26e/webcompat/static/js/lib/issues.js#L237-L240

if e.target.files[0].size > 7MB prints message to user warning that it may fail

[marimeireles]

I mean:

if image type == GIF && if e.target.files[0].size > 7MB

[miketaylr]

I think that's probably the wrong place to check that, @marimeireles.

In BugForm#showUploadPreview, we downsample it if it's bigger than the upload limit -- so I think it would never hit that if statement inside ImageUploadView#validateAndUpload.

https://github.com/webcompat/webcompat.com/blob/eae44eda6b0e1db226d9c4acaa90839c99199593/webcompat/static/js/lib/bugform.js#L161-L178,

So if we want to not attempt to resize (animated?) GIFs, that's probably the place to do it. It would be interesting to see how to detect animated GIFs from JS...

[marimeireles]

Apparently there are a few different weird ways to do that. Using a npm package, checking the gif headers and converting it to an array. I could also just print a message to the user explaining that we will down sample the image and it will stop being animated, if you think these solutions are overkill... @miketaylr

[softvision-raul-bucata]

It was observed that when a reporter fills in the bug report form with valid data until the "Screenshot" section of the report is reached when the reporter uploads a file in .gif format, the file is actually uploaded in a .jpeg format and can not be viewed in its original format. This is reproducible in the staging version and in the public version.

Notes:

1.When the reporter tries to edit a report, this is the result in the screenshot section:

2. Public version: https://webcompat.com/issues/new Staging version: https://staging.webcompat.com/new
3. Reproducible across all browsers.

Environment: Operating system: Windows 10 Pro x64 Browser: Firefox Nightly 87.0a1 (2021-01-26) (64-bit) / Google Chrome Version 87.0.4280.141 (Official Build) (64-bit)

[karlcow]

@softvision-raul-bucata The conversion from gif to jpeg is on purpose to save space. :) It should not happened for animated GIF. which is what this issue is about. Was it an animated gif you were trying to upload?

[softvision-raul-bucata]

@karlcow it is an animated GIF. It has 145 frames and takes 3.43 MB in storage space.