[webkit-changes] [WebKit/WebKit] dd5454: [macOS Downlevels] AVIF and JPEG XL images can get...

Myles C. Maxfield noreply at github.com
Mon Oct 9 12:52:45 PDT 2023


  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: dd54547c2b7b1ede124b744778c0857e675271aa
      https://github.com/WebKit/WebKit/commit/dd54547c2b7b1ede124b744778c0857e675271aa
  Author: Myles C. Maxfield <mmaxfield at apple.com>
  Date:   2023-10-09 (Mon, 09 Oct 2023)

  Changed paths:
    A LayoutTests/http/tests/images/repaint-garbled-expected.html
    A LayoutTests/http/tests/images/repaint-garbled.html
    A LayoutTests/http/tests/images/resources/green-313x313.jxl
    M Source/WebCore/platform/graphics/cg/ImageBackingStoreCG.cpp

  Log Message:
  -----------
  [macOS Downlevels] AVIF and JPEG XL images can get corrupted
https://bugs.webkit.org/show_bug.cgi?id=259698
<rdar://problem/113007909>

Reviewed by Said Abou-Hallawa.

When we create a `NativeImage`, we call `ImageSource::frameAtIndexCacheIfNeeded()` with
a caching mode of `MetadataAndImage`. This does 2 things:
1. `auto platformImage = m_decoder->createFrameImageAtIndex(index, subsamplingLevelValue, decodingOptions);`
2. `cachePlatformImageAtIndex(WTFMove(platformImage), index, subsamplingLevelValue, DecodingOptions(DecodingMode::Synchronous));`
ImageSource owns its own cache of `Vector<ImageFrame, 1> m_frames;` whereas
`ScalableImageDecoder` owns its own
`Vector<ScalableImageDecoderFrame, 1> m_frameBufferCache`. Therefore, the output of
`createFrameImageAtIndex()` may be expected to outlive the `ImageDecoder` it came from.
However, `createFrameImageAtIndex()` indirectly calls into `ImageBackingStore::image()`
which creates the `CGImage` with a `CGDataProvider` that points into the
`ImageBackingStore`, which is owned by the `m_frameBufferCache` which is owned by the
`ScalableImageDecoder`. So, when the `ImageSource` destroys its `ImageDecoder`, it blows
away the contents of the `CGImage`s being cached, but the images themselves live on
inside the `ImageSource` itself. That leads to this kind of corruption.

The solution is to make the `CGImage` retain its backing data.

* LayoutTests/http/tests/images/repaint-garbled-expected.html: Added.
* LayoutTests/http/tests/images/repaint-garbled.html: Added.
* LayoutTests/http/tests/images/resources/green-313x313.jxl: Added.
* Source/WebCore/platform/graphics/cg/ImageBackingStoreCG.cpp:
(WebCore::ImageBackingStore::image const):

Originally-landed-as: 265870.229 at safari-7616-branch (e633a9de382d). rdar://116422568
Canonical link: https://commits.webkit.org/269091@main




More information about the webkit-changes mailing list