[webkit-changes] [WebKit/WebKit] 84f259: Cherry-pick 258586 at main (7d40f6d46408). rdar://987...

[Tim Horton]

  Branch: refs/heads/safari-7615.1.16.1-branch
  Home:   https://github.com/WebKit/WebKit
  Commit: 84f259c3d8371e4dde443c830ddb8f196045b914
      https://github.com/WebKit/WebKit/commit/84f259c3d8371e4dde443c830ddb8f196045b914
  Author: Tim Horton <thorton at apple.com>
  Date:   2023-01-13 (Fri, 13 Jan 2023)

  Changed paths:
    M Source/WebCore/platform/graphics/BifurcatedGraphicsContext.cpp
    M Source/WebCore/platform/graphics/BifurcatedGraphicsContext.h
    M Source/WebCore/platform/graphics/GraphicsContext.h
    M Source/WebCore/platform/graphics/cg/GraphicsContextCG.cpp
    M Source/WebCore/platform/graphics/cg/GraphicsContextCG.h
    M Source/WebCore/platform/graphics/cg/ImageBufferIOSurfaceBackend.cpp
    M Source/WebKit/Shared/RemoteLayerTree/CGDisplayListImageBufferBackend.mm

  Log Message:
  -----------
  Cherry-pick 258586 at main (7d40f6d46408). rdar://98798050

    Canvases painted into CG display list image buffers don't ever update
    https://bugs.webkit.org/show_bug.cgi?id=250196
    rdar://98798050

    Reviewed by Simon Fraser and Dean Jackson.

    WebKit has long accidentally depended on the combination of two somewhat
    unusual behavioral quirks in CGIOSurfaceContext:

    1) (Source) If you make a CGImageRef from one CGIOSurfaceContext via
    CGIOSurfaceContextCreateImage, and mutate the original IOSurface under the hood
    (or in a different process) in a way that CGIOSurfaceContext does not know,
    CGIOSurfaceContextCreateImage will return the same CGImageRef when called later.

    2) (Destination) If you make a CGImageRef from one CGIOSurfaceContext via
    CGIOSurfaceContextCreateImage, paint it into a different CGIOSurfaceContext,
    then mutate the original IOSurface, and paint the same CGImageRef again,
    the updated IOSurface contents will be used the second time.

    The second quirk has never worked with unaccelerated CoreGraphics bitmap context
    destinations. Instead, in the unaccelerated case, the CGImageRef acts as a
    snapshot of the surface at the time it was created.

    We've long had code to handle this, forcing CGIOSurfaceContextCreateImage to
    re-create the CGImageRef each time we paint it (by drawing an empty rect into
    the CGIOSurfaceContext), working around quirk #1 and thus bypassing quirk #2,
    if we're painting into an unaccelerated backing store.

    It turns out our CG display list backing store implementation behaves like a
    CG bitmap context (without quirk #2), and so currently any IOSurfaces painted into
    CG display list backing store from a CGImageRef created by CGIOSurfaceContextCreateImage
    (but not -CreateImageReference) become stale if painted multiple times.

    To avoid this, extend the workaround to apply to any destination context that
    claims that it needs the workaround, and use it whenever painting an IOSurface
    into anything other than a CGIOSurfaceContext.

    * Source/WebCore/platform/graphics/BifurcatedGraphicsContext.cpp:
    (WebCore::BifurcatedGraphicsContext::needsCachedNativeImageInvalidationWorkaround):
    * Source/WebCore/platform/graphics/BifurcatedGraphicsContext.h:
    Make BifurcatedGraphicsContext assume the more conservative mode of its two children.

    * Source/WebCore/platform/graphics/GraphicsContext.h:
    (WebCore::GraphicsContext::needsCachedNativeImageInvalidationWorkaround):
    Assume that by default, GraphicsContexts need the workaround.

    * Source/WebCore/platform/graphics/cg/GraphicsContextCG.cpp:
    (WebCore::GraphicsContextCG::needsCachedNativeImageInvalidationWorkaround):
    * Source/WebCore/platform/graphics/cg/GraphicsContextCG.h:
    GraphicsContextCG needs the workaround, except in the IOSurface->IOSurface case.

    * Source/WebCore/platform/graphics/cg/ImageBufferIOSurfaceBackend.cpp:
    (WebCore::ImageBufferIOSurfaceBackend::finalizeDrawIntoContext):
    Confer with the GraphicsContext about its need for the workaround
    instead of hardcoding the behavior here.

    * Source/WebKit/Shared/RemoteLayerTree/CGDisplayListImageBufferBackend.mm:
    CG display list graphics contexts need the workaround.

    Canonical link: https://commits.webkit.org/258586@main

Canonical link: https://commits.webkit.org/257979.16@safari-7615.1.16.1-branch


  Commit: 2b6ca2a2e4687b85347e33eb9eb0b113d3e5586b
      https://github.com/WebKit/WebKit/commit/2b6ca2a2e4687b85347e33eb9eb0b113d3e5586b
  Author: Tim Horton <thorton at apple.com>
  Date:   2023-01-13 (Fri, 13 Jan 2023)

  Changed paths:
    M Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm

  Log Message:
  -----------
  Cherry-pick 258521 at main (1a1e7ad8f8a7). rdar://96702143

    Live-ish resize sometimes pops to unexpected scroll position even if layout width doesn't change
    https://bugs.webkit.org/show_bug.cgi?id=250153
    rdar://96702143

    Reviewed by Wenson Hsieh.

    * Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm:
    (-[WKWebView _updateScrollViewForTransaction:]):
    By default, UIScrollView pins the center of the view when you change zoomScale.
    When doing a live resize with a fixed layout width, the zoomScale changes on
    every resize. Resizes normally pin the top edge of the content (or rather,
    don't try to adjust the content offset -- at least until scroll anchoring
    comes along), so this leads to surprising jumps. To fix this, when
    web-process-originated scale changes occur, pin the vertical scroll position
    to the top edge of the content, instead of the center. I don't expect any
    clients are depending on the existing behavior, and hope that this
    will be purely an improvement.

    (-[WKWebView _didCommitLayerTree:]):
    Like animated resize, bail from updating scroll view parameters and various
    other incoming-commit-related things until *after* the live resize finishes.
    This avoids us calling _updateScrollViewForTransaction and adjusting zoomScale
    while the resize animation view is installed, which results in our scroll view
    thinking that the current zoomScale is 1, and throwing all the math off, causing
    further unexpected scrolling.

    (-[WKWebView _updateVisibleContentRects]):
    Fix this logging to indicate whether whether we're deferring geometry updates
    for any reason; an earlier patch changed the condition but not the log.

    Canonical link: https://commits.webkit.org/258521@main

Canonical link: https://commits.webkit.org/257979.17@safari-7615.1.16.1-branch


  Commit: 68ba9383acdc717014d07c34c6dd3e189ed72d12
      https://github.com/WebKit/WebKit/commit/68ba9383acdc717014d07c34c6dd3e189ed72d12
  Author: Tim Horton <thorton at apple.com>
  Date:   2023-01-13 (Fri, 13 Jan 2023)

  Changed paths:
    M Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm

  Log Message:
  -----------
  Cherry-pick 258687 at main (6e41546bc076). rdar://103977580

    REGRESSION (258521 at main): Can end up scrolled to an invalid offset, blank space above page
    https://bugs.webkit.org/show_bug.cgi?id=250335
    rdar://103977580

    Reviewed by Dean Jackson and Megan Gardner.

    * Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm:
    (-[WKWebView _updateScrollViewForTransaction:]):
    Ensure that we don't scroll to an invalid offset, the same way we do elsewhere.

    Canonical link: https://commits.webkit.org/258687@main

Canonical link: https://commits.webkit.org/257979.18@safari-7615.1.16.1-branch


Compare: https://github.com/WebKit/WebKit/compare/b04e12775477...68ba9383acdc