[webkit-changes] [WebKit/WebKit] d37199: Versioning.

Tue May 14 14:28:34 PDT 2024

  Branch: refs/heads/safari-7619.1.5.6-branch
  Home:   https://github.com/WebKit/WebKit
  Commit: d371998f7deca077c617eafd6bbfef59ed89c1ec
      https://github.com/WebKit/WebKit/commit/d371998f7deca077c617eafd6bbfef59ed89c1ec
  Author: Myah Cobbs <mcobbs at apple.com>
  Date:   2024-03-11 (Mon, 11 Mar 2024)

  Changed paths:
    M Configurations/Version.xcconfig

  Log Message:
  -----------
  Versioning.

Identifier: 273664.1360 at safari-7619.1.5.6-branch


  Commit: 2994a63f6a6eebb415643193ac34895dd0a779c5
      https://github.com/WebKit/WebKit/commit/2994a63f6a6eebb415643193ac34895dd0a779c5
  Author: Myah Cobbs <mcobbs at apple.com>
  Date:   2024-03-11 (Mon, 11 Mar 2024)

  Changed paths:
    M Configurations/Version.xcconfig

  Log Message:
  -----------
  Correct Versioning.


  Commit: a7d8aa97cc3dd9294dc198f0bf244b6ebc6efde7
      https://github.com/WebKit/WebKit/commit/a7d8aa97cc3dd9294dc198f0bf244b6ebc6efde7
  Author: Brian Weinstein <bweinstein at apple.com>
  Date:   2024-03-11 (Mon, 11 Mar 2024)

  Changed paths:
    M Source/WebKit/WebProcess/Extensions/WebExtensionContextProxy.cpp

  Log Message:
  -----------
  Cherry-pick 5e8c33f6e1ce. rdar://123409359

    Check both browser and chrome objects in enumerateFramesAndNamespaceObjects
    https://bugs.webkit.org/show_bug.cgi?id=270657
    rdar://123409359

    Reviewed by Timothy Hatcher.

    Some extensions use a polyfill to overwrite the browser object with their own proxy. The Blue Canoe extension was doing this,
    and it led to WebExtensionContextProxy::enumerateFramesAndNamespaceObjects not being able to find the namespace object for the extension,
    since we were only checking the `browser` object.

    To fix this, check both `browser` and `chrome`, and use whichever one is valid.

    * Source/WebKit/WebProcess/Extensions/WebExtensionContextProxy.cpp:
    (WebKit::WebExtensionContextProxy::enumerateFramesAndNamespaceObjects):

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

Identifier: 273664.1362 at safari-7619.1.5.6-branch


  Commit: 2704ec5246abb5d74b261b18fc88cc555006e28d
      https://github.com/WebKit/WebKit/commit/2704ec5246abb5d74b261b18fc88cc555006e28d
  Author: Tim Horton <thorton at apple.com>
  Date:   2024-03-11 (Mon, 11 Mar 2024)

  Changed paths:
    M Source/WebKit/GPUProcess/graphics/RemoteImageBufferSet.cpp
    M Source/WebKit/GPUProcess/graphics/RemoteImageBufferSet.h
    M Source/WebKit/GPUProcess/graphics/RemoteRenderingBackend.cpp
    M Source/WebKit/GPUProcess/graphics/RemoteRenderingBackend.h

  Log Message:
  -----------
  Cherry-pick b46e324ca99c. rdar://122577452

    Apply 274319 at main to GPU-process rendered layers
    https://bugs.webkit.org/show_bug.cgi?id=270680
    rdar://122577452

    Reviewed by Megan Gardner and Richard Robinson.

    * Source/WebKit/GPUProcess/graphics/RemoteImageBufferSet.cpp:
    (WebKit::RemoteImageBufferSet::ensureBufferForDisplay):
    (WebKit::RemoteImageBufferSet::ensureDynamicContentScalingResourceCache):
    * Source/WebKit/GPUProcess/graphics/RemoteImageBufferSet.h:
    * Source/WebKit/GPUProcess/graphics/RemoteRenderingBackend.cpp:
    (WebKit::RemoteRenderingBackend::allocateImageBuffer):
    (WebKit::RemoteRenderingBackend::createImageBuffer):
    * Source/WebKit/GPUProcess/graphics/RemoteRenderingBackend.h:
    Copy the fix from 274319 at main into RemoteImageBufferSet, to fix the bug for
    the GPU-process-enabled case.

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

