Bug 220330 – [ Big Sur ] fast/images/webp-as-image.html is failing

• Status: RESOLVED
• Resolution: FIXED
• Component: Images

[Truitt Savell]

fast/images/webp-as-image.html

This test is failing on Big Sur Constantly. it looks like this image is not loading. 

History:
https://results.webkit.org/?suite=layout-tests&test=fast%2Fimages%2Fwebp-as-image.html

Diff:
https://build.webkit.org/results/Apple-BigSur-Release-WK2-Tests/r271146%20(753)/fast/images/webp-as-image-diffs.html

[Radar WebKit Bug Importer]

<rdar://problem/72818152>

[Truitt Savell]

Modified expectation in https://trac.webkit.org/changeset/271155/webkit

[Said Abou-Hallawa]

I can't reproduce the failure on macOS 11.0.

But the bots have build macOS 11.1 (20C69) see https://build.webkit.org/buildslaves/bot1024.

[Szymon Witamborski]

Created attachment 419649 [details]
Script that searches for last good and first bad webp image that fails to be decoded on Big Sur

We found out that Safari was failing to load some lossless webp images, most of the time they were simple single or two-colour images. It was also failing only from a certain size but different depending on content.

When trying to open these images with Preview, it was also failing so that'd point for the bug to be system-level.

I wrote a simple script to generate images with ImageMagick and check if they open with sips -i (normally used to generate thumbnails). This script also binary-searches for last good and first bad images and outputs an HTML file to be used in a browser.

From some manual testing done first it looked like breaking point was independent of aspect ratio but rather only depends on final number of pixels in the image, hence the script generates a 1px-high images and only width is variable. 

Breaking points depend on the actual colour value used. The script only uses some simple examples but could be easily tweaked to test other values (hex values work too). For some it'll go beyond 16383 which is beyond max edge size of webp image so it might be necessary to adjust height of generated images.

Here's a live version on codepen of the generated page:
https://codepen.io/brainshave/pen/RwoaXow

And all edge files in a GH gist:
https://gist.github.com/brainshave/04ae8279a4b16e72897ebfb5b382bbd1

Tested on macOS 11.1 and 11.2 on both Safari 14.0.3 and Safari TP 119. All other browsers process these images without issue.

[Szymon Witamborski]

Created attachment 419651 [details]
Test HTML file for local browser testing

Expected output from the page: (Firefox 85, Chrome 88)

✅black_11333.webp 
✅black_11334.webp
✅white_12666.webp
✅white_12667.webp
✅red_12000.webp
✅red_12001.webp
✅green_12000.webp
✅green_12001.webp
✅blue_12000.webp
✅blue_12001.webp

Safari 14.0.3 and Safari TP 119 on Big Sur 11.2 (Intel MBP)

✅black_11333.webp
❌black_11334.webp
✅white_12666.webp
❌white_12667.webp
✅red_12000.webp
❌red_12001.webp
✅green_12000.webp
❌green_12001.webp
✅blue_12000.webp
❌blue_12001.webp

[Andreas]

We found a similar issue in our testing last week when trying to enable webp images for our website. Here is the codepen https://codepen.io/grunewald/pen/ExNyvOr all images marked "broken" render fine in Chrome and Firefox but do not render in iOS14 Safari, we weren't able to test on Big Sur. Hope this adds additional data points to this issue. 

We validated the webp images and none of them seem to be broken. We even generated some ourselves with the cwebp tool and could reproduce the issue sometimes.

Happy to support in debugging and testing. 
-Andreas

[Andreas]

I just tested with the latest iOS 14.5 beta and can no longer reproduce the issue. Can anyone confirm that this is fixed?

[Sam Sneddon [:gsnedders]]

Indeed, this was fixed in iOS 14.5 (via rdar://72485913)