feat(images): open AVIF

[skjnldsv]

Picks up nextcloud/viewer#1973 by @JanisPlayer, open since September 2023 and closed this morning with the repo. The question that held it up there was whether browser support was good enough; it is, and I measured it rather than reading a table.

A 64x64 AVIF, fed to both paths the viewer and the editor use:

engine	<img>	createImageBitmap
Chromium	decodes, 64x64	decodes, 64x64
Firefox	decodes, 64x64	decodes, 64x64

So it goes in browserSupportedMimes, the list of formats shown from the file itself. That matters, because the other list would have made it worse rather than better: previewSupportedMimes is filtered against the server's enabled providers, and nothing in Nextcloud previews AVIF. HEIC.php mentions avif at line 107, but that is a sanity check on what ImageMagick reports for a file claiming to be HEIC; its getMimeType() is /image\/(x-)?hei(f|c)/. Imaginary::supportedMimeTypes() does not list it either. Listed as preview-supported, AVIF would have been filtered straight back out on every server.

Closes nextcloud/viewer#407.

The catch, which is not in this repo

An .avif file may never reach the viewer as image/avif in the first place. resources/config/mimetypemapping.dist.json in server has no avif entry, and Detection::detectPath() returns application/octet-stream for an extension it does not know:

return $this->mimeTypes[$extension][0] ?? 'application/octet-stream';

detect() then falls back to content sniffing, so whether it is labelled correctly depends on the server's libmagic and on which code path stored the file. A one-line addition to the mapping would settle it. I have not opened that PR; say the word and I will.

I have also not tested this against a live server, only against the playground, so that is the bit worth checking when you try it.

On jp2, the other half of #2587

Not included here, because by the same rule it qualifies for neither list.

No engine decodes it: the same probe on a JPEG 2000 file fails through both <img> and createImageBitmap, in Chromium and in Firefox. And nothing previews it either. jp2 appears in server only in mimetypemapping.dist.json and RepairMimeTypes.php; there is no provider, in core or in Imaginary, whose mime regex matches it.

So an image/jp2 entry in previewSupportedMimes would be filtered out on every stock server and show nothing. It is harmless, since the filter is self-gating, and it would light up on its own the day a provider exists, but today it is an entry that does nothing. I left it out rather than add dead configuration. Happy to add it if you would rather have it waiting.

👾 This pull request was assisted by Claude Code, commits carry an Assisted-by trailer.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.11%. Comparing base (ed33bbe) to head (12fbe81).

Additional details and impacted files

@@           Coverage Diff           @@
##             main      #50   +/-   ##
=======================================
  Coverage   88.10%   88.11%           
=======================================
  Files          37       37           
  Lines        2624     2625    +1     
  Branches      558      558           
=======================================
+ Hits         2312     2313    +1     
  Misses        305      305           
  Partials        7        7           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.