1682995 - (avif-default) Enable AVIF support by default

Status: RESOLVED FIXED

(Core :: Graphics: ImageLib, task, P1)

Description

[Jon Bauman [:jbauman:]]

What it says on the tin, basically. This amounts to setting image.avif.enabled to true and letting it ride the trains to release.

Comment 1

[Jon Bauman [:jbauman:]]

Attachment: Bug 1682995 - Enable AVIF support by default. r=aosmond,jaws

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/feef6926b977
Enable AVIF support by default. r=aosmond,preferences-reviewers

Comment 3

[Bogdan Tara[:bogdan_tara | bogdant]]

Backed out changeset feef6926b977 (bug 1682995) for test_accept_header.html failures.

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&fromchange=f737176fe4c7c6bb742315b5fcc44acc7e75af3d&tochange=97bb496fd391cd8bb30f65001a637f074a35be94&searchStr=mochitest&selectedTaskRun=EQV68_GGR6-czzsAYRylkA.0

Backout link: https://hg.mozilla.org/integration/autoland/rev/55143e2b92a52bf0a944a383932a4933a854e51d

Failure log: https://treeherder.mozilla.org/logviewer?job_id=324850432&repo=autoland&lineNumber=4150

[task 2020-12-17T19:53:15.275Z] 19:53:15     INFO - TEST-START | netwerk/test/mochitests/test_accept_header.html
[task 2020-12-17T19:53:15.452Z] 19:53:15     INFO -  test_accept_header /tests/netwerk/test/mochitests/test_accept_header.sjs?iframe
[task 2020-12-17T19:53:15.529Z] 19:53:15     INFO -  test_accept_header /tests/netwerk/test/mochitests/test_accept_header.sjs?get
[task 2020-12-17T19:53:15.550Z] 19:53:15     INFO - TEST-PASS | netwerk/test/mochitests/test_accept_header.html | Expected: iframe 
[task 2020-12-17T19:53:15.552Z] 19:53:15     INFO - TEST-INFO | started process screentopng
[task 2020-12-17T19:53:15.568Z] 19:53:15     INFO -  test_accept_header /tests/netwerk/test/mochitests/test_accept_header.sjs?image
[task 2020-12-17T19:53:15.596Z] 19:53:15     INFO -  test_accept_header /tests/netwerk/test/mochitests/test_accept_header.sjs?get
[task 2020-12-17T19:53:15.624Z] 19:53:15     INFO -  test_accept_header /tests/netwerk/test/mochitests/test_accept_header.sjs?style
[task 2020-12-17T19:53:15.640Z] 19:53:15     INFO -  test_accept_header /tests/netwerk/test/mochitests/test_accept_header.sjs?get
[task 2020-12-17T19:53:15.680Z] 19:53:15     INFO -  test_accept_header /tests/netwerk/test/mochitests/test_accept_header.sjs?worker
[task 2020-12-17T19:53:15.696Z] 19:53:15     INFO -  test_accept_header /tests/netwerk/test/mochitests/test_accept_header.sjs?get
[task 2020-12-17T19:53:15.813Z] 19:53:15     INFO - TEST-INFO | screentopng: exit 0
[task 2020-12-17T19:53:15.813Z] 19:53:15     INFO - TEST-UNEXPECTED-FAIL | netwerk/test/mochitests/test_accept_header.html | Accept header: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 - got "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8", expected "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8"
[task 2020-12-17T19:53:15.813Z] 19:53:15     INFO -     SimpleTest.is@SimpleTest/SimpleTest.js:500:14
[task 2020-12-17T19:53:15.813Z] 19:53:15     INFO -     test_last_request_and_continue/<@netwerk/test/mochitests/test_accept_header.html:20:7
[task 2020-12-17T19:53:15.813Z] 19:53:15     INFO - TEST-PASS | netwerk/test/mochitests/test_accept_header.html | Expected: image 
[task 2020-12-17T19:53:15.813Z] 19:53:15     INFO - Not taking screenshot here: see the one that was previously logged
[task 2020-12-17T19:53:15.813Z] 19:53:15     INFO - TEST-UNEXPECTED-FAIL | netwerk/test/mochitests/test_accept_header.html | Accept header: image/webp,*/* - got "image/avif,image/webp,*/*", expected "image/webp,*/*"
[task 2020-12-17T19:53:15.813Z] 19:53:15     INFO -     SimpleTest.is@SimpleTest/SimpleTest.js:500:14
[task 2020-12-17T19:53:15.813Z] 19:53:15     INFO -     test_last_request_and_continue/<@netwerk/test/mochitests/test_accept_header.html:20:7
[task 2020-12-17T19:53:15.814Z] 19:53:15     INFO - TEST-PASS | netwerk/test/mochitests/test_accept_header.html | Expected: style 
[task 2020-12-17T19:53:15.814Z] 19:53:15     INFO - TEST-PASS | netwerk/test/mochitests/test_accept_header.html | Accept header: text/css,*/*;q=0.1 
[task 2020-12-17T19:53:15.815Z] 19:53:15     INFO - TEST-PASS | netwerk/test/mochitests/test_accept_header.html | Expected: worker 
[task 2020-12-17T19:53:15.815Z] 19:53:15     INFO - TEST-PASS | netwerk/test/mochitests/test_accept_header.html | Accept header: */* 
[task 2020-12-17T19:53:15.815Z] 19:53:15     INFO - GECKO(3092) | MEMORY STAT | vsize 2564MB | residentFast 155MB | heapAllocated 10MB
[task 2020-12-17T19:53:15.816Z] 19:53:15     INFO - TEST-OK | netwerk/test/mochitests/test_accept_header.html | took 462ms

Comment 4

[Bogdan Tara[:bogdan_tara | bogdant]]

The following also seems to start perma failing with the backed out changes: https://treeherder.mozilla.org/logviewer?job_id=324855672&repo=autoland&lineNumber=4508

Comment 5

[Pulsebot]

Backout by [e-mail]:
https://hg.mozilla.org/mozilla-central/rev/26d8d2248fcd
Backed out changeset feef6926b977 for test_accept_header.html failures CLOSED TREE

Comment 6

[Jon Bauman [:jbauman:]]

I'm currently looking at this. The fix to test_accept_header.html is straightforward, but it led me to run a full mochitest suite and that showed some less-obvious errors. In particular image/test/mochitest/test_bug496292.html is failing, but it took me awhile (I got sidetracked by bug 1682709) to track down why.

To hopefully avoid another backout, I've just replaced all the instances of "image/webp,*/*" (our previous Accept header) in our test code with "image/avif,image/webp,*/*". I'll run another try and hopefully that one will be green.

Comment 7

[Jon Bauman [:jbauman:]]

Sadly there still seem to be some test failures that, while it's not immediately clear why they'd be affected by this, are locally reproducible only with this change. For example: devtools/client/netmonitor/test/browser_net_copy_headers.js.

So, I'm looking into those and won't try to re-land until I've got them sorted.

Comment 8

[Tom S [:evilpie]]

(In reply to Jon Bauman [:jbauman:] from comment #7)

Sadly there still seem to be some test failures that, while it's not immediately clear why they'd be affected by this, are locally reproducible only with this change. For example: devtools/client/netmonitor/test/browser_net_copy_headers.js.

That test will poll the clipboard until it finds an expected strings. When it can't find the expected string it will time out. https://searchfox.org/mozilla-central/source/devtools/client/netmonitor/test/browser_net_copy_headers.js#45

So, I'm looking into those and won't try to re-land until I've got them sorted.

Comment 9

[Jon Bauman [:jbauman:]]

Thanks Tom, I found that as well (unfortunately before I saw your comment). Not sure how I missed it the first time around, but I'm pretty sure I've addressed all the locations in test code where image/webp appears and if this next try run looks good, I'll try to land this again.

Comment 10

[Jon Bauman [:jbauman:]]

I don't think any of the remaining failures are due to the changes for this issue. However, I don't want to land a change directly before being unavailable during the holiday time, so wait on this until I'm back.

Comment 11

[Yuan Tong]

Hi! Excited to see this, but maybe bug 1654461 should be fixed first? Both libavif and squoosh.app produce full range AVIF images by default, and it's better to use full range in image encoding to prevent banding artifact.

Comment 12

[NVD]

https://code.videolan.org/videolan/dav1d/-/blob/master/NEWS
https://code.videolan.org/videolan/dav1d/-/releases

Please update to dav1d 0.8.1 if possible for faster AVIF decoding.

Comment 13

[Jon Bauman [:jbauman:]]

Per bug 1680396, we'll update to the latest dav1d version later this month

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4267ac191113
Enable AVIF support by default. r=aosmond,preferences-reviewers,necko-reviewers,valentin

Comment 15

[Ryan VanderMeulen [:RyanVM]]

Seems like something we'd want to relnote.

Comment 16

[Jon Bauman [:jbauman:]]

Indeed! Thanks, Ryan

Comment 17

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/4267ac191113

Comment 18

[Pascal Chevrel:pascalc (PTO until April 26)]

Jon, do you have a suggestion for the wording of the release note and maybe an url to an explainer we could link to from the release notes? Thanks

Comment 19

[Jon Bauman [:jbauman:]]

Hi Pascal, this is adapted from what I suggested back when AVIF was partially implemented, but disabled by default

[Why is this notable]: A new image format with excellent compression and no patent restrictions developed by the Alliance for Open Media
[Suggested wording]: Basic AVIF support is enabled in this release. Some advanced features like animated images and colorspace support is still in development. See https://bugzilla.mozilla.org/show_bug.cgi?id=1682995 and related issue for more detail. It can be disabled by setting image.avif.enabled to false in about:config.
[Links (documentation, blog post, etc)]: https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Image_types#AVIF and https://en.wikipedia.org/wiki/AV1#AV1_Image_File_Format_(AVIF)

I'm not sure if we tend to include links to non-mozilla blog posts in these kinds of notes, but https://jakearchibald.com/2020/avif-has-landed/ is a very good write up on the format generally and includes several examples.

Comment 20

[Pascal Chevrel:pascalc (PTO until April 26)]

I went with this note:

Basic AVIF support is enabled in Firefox 86. Some advanced features like animated images and colorspace support are still in development (see bug 1682995 and dependencies)

I am linking to our own documentation and adding the dev-doc-needed keyword to this bug as we will need to also add this information to https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/86 and also update https://developer.mozilla.org/docs/Web/Media/Formats/Image_types#AVIF to indicate that this is no longer behind an about:config flag.

The final release note will likely be rewritten by our marketing team for a more end-user focused wording.

Thanks!

Comment 21

[Hamish Willee]

FYI Documentation for the FF86 release of this feature is now done/being reviewed. This was mostly already done (we thought this would release in FF83). Essentially this confirms the MIME types, change to HTTP accepts, release note, removes experimental tagging etc.

Full details can be found here: https://github.com/mdn/content/issues/1726#issuecomment-769577479

Comment 22

[Nick Doyle]

I've commented over on 1443863 that it will be problematic for AVIF to be enabled by default until bugs around colour accuracy are addressed. Please reconsider enabling AVIF by default until colour is working. This will have long lasting implications for people and services who want to serve AVIF and trust the Accept header.

Comment 23

[Jeff Muizelaar [:jrmuizel]]

I agree. Are we sure we want to ship this without colorspace support?

Comment 24

[Nick Doyle]

I'm sorry to keep pushing on this so aggressively but the situation is more problematic than I had initially thought.

With the release of Firefox 86 in two days, this needs urgent attention. I would have pushed on this sooner but I was sideswiped by the fact that AVIF support was enabled by default before all the blockers for bug 1443863 were resolved.

AVIF support, as it stands now is too broken to ship.

To recap the situation:

Any image encoded with libheif (used by ImageMagick for example) will have completely inaccurate colour in Firefox. This is clearly visible in attachment 9202460 [details] and discussed in more detail in bug 1634741. This is not a problem with other browsers with AVIF support.

Colour is broken on all displays, both sRGB and wide gamut, and personally observed in both macOS and Linux X11.

These are not esoteric AVIF images or unusual input images. This happens with a plain old JPEG without accompanying ICC profile (the most common kind) encoded to AVIF with default parameters with one of the most common AVIF codecs (libheif/libaom, as used by ImageMagick for example).

The situation is made worse because this version of Firefox will start advertising AVIF support in the Accept header. In order to properly do content negotiation, servers need to trust the Accept header and assume that support for anything in the Accept header is at the lowest common denominator for browsers that advertise that format. If Firefox 86 ships with AVIF enabled today, with advertising in the Accept header for support, we now must assume that the lowest common denominator has completely inaccurate colour. This means that servers must assume that browsers advertising AVIF support in the Accept header will have broken colour. The only workaround is to use User-Agent sniffing to determine real working AVIF support which is completely antithetical to how content negotiation is supposed to work.

Similar issues made the Accept header useless for years with regards to WebP support in Chrome (around introducing features like transparency, lossless encoding, and animation that older browsers didn't support). Making the same mistake here will have very long lasting repercussions.

Image format "support" with such inaccurate colour is not "support". Rendering an image isn't meaningful if the image is rendered so incorrectly. AVIF in Firefox is not ready.

Look, I'm as excited as anyone for AVIF support in Firefox (it's why I'm pushing so hard here), and can't wait to enable it in our imaging products at Akamai, but enabling it as is today is going to do more harm than good.

Comment 25

[Stig Nygaard]

I'm a "nobody", I'm not sure my "vote" counts. But still want to say I agree with Nick. I want AVIF to succeed. To do that we must be able to trust a browser saying it can handle AVIF to show expected colors if we choose to server it AVIF instead of a fallback jpg.
I can easily accept lack of f.ex. animation-support, that's a very special case. But missing proper colorspace handling in 2021, that's a no go.

Comment 26

[Nick Doyle]

Just to be clear, these incorrect colours happen without colour profiles even being involved.

This happens in the most base of base case: untagged JPEG converted to AVIF with default settings using libheif/libaom (with ImageMagick for example) viewed on any display.

Comment 27

[Jeff Muizelaar [:jrmuizel]]

Status update: We talked about not shipping this on Friday, unfortunately it was very late in the release schedule, would have required spinning a new RC and potentially missing the release date. We still have the option of disabling this by a remotely via pref flip and we'll talk about doing that tomorrow.

It, indeed, would've been better if these concerns had been raised earlier instead of after the last RC.

Nick, since Firefox Nightly and Beta have been setting the Accept header for a while, I assume Akamai is not actually serving AVIF based off of that yet?

Comment 28

[Nick Doyle]

Akamai hasn't publicly exposed serving AVIF by the Accept header yet. Initial support is imminent. We've had to add a block for Firefox in anticipation for the 86 release. Having a misbehaving browser released will complicate matters though because of sensitivity to serving only colour accurate images even to lingering outdated browser versions.

Comment 29

[Nick Doyle]

Also, to be fair, concerns were raised 11 days ago in bug 1634741 and the impact was shrouded by bug 1443863 being still open also with related open blockers.

Comment 30

[Yuan Tong]

Would it make things any better if I can submit a patch to fix the most common cases now?

Comment 31

[Pascal Chevrel:pascalc (PTO until April 26)]

Chris, we are not going to ship AVIF in 86 tomorrow, could the dev docs be updated to reflect that? Thanks

Comment 32

[Pascal Chevrel:pascalc (PTO until April 26)]

Backed out for 86
https://hg.mozilla.org/releases/mozilla-release/rev/153c0901a573c2684bb83499b73db12fe65e2903

Comment 33

[Chris Mills [:cmills]]

Thanks :pascalc, I was reading this thread with interest, and waiting for the call on it.

I'll remove mention of it from the release notes and release blog post immediately, and get Hamish to revert any specific mentions in the docs elsewhere.

Comment 34

[Hamish Willee]

FYI, docs work "undone" once the fixes are merged. Info about what I changed in https://github.com/mdn/content/issues/1726#issuecomment-783871008. We can re-enable pretty easily by reverting those changes; though at that point you might have added support for animations etc, which would imply a few addition tidy-ups.

Comment 35

[Julien Cristau [:jcristau] (back April 22)]

Jon, can you take care of the patch for 87/88? I don't know if we want to keep the feature in nightly and/or early-beta for now, or disabled entirely.

Comment 36

[Pascal Chevrel:pascalc (PTO until April 26)]

Disabled in 86 with a backout.

Comment 37

[Jon Bauman [:jbauman:]]

(In reply to Julien Cristau [:jcristau] from comment #35)

Jon, can you take care of the patch for 87/88? I don't know if we want to keep the feature in nightly and/or early-beta for now, or disabled entirely.

I believe everything is set for now (thanks to you, Julien). AVIF remains enabled for Fx87 nightly/beta, but disabled for Fx87 release. Let me know if I'm missing something since this is my first experience with a back-out like this.

We'll shoot for enabling in Fx88 release, but make sure we have the issues that derailed the Fx86 release plan sorted out first.

Comment 38

[Julien Cristau [:jcristau] (back April 22)]

87 is currently on mozilla-beta, so AVIF is set to enabled there. I'll keep the needinfo to turn that off later this week.

Comment 39

[Kornel]

I was unable to figure out why Firefox doesn't accept my transparent AVIF images, which do work in Chrome: https://bugzilla.mozilla.org/show_bug.cgi?id=1696056

Comment 40

[Julien Cristau [:jcristau] (back April 22)]

Now disabled for 87 late beta and release:
https://hg.mozilla.org/releases/mozilla-beta/rev/58cf44cd280ff96c3df220963cc49c8e99b0f03d

Comment 41

[Ryan VanderMeulen [:RyanVM]]

Hi Jon, I just wanted to confirm that we're targeting Fx89 now and want to land the patch from comment 40 on Beta again after 88 merges there on Monday?

Comment 42

[Jon Bauman [:jbauman:]]

That is correct. Thanks for confirming.

Comment 43

[Ryan VanderMeulen [:RyanVM]]

Backed out from 88 as well for 88.0b7.
https://hg.mozilla.org/releases/mozilla-beta/rev/ddaaeb918e1f

Given that we plan to let this ride Fx89 to release and we've been handling the disabling by backing out the patch which enabled it by default, I think there's no further action required in this bug.

Comment 44

[Nick Doyle]

This would be easier to track for non-Mozilla people if this bug was not resolved until the blockers this bug depends on are also resolved. AVIF is not ready to ship until those bugs are finished.

Comment 45

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/releases/mozilla-beta/rev/181699443bb5

Comment 46

[Jon Bauman [:jbauman:]]

Hey Nick,

Sorry for the confusion here. The bug is correctly RESOLVED FIXED at the moment because AVIF is currently enabled by default in nightly, and absent intervention will be going through our normal release process to ship in Fx89. Yes, there are incomplete blocking issues and our expectation is that those will be resolved in time for shipping in Fx89. You can rest assured that this bug will get updated in response to any changes to that plan.

Comment 47

[Jon Bauman [:jbauman:]]

Attachment: Bug 1682995 - Revert Enable AVIF support by default. r=aosmond,jaws,valentin

Revert this change to turn AVIF off by default for now

Comment 48

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6646eb3b62f7
Revert Enable AVIF support by default. r=aosmond,valentin,necko-reviewers,preferences-reviewers,Gijs

Comment 49

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/6646eb3b62f7

Comment 50

[Punam Dahiya [:pdahiya]]

Revert of this bug seems to have caused bug 1702250 to regress as it relies on optimized avif image to use as background for MR1 new user onboarding flow. Is there an ETA on fix or uplift of blocking issue into Fx89, we were relying on optimized light weight avif images to show up as part of first about:welcome screen. Thanks!

Comment 51

[:Gijs (he/him)]

(In reply to Punam Dahiya [:pdahiya] from comment #50)

Revert of this bug seems to have caused bug 1702250 to regress as it relies on optimized avif image to use as background for MR1 new user onboarding flow. Is there an ETA on fix or uplift of blocking issue into Fx89, we were relying on optimized light weight avif images to show up as part of first about:welcome screen. Thanks!

Uh, if we're disabling avif on nightly by default for 89 (which is what this bug does), I don't think you can rely on it for release, so I would suggest updating the images to not use avif.

Comment 52

[Punam Dahiya [:pdahiya]]

(In reply to :Gijs (he/him) from comment #51)

(In reply to Punam Dahiya [:pdahiya] from comment #50)

Revert of this bug seems to have caused bug 1702250 to regress as it relies on optimized avif image to use as background for MR1 new user onboarding flow. Is there an ETA on fix or uplift of blocking issue into Fx89, we were relying on optimized light weight avif images to show up as part of first about:welcome screen. Thanks!

Uh, if we're disabling avif on nightly by default for 89 (which is what this bug does), I don't think you can rely on it for release, so I would suggest updating the images to not use avif.

Started patch to use webp in Bug 1705499, hopefully we see avif turned on by default in 90

Comment 53

[Timothy Nikkel (:tnikkel)]

If even we enable avif by default on release we should not be relying on it in our chrome code until at least one release after the first release with it enabled in case we need to disable it for some critical issue, even if that is unlikely we don't want to have to worry about breaking anything else.

Comment 54

[Jon Bauman [:jbauman:]]

Attachment: Bug 1682995 - Enable AVIF support by default. r=jrmuizel

Comment 55

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/bb07fcce3567
Enable AVIF support by default. r=jrmuizel,necko-reviewers,preferences-reviewers,valentin,Gijs

Comment 56

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/bb07fcce3567

Comment 57

[Ryan VanderMeulen [:RyanVM]]

Added to the Fx92 beta relnotes.

Comment 58

[benjamin.j.grant]

Shouldn't this wait for bug 1686338 to be resolved? I don't think Firefox should indicate that it supports AVIF if it doesn't support all AVIF files (i.e. animated ones).

Comment 59

[Jon Bauman [:jbauman:]]

What's implemented so far should cover the vast majority of AVIF use cases. We decided it was worth shipping based on what we thought would be most valuable to users and the format as well as provide insight into what unimplemented features we should prioritize based on usage.

Comment 60

[benjamin.j.grant]

I still don't think this is the right choice. Now Firefox will send Accept: image/avif when it doesn't support all AVIF files. This means that a site with animated AVIF files will have to look at the user agent or some other information to determine if its files will work for a given user.

Comment 61

[Marco Sousa]

Ok with release without 100% perfect, will never be perfect..

Comment 62

[benjamin.j.grant]

Obviously it'll never be perfect, but IMO Firefox should at least attempt to support the entire format before declaring that it supports the entire format. Either that or we'd need a way for Firefox to indicate to a website that it only supports non-animated AVIF files.

AVIF being enabled by default was already delayed until colors were fixed, so there is precedent for Firefox developers not wanting to roll out imperfect support for a format. I don't see why it can't wait some more.

Comment 63

[Vittorio Giovara]

(In reply to benjamin.j.grant from comment #62)

AVIF being enabled by default was already delayed until colors were fixed, so there is precedent for Firefox developers not wanting to roll out imperfect support for a format. I don't see why it can't wait some more.

One could argue that incorrect colors were detrimental to the main use case of this format (serving static images) that is becoming more and more requested. On the other hand animation is a subset of the avif format that is not widely in use (yet) and there is little to gain from putting avif support off -- there are plenty of precedents of not supporting a format fully for the sake of release.

Also that doesn't mean animation won't happen in the future, and I invite you to raise priority on the animation bug if that matter to you.

Good work Firefox team, it's great to see this out.

Comment 64

[benjamin.j.grant]

(In reply to Vittorio Giovara from comment #63)

On the other hand animation is a subset of the avif format that is not widely in use (yet)

Animated AVIF does have quite some potential, since AFAIK it allows all AV1 features including inter-frame compression. This is in contrast with other animation formats that are intra-only, so AVIF should have much higher efficiency. It's certainly one of the most exciting parts of the format to me, as opposed to lossy still AVIF (which will probably get superseded by JPEG XL for all but low-bpp images) and lossless (which is generally worse than WebP and sometimes even PNG).

there is little to gain from putting avif support off

Rolling out incomplete AVIF support now will make it harder to serve animated AVIFs forever (or as long as the Firefox version(s) that support still-only AVIF are ones you care about supporting), because it puts browsers in the wild that send an incorrect/dishonest Accept: image/avif header. Delaying support until we have animations will only keep still AVIF at the support level it has now (where it is already somewhat in use, since Chrome and friends support it), and only until Firefox rolls out complete AVIF support. Notably, the latter course of action requires no action from websites serving still or animated AVIF files.

there are plenty of precedents of not supporting a format fully for the sake of release.

I'm not familiar with the history here—could you elaborate?

I should also mention a couple other things:

• IMO a better solution would be differentiating between still and animated AVIF files by MIME type. It sounds like image/avifs was proposed for animated files, but they ended up getting the same one. If they had different types, there would be no issue here—Firefox could roll out still-only support with Accept: image/avif, and browsers that support animations too could send Accept: image/avif,image/avifs. I think supporting inter-frame compression makes animated AVIF sufficiently different from still AVIF to merit another MIME type, but I understand there's a process here and a decision was made already. I can't just will a MIME type into existence :_(
• Right now, Firefox (I have stable 90.0.2 with image.avif.enabled = true) can actually open animated AVIF files; it just displays the first frame only. This means that if Firefox is served an animated AVIF file, the only way the user could tell that it's animated would be contextual clues. If still-only AVIF support is to be rolled out, I think Firefox should display an error for animated files, so the user could at least tell something is wrong.

Good work Firefox team, it's great to see this out.

Yes, I should have said this earlier. Thank you all for your work supporting still AVIF and other modern image/video formats! I am arguing this point because I want Firefox to be the best it can be.

Comment 65

[Vittorio Giovara]

benjamin, I understand and respect your frustration about the topic, but this is not the right place to discuss them. Please open separate issues or add your thoughts to the relevant bug reports

Comment 66

[Hamish Willee]

FF92 release docs work for this feature can be tracked in https://github.com/mdn/content/issues/7744#issuecomment-898194268

A few questions. When we last tried to document this in FF86 it was characterised as "basic support only; advanced features like animated images and colorspace support yet to the implemented".

1. Is that still correct - if not, what would you say now?
2. Other than the problem in FF86 that stopped this going out, have any other major changes/improvements been added?
   • I will be updating https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Image_types#avif to remove the comments about "behind a preference". If there is anything else you think should go in that table, let me know.
3. Does this change have any impact on AV1 support in Android (e.g. https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Experimental_features#av1_support_for_firefox_on_android). I assume not - just checking.

FYI, I tried the attachment referred to in https://bugzilla.mozilla.org/show_bug.cgi?id=1682995#c24 and this still doesn't work in FF93 (https://bug1634741.bmoattachments.org/attachment.cgi?id=9202460). FF says "The image cannot be displayed because it contains errors" but Chrome 93 can display it.

Comment 67

[Jon Bauman [:jbauman:]]

A few questions. When we last tried to document this in FF86 it was characterised as "basic support only; advanced features like animated images and colorspace support yet to the implemented".

1. Is that still correct - if not, what would you say now?

Image sequences and animation (bug 1686338) aren't supported yet. Colorspace support (bug 1634741) is complete, including both full and limited range (bug 1654461) colors.

2. Other than the problem in FF86 that stopped this going out, have any other major changes/improvements been added?

In addition to the colorspace work, image transforms for mirroring and rotation (bug 1696093) have been implemented, as well as a number of under-the-hood changes. Parsing is more conformant to the specifications (bug 1701426), though there's more work coming there. There's also a new pref to adjust the compliance strictness (more on that below).

I will be updating https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Image_types#avif to remove the comments about "behind a preference". If there is anything else you think should go in that table, let me know.

I'd suggest adding the new preference image.avif.compliance_strictness. It defaults to 1, which rejects only inputs which violate requirements of the specification ("shall" language), but accepts inputs which violate recommendations ("should" language). This can be turned down to 0 to accept any inputs that we can safely and unambiguously interpret, or turned up to 2 to reject inputs which violate requirements or recommendations (a sort of validator mode).

3. Does this change have any impact on AV1 support in Android

No

FYI, I tried the attachment referred to in https://bugzilla.mozilla.org/show_bug.cgi?id=1682995#c24 and this still doesn't work in FF93 (https://bug1634741.bmoattachments.org/attachment.cgi?id=9202460). FF says "The image cannot be displayed because it contains errors" but Chrome 93 can display it.

That file is invalid per the standard due to the omission of the required Pixel Information (pixi) box. This can be checked with the AOM AVIF validator: https://gpac.github.io/ComplianceWarden-wasm/avif.html. It's possible to display it by relaxing the parsing strictness pref. See bug 1725022 for more information.

Comment 68

[Jon Bauman [:jbauman:]]

AVIF support will ship enabled by default in Firefox 92 with compliance strictness temporarily relaxed via bug 1727448.

See bug 1443863 comment 80 for the rationale

Comment 69

[Jon Bauman [:jbauman:]]

Attachment: Bug 1682995 - Revert Enable AVIF support by default. r=aosmond,jaws

Backed out changeset bb07fcce3567

Unfortunately we didn't discover bug 1729071 early enough to fix it and the
impact is likely too great to want to continue with release.

Comment 70

[Jon Bauman [:jbauman:]]

Sadly, we're going to have to pull AVIF by default support for 92. See bug 1729071 comment 4 for the reasoning

Comment 71

[Ryan VanderMeulen [:RyanVM]]

Backed out for 92.0rc3. It remains enabled by default for 93+. Also moved from the Fx92 to the Fx93 relnotes.
https://hg.mozilla.org/releases/mozilla-release/rev/74a9748f90655e731a34c298948869e67ceaa102