Identifier: 273664.1363 at safari-7619.1.5.6-branch


  Commit: b1493cd55783dbd7ee61bf1bb016bd0f045a5400
      https://github.com/WebKit/WebKit/commit/b1493cd55783dbd7ee61bf1bb016bd0f045a5400
  Author: Ada Chan <adachan at apple.com>
  Date:   2024-03-11 (Mon, 11 Mar 2024)

  Changed paths:
    M Source/WebCore/page/Page.cpp
    M Source/WebCore/page/Page.h
    M Source/WebKit/WebProcess/WebPage/WebPage.cpp

  Log Message:
  -----------
  Cherry-pick 2b9b6bf2f2fb. rdar://123777699

    [WebXR] Skip freezing layer tree with an active WebXR immersive session only when there's video content
    https://bugs.webkit.org/show_bug.cgi?id=270669
    rdar://123777699

    Reviewed by Eric Carlson.

    We initially skip freezing the layer tree with an active WebXR immersive session
    so videos can continue to get their requestVideoFrameCallback serviced. However,
    since this also incurs a power cost, we'll only do this when there's video
    content on the page.

    * Source/WebCore/page/Page.cpp:
    (WebCore::Page::shouldBlockLayerTreeFreezingForVideo):
    * Source/WebCore/page/Page.h:
    * Source/WebKit/WebProcess/WebPage/WebPage.cpp:
    (WebKit::WebPage::updateDrawingAreaLayerTreeFreezeState):

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

Identifier: 273664.1364 at safari-7619.1.5.6-branch


  Commit: 3a8dc20ce2dfb3d6f767ac67f7223191e6e078e6
      https://github.com/WebKit/WebKit/commit/3a8dc20ce2dfb3d6f767ac67f7223191e6e078e6
  Author: Megan Gardner <megan_gardner at apple.com>
  Date:   2024-03-11 (Mon, 11 Mar 2024)

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

  Log Message:
  -----------
  Cherry-pick 89bc7dd33ce8. rdar://122843511

    Find in Note: Dark gray outline (shadow) appears behind gray/yellow highlights when matched text found in HTML note.
    https://bugs.webkit.org/show_bug.cgi?id=270666
    rdar://122843511

    Reviewed by Aditya Keerthi.

    In notes, the WKContentView is transparent, so our original solution of putting an additional
    grey layer behind the content view that filled up the empty parts of the scroll view would show
    through and make the find ui have a incorrect grey cast. So instead, we make four views that surround
    the WKContentView to fill in any part of the scrollView that isn't covered by the contentView.
    These are arranged around the content view like so:

    ----- -----------
    |    |          |
    |    |----------|
    |    |     |    |
    |    |     |    |
    ----- ------    |
    |          |    |
    |__________|____|

    Each view is expanded to reach the edges of the scroll view every time the view is scrolled or the bounds change.
    This means that no matter where the content view is scrolled to, there will be a view that gives the correct
    grey cast to the scroll view.

    * Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h:
    * Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm:
    (-[WKWebView scrollViewDidScroll:]):
    (-[WKWebView _frameOrBoundsMayHaveChanged]):
    (-[WKWebView _updateFindOverlayForOverflowScrollPositions]):
    (-[WKWebView _showFindOverlay]):
    (-[WKWebView _hideFindOverlay]):
    (-[WKWebView _didAddLayerForFindOverlay:]):
    (-[WKWebView _updateFindOverlayPosition]): Deleted.

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

Identifier: 273664.1365 at safari-7619.1.5.6-branch


  Commit: 39d7eb24d8f385a409d6cec2ae7297583bfc6116
      https://github.com/WebKit/WebKit/commit/39d7eb24d8f385a409d6cec2ae7297583bfc6116
  Author: Chris Dumez <cdumez at apple.com>
  Date:   2024-03-11 (Mon, 11 Mar 2024)

  Changed paths:
    M Source/WebKit/Shared/Cocoa/WKKeyedCoder.mm

  Log Message:
  -----------
  Cherry-pick b1fa8241a6a7. rdar://124247709

    Fix memory leak under [WKKeyedCoder initWithDictionary]
    https://bugs.webkit.org/show_bug.cgi?id=270734
    rdar://124247709

    Reviewed by Darin Adler.

    Make sure we adopt the result of `[NSDictionary mutableCopy]`.

    * Source/WebKit/Shared/Cocoa/WKKeyedCoder.mm:
    (-[WKKeyedCoder initWithDictionary:]):

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

Identifier: 273664.1366 at safari-7619.1.5.6-branch


Compare: https://github.com/WebKit/WebKit/compare/d371998f7dec%5E...39d7eb24d8f3

To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications