Bugzilla

tl;dr the current plan for AVIF in Firefox is:
1. Ship AVIF enabled by default in [Firefox 92](https://fx-trains.herokuapp.com/release/?version=92) (releasing September 7, 2021) but with [`image.avif.compliance_strictness`](https://searchfox.org/mozilla-central/rev/4cca5d2f257c6f1bcef50a0debcbd66524add703/modules/libpref/init/StaticPrefList.yaml#5693-5698) default changed from 1 (normal) to 0 (maximally permissive). See tracking bug XXX (to be filed).
2. Add telemetry to determine what fraction of images would be rejected and why if `image.avif.compliance_strictness` were returned to 1. Note that this setting only rejects images which are invalid according to [the specifications](https://bugzilla.mozilla.org/show_bug.cgi?id=avif-compliance). See bug 1696045 (and likely follow-ups).
3. After evaluating the telemetry for a release or two and working with the sources of invalid files, add targeted exceptions for the issues that cannot reasonably be fixed via regenerating files or amending specifications (like bug 1725022 and bug 1727033).
4. No later than [Firefox 94](https://fx-trains.herokuapp.com/release/?version=94) (releasing November 2, 2021), revert the default value of `image.avif.compliance_strictness` to 1; hopefully for good. See tracking bug XXX (to be filed)

Some rationale:
Given that AVIF is a very new format, there are only a few independent implementations of readers and writers. Part of what determines whether it will be broadly adopted in the real world is how well they all interoperate. Even for openly-developed libraries, testing every reader/writer combination for compatibility is untenable, so we depend on specifications and independent validators like [Compliance Warden](https://gpac.github.io/ComplianceWarden-wasm/avif.html) for this.

Though it can be tempting to make readers as permissive as possible (people just want to see the images!), this comes at the cost of normalizing invalid files, making the standards less useful and making future implementations more challenging. Since the number of AVIFs in circulation is only going to increase, it's generally not feasible to make implementations stricter in the future. That means now is the time to be as strict as is reasonably practical in order to surface as many implementation errors as early as possible and help make the format as valuable and easy to work with as we can.

tl;dr the current plan for AVIF in Firefox is:
1. Ship AVIF enabled by default in [Firefox 92](https://fx-trains.herokuapp.com/release/?version=92) (releasing September 7, 2021) but with [`image.avif.compliance_strictness`](https://searchfox.org/mozilla-central/rev/4cca5d2f257c6f1bcef50a0debcbd66524add703/modules/libpref/init/StaticPrefList.yaml#5693-5698) default changed from 1 (normal) to 0 (maximally permissive). See tracking bug 1727448.
2. Add telemetry to determine what fraction of images would be rejected and why if `image.avif.compliance_strictness` were returned to 1. Note that this setting only rejects images which are invalid according to [the specifications](https://bugzilla.mozilla.org/show_bug.cgi?id=avif-compliance). See bug 1696045 (and likely follow-ups).
3. After evaluating the telemetry for a release or two and working with the sources of invalid files, add targeted exceptions for the issues that cannot reasonably be fixed via regenerating files or amending specifications (like bug 1725022 and bug 1727033).
4. No later than [Firefox 94](https://fx-trains.herokuapp.com/release/?version=94) (releasing November 2, 2021), revert the default value of `image.avif.compliance_strictness` to 1; hopefully for good. See tracking bug XXX (to be filed)

Some rationale:
Given that AVIF is a very new format, there are only a few independent implementations of readers and writers. Part of what determines whether it will be broadly adopted in the real world is how well they all interoperate. Even for openly-developed libraries, testing every reader/writer combination for compatibility is untenable, so we depend on specifications and independent validators like [Compliance Warden](https://gpac.github.io/ComplianceWarden-wasm/avif.html) for this.

Though it can be tempting to make readers as permissive as possible (people just want to see the images!), this comes at the cost of normalizing invalid files, making the standards less useful and making future implementations more challenging. Since the number of AVIFs in circulation is only going to increase, it's generally not feasible to make implementations stricter in the future. That means now is the time to be as strict as is reasonably practical in order to surface as many implementation errors as early as possible and help make the format as valuable and easy to work with as we can.

tl;dr the current plan for AVIF in Firefox is:
1. Ship AVIF enabled by default in [Firefox 92](https://fx-trains.herokuapp.com/release/?version=92) (releasing September 7, 2021) but with [`image.avif.compliance_strictness`](https://searchfox.org/mozilla-central/rev/4cca5d2f257c6f1bcef50a0debcbd66524add703/modules/libpref/init/StaticPrefList.yaml#5693-5698) default changed from 1 (normal) to 0 (maximally permissive). See tracking bug 1727448.
2. Add telemetry to determine what fraction of images would be rejected and why if `image.avif.compliance_strictness` were returned to 1. Note that this setting only rejects images which are invalid according to [the specifications](https://bugzilla.mozilla.org/show_bug.cgi?id=avif-compliance). See bug 1696045 (and likely follow-ups).
3. After evaluating the telemetry for a release or two and working with the sources of invalid files, add targeted exceptions for the issues that cannot reasonably be fixed via regenerating files or amending specifications (like bug 1725022 and bug 1727033).
4. No later than [Firefox 94](https://fx-trains.herokuapp.com/release/?version=94) (releasing November 2, 2021), revert the default value of `image.avif.compliance_strictness` to 1; hopefully for good. See tracking bug 1727449.

Some rationale:
Given that AVIF is a very new format, there are only a few independent implementations of readers and writers. Part of what determines whether it will be broadly adopted in the real world is how well they all interoperate. Even for openly-developed libraries, testing every reader/writer combination for compatibility is untenable, so we depend on specifications and independent validators like [Compliance Warden](https://gpac.github.io/ComplianceWarden-wasm/avif.html) for this.

Though it can be tempting to make readers as permissive as possible (people just want to see the images!), this comes at the cost of normalizing invalid files, making the standards less useful and making future implementations more challenging. Since the number of AVIFs in circulation is only going to increase, it's generally not feasible to make implementations stricter in the future. That means now is the time to be as strict as is reasonably practical in order to surface as many implementation errors as early as possible and help make the format as valuable and easy to work with as we can.