Created attachment 416391 [details]
Some WebP images can no longer be read in iOS 14.3.
There was no problem until iOS 14.2.
We have prepared a page to check the problem.
User Agent on my device : Mozilla/5.0 (iPhone; CPU iPhone OS 14_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.2 Mobile/15E148 Safari/604.1
*** Bug 220317 has been marked as a duplicate of this bug. ***
Thank you for the report! Marking as invalid because this was determined to be an issue in system frameworks below WebKit. This will continue to be investigated by Apple internally.
*** Bug 220629 has been marked as a duplicate of this bug. ***
*** Bug 220775 has been marked as a duplicate of this bug. ***
Cloudinary is attempting to work around this issue by turning off WebP support to affected clients.
If this is indeed about the underlying OS frameworks, rather than the browser version, as far as we can tell it appeared sometime after MacOS 11.0.1 and before or in 11.1.0. All we have been able to narrow down on the iOS side is ≥14.0.
If you have additional guidance on which versions of the OSes are affected, so that we can prevent Safari users from receiving broken images, it would be much appreciated!
*** Bug 220853 has been marked as a duplicate of this bug. ***
I have some more version numbers, although I'm uncertain if they give anything not already known.
Fails (i.e., image doesn't load): iOS 14.3, iOS 14.4, macOS 11.1
Works: iOS 14.0.1
I'm uploading a second image which fails in the same scenarios as the page linked in the initial report.
Created attachment 418482 [details]
A second bad WebP image
Downloaded from <https://commons.wikimedia.org/wiki/File:Chessboard480.svg> via cURL:
curl 'https://upload.wikimedia.org/wikipedia/commons/thumb/d/d7/Chessboard480.svg/416px-Chessboard480.svg.png' -H 'Accept: image/webp' --output 'WebP loading error.webp'
Replacing "416" with "200" gives a WebP file that /does/ work. I haven't tested much further beyond that.
Re: Perry in Comment #9
When I replace "416" with "200" I actually get a PNG back instead of a WebP? Not sure what decision making is happening on the server...
I compiled all of the example images here, plus a couple that we've received from Cloudinary customers:
The one pattern that jumps out to me is that most of the broken images seem to have palletized color information in some channel; sometimes in the alpha channel (e.g., "lamp"), other times in color channels (e.g., "stripes", "chessboard").
Two possible exceptions are "blue" and "text". Looking at the image content I would kind of expect indexing (they both have very limited color palletes), but their webpinfos don't mention indexing as a transform, as every other image does...
If anyone from Apple could confirm our understanding of which versions of MacOS and iOS are affected, or share any information that could give us a sense of either the scale or cause of the problem, it would be *very* helpful.
(In reply to Eric Portis from comment #10)
> Re: Perry in Comment #9
> When I replace "416" with "200" I actually get a PNG back instead of a WebP?
> Not sure what decision making is happening on the server...
If the Accept header is set to image/webp it serves it as a webp for me—going to the URL in a browser seems to serve it as a PNG. (See the curl command in comment 8.)
I'm not super confident that there'll be too much follow-up on the bug itself, especially as this isn't even a WebKit issue, but an internal one. I'm happy to be proved wrong though ;).
Re: Perry in Comment #10
% curl 'https://upload.wikimedia.org/wikipedia/commons/thumb/d/d7/Chessboard480.svg/200px-Chessboard480.svg.png' -H 'Accept: image/webp' --output 'isthisa.webp'; webpinfo isthisa.webp; exiftool isthisa.webp
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 668 100 668 0 0 3976 0 --:--:-- --:--:-- --:--:-- 3952
ExifTool Version Number : 12.00
File Name : isthisa.webp
Directory : .
File Size : 668 bytes
File Modification Date/Time : 2021:01:27 11:47:56-08:00
File Access Date/Time : 2021:01:27 11:47:56-08:00
File Inode Change Date/Time : 2021:01:27 11:47:56-08:00
File Permissions : rw-r--r--
File Type : PNG
File Type Extension : png
MIME Type : image/png
Image Width : 200
Image Height : 200
Bit Depth : 8
Color Type : RGB
Compression : Deflate/Inflate
Filter : Adaptive
Interlace : Noninterlaced
Background Color : 255 255 255
Image Size : 200x200
Megapixels : 0.040
Tried my luck at creating WebPs that fail today... had some luck but am more confused now than ever.
Created attachment 421723 [details]
Solid black color
This is what cwebp spits out for a PNG with purely black color.
Created attachment 421724 [details]
Solid hex 121212 color
And this is even smaller image filled only with RGB hex 121212 color.
fwiw to anyone looking into this issue: an OS upgrade to 14.5.1 appears to have resolved this bug for me.
Created attachment 454255 [details]
Example of a webp image that is not working on Safari
This issue appears to have been fully fixed in macOS 13 Ventura.
However, today I discovered a seemingly-related issue, affecting JPEG2000s.