Open Bug 1848544 Opened 1 year ago Updated 1 year ago

The picture is displayed differently in firefox than in chromium and geeqie (Firefox ignores crc mismatch on acTL chunk)

Categories

(Core :: Graphics: ImageLib, defect)

Firefox 116
defect

Tracking

()

People

(Reporter: xjjzyx, Unassigned)

References

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/116.0

Steps to reproduce:

Open the attached picture with firefox, and then open the same picture with chromium,.

Actual results:

The displayed content is very different.

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Widget: Gtk
Product: Firefox → Core

Can repro on a Win11x64 machine.
Firefox displays a completely different image. Chrome and Windows photo viewer show the same image.
Can repro this on a build from Jan2021. So this is not a new regression.

Status: UNCONFIRMED → NEW
Component: Widget: Gtk → Graphics: ImageLib
Ever confirmed: true
Blocks: apng

Where did you get this image?

Flags: needinfo?(xjjzyx)

I guess that doesn't actually matter, just curious about this unusual png.

Flags: needinfo?(xjjzyx)

The crc on the acTL chunk (the animation control chunk, the chunk that flags the image as being animated and contains the basic animation info) is incorrect. libpng just issues a warning and Firefox ignores that and decodes the image as an APNG (reading the fDAT chunks to get the image data). Evidently Chrome decides to ignore the acTL chunk and treat this as a static png (displaying only the IDAT chunks). The IDAT and fDAT chunks contains very different images, so hence the result. On macOS, both Safari and the macOS Preview app match Firefox. If I disable apng support in Firefox then we match Chrome as expected. If I fix the CRC on the png then Chrome matches Firefox.

Arguably Firefox's behaviour is good here, being flexible in what it will accept as an animated image, but I'm open to hearing arguments the other way.

If this is just one corrupt image then I think we should probably just keep Firefox as it is. If there are more images like this then maybe we could consider doing something else.

Interestingly, bug 1693190, bug 1225679, and bug 1422694 are all about cases where Firefox is more strict when parsing a PNG then Chrome, and bug 1225679 is even about incorrect CRCs, but I guess acTL chunks are the only chunk we don't care about the CRC maybe?

Severity: -- → S4

I'm also curious what the writing in the image says, in case it gives any clues about the reason this image is setup that way.

Summary: The picture is displayed differently in firefox than in chromium and geeqie. → The picture is displayed differently in firefox than in chromium and geeqie (Firefox ignores crc mismatch on acTL chunk)

(In reply to Timothy Nikkel (:tnikkel) from comment #6)

I'm also curious what the writing in the image says, in case it gives any clues about the reason this image is setup that way.

The text that I see only displayed in firefox seems to be some Chinese advertisements.

Does it come from a website where there are similar images? Wondering if this is a one off image, or other images on the site have the same unusual structure.

(In reply to Timothy Nikkel (:tnikkel) from comment #8)

Does it come from a website where there are similar images? Wondering if this is a one off image, or other images on the site have the same unusual structure.

The picture comes from a Chinese website, but the page containing the picture was quickly deleted, probably due to the reason related to advertising, which should be a relatively common thing.
I should have seen such a picture once in total. But there are a lot of advertisers on that website, and the website should try to delete the ads that are not allowed.

This feels like something that should be standardized and we might want to reach out to our fellow browsers and collaborate on what to do here.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: