unsupported image types preload (AVIF and JXL)
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
People
(Reporter: jsnkuhn, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0
Steps to reproduce:
Set a preload link for browsers that support AVIF: <link rel="preload" href="https://tracker.randomania.net/dwr/images/alefgard_crop_test.avif" as="image" type="image/avif">
https://codepen.io/jsnkuhn/full/RwpNegy
Actual results:
Firefox downloaded the AVIF (wasting resources) but then could not load as a background image because it's not supported yet.
Expected results:
MDN article states that browsers should ignore `<link rel="preload"> for non supported mime types.
https://developer.mozilla.org/en-US/docs/Web/HTML/Preloading_content#including_a_mime_type
|
||
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::ImageLib' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
|
||
Comment 2•3 years ago
•
|
||
avif support should be turned on soon (in fact it has been on in general, but was turned off for a bit), so I expect this bug will get resolved by enabling avif.
Added jpeg xl (.jxl) and webp2 (.wp2) preloads to the codepen from above. Both he AVIF and the JXL show up in the network panel as downloaded even though neither are technically yet supported. The WEBP2 is skipped as it should be. Seems to me that this shows this is not just an AVIF issue.
|
|
||
Updated•3 years ago
|
new test with just straight <img> tags: https://codepen.io/jsnkuhn/pen/gOmpWqZ?editors=1000
The JXL and AVIF download but can't be rendered.
So this is not preload related at all. I guess maybe just something about the way the headers are being set while ya'll work on implementing these new file types??
I wonder if this or something similar is what led chrome to add the ability to toggle unsupported images in dev tools?: https://developer.chrome.com/blog/new-in-devtools-88/#emulate-image
Either way, especially on mobile, waistful downloads like this can literally end up costing folk money in the long run.
|
||
Updated•3 years ago
|
Just looked up the definition of S3 and am a little confused. What "work around" exists for this?
|
|
||
Updated•3 years ago
|
|
|
||
Comment 7•3 years ago
|
||
(In reply to jsnkuhn from comment #4)
new test with just straight
<img>tags: https://codepen.io/jsnkuhn/pen/gOmpWqZ?editors=1000The JXL and AVIF download but can't be rendered.
So this is not preload related at all.
We can't judge from the extension on the url, the web expects browsers to download and render images with no extensions in the url etc.
ahh, apologies. It is downloading the WP2 as an img it's just not showing up in images in the network panel.
|
Reporter | |
Comment 10•3 years ago
|
||
Testing with just <picture> to get around the above issue:
no preload only the png loads: https://codepen.io/jsnkuhn/pen/gOmrJYa
WITH preload unsupported images download: https://codepen.io/jsnkuhn/pen/abJZvQB
same test but with css image-set() and type() (FF89 only)
no preload only the png loads: https://codepen.io/jsnkuhn/pen/VwpaOLo
WITH preload unsupported images download: https://codepen.io/jsnkuhn/pen/eYvzpeY
so... yes this is a preload issue?
|
|
Reporter | |
Comment 11•3 years ago
|
||
I'm guessing that the reason WP2 isn't showing in the network image panel is the "octet-stream" type. This will probably fix itself as google solidifies WP2 and FF looks into implimenting.
Stable FF will soon support AVIF so the results of the above codepens will change. But the main issue of non-stuported images loading from <preload> still exists.
Description
•