[webkit-changes] [WebKit/WebKit] 0016e2: Versioning.

Tue Oct 29 16:27:34 PDT 2024

  Branch: refs/heads/safari-7619.2.8.11-branch
  Home:   https://github.com/WebKit/WebKit
  Commit: 0016e276ff194a902b1b6c92517bb63fbfb20606
      https://github.com/WebKit/WebKit/commit/0016e276ff194a902b1b6c92517bb63fbfb20606
  Author: Mohsin Qureshi <mohsinq at apple.com>
  Date:   2024-09-25 (Wed, 25 Sep 2024)

  Changed paths:
    M Configurations/Version.xcconfig

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

WebKit-7619.2.8.11.1

Canonical link: https://commits.webkit.org/280938.374@safari-7619.2.8.11-branch

  Commit: af32cf6cc91bdb2ee665b8c0d5fe834560070471
      https://github.com/WebKit/WebKit/commit/af32cf6cc91bdb2ee665b8c0d5fe834560070471
  Author: Marcus Plutowski <marcus_plutowski at apple.com>
  Date:   2024-09-26 (Thu, 26 Sep 2024)

  Changed paths:
    M Source/JavaScriptCore/assembler/AssemblerBuffer.h
    M Source/JavaScriptCore/jit/ExecutableAllocator.h

  Log Message:
  -----------
  Cherry-pick 60a72b8caf51. rdar://136764436

    Poison AssemblerBuffer's inline buffer on x86
    https://bugs.webkit.org/show_bug.cgi?id=280354
    rdar://136706743

    Reviewed by Yusuke Suzuki.

    JIT_SCAN_ASSEMBLER_BUFFER_FOR_ZEROES is a feature enabled on X86 that
    scans the assembler buffer for excessive strings of zeroes at link-time.
    We would like to be able to distinguish between two cases:
     1. The zeroes were written into the buffer (either intentionally or
        unintentionally)
     2. The zeroes were left there by someone who forgot to write over a
        chunk of code, and are thus just left over from initialization
    By poisoning m_inlineBuffer inside the constructor, we mostly achieve
    this -- we'd like to poison the out-of-line buffers too, but it's more
    likely that that will have too high of a performance cost and inline
    buffers are the ones most likely to be corrupted regardless (being on
    the stack, and thus most vulnerable to buffer overruns and the like).

    * Source/JavaScriptCore/assembler/AssemblerBuffer.h:
    (JSC::AssemblerDataImpl::AssemblerDataImpl):
    (JSC::AssemblerDataImpl::poisonInlineBuffer):
    * Source/JavaScriptCore/jit/ExecutableAllocator.h:
    (JSC::performJITMemcpy):

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

Canonical link: https://commits.webkit.org/280938.375@safari-7619.2.8.11-branch

  Commit: 244a19d8856c3f17073df33959f6ec466cf56982
      https://github.com/WebKit/WebKit/commit/244a19d8856c3f17073df33959f6ec466cf56982
  Author: Mohsin Qureshi <mohsinq at apple.com>
  Date:   2024-09-27 (Fri, 27 Sep 2024)

  Changed paths:
    M Configurations/Version.xcconfig

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

WebKit-7619.2.8.11.2

Canonical link: https://commits.webkit.org/280938.376@safari-7619.2.8.11-branch

  Commit: a70b287d663f3f44a3735275565ef11d698f78ab
      https://github.com/WebKit/WebKit/commit/a70b287d663f3f44a3735275565ef11d698f78ab
  Author: Alex Christensen <achristensen at apple.com>
  Date:   2024-09-27 (Fri, 27 Sep 2024)

  Changed paths:
    M Source/WebCore/page/csp/ContentSecurityPolicyDirectiveList.cpp
    M Source/WebCore/page/csp/ContentSecurityPolicyTrustedTypesDirective.cpp
    M Tools/TestWebKitAPI/Tests/WebKitCocoa/ContentSecurityPolicy.mm

  Log Message:
  -----------
  Cherry-pick 1db982b7c00f. rdar://136779806

    Fix infinite loops when parsing invalid CSP header fields after 273894 at main
    https://bugs.webkit.org/show_bug.cgi?id=280442
    rdar://136779806

    Reviewed by Brent Fulgham.

    If we find an invalid value, report it and return instead of reporting it over and over
    again in an infinite loop until we run out of memory from too many reports.

    * Source/WebCore/page/csp/ContentSecurityPolicyDirectiveList.cpp:
    (WebCore::ContentSecurityPolicyDirectiveList::parseRequireTrustedTypesFor):
    * Source/WebCore/page/csp/ContentSecurityPolicyTrustedTypesDirective.cpp:
    (WebCore::ContentSecurityPolicyTrustedTypesDirective::parse):
    * Tools/TestWebKitAPI/Tests/WebKitCocoa/ContentSecurityPolicy.mm:
    (TEST(ContentSecurityPolicy, InvalidRequireTrustedTypesFor)):

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

  Commit: ef9ce463d9a95aa5491edc7f54112684ade2238a
      https://github.com/WebKit/WebKit/commit/ef9ce463d9a95aa5491edc7f54112684ade2238a
  Author: Mohsin Qureshi <mohsinq at apple.com>
  Date:   2024-09-30 (Mon, 30 Sep 2024)

  Changed paths:
    M Configurations/Version.xcconfig

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

WebKit-7619.2.8.11.3

Canonical link: https://commits.webkit.org/280938.378@safari-7619.2.8.11-branch

  Commit: a0c299f26e08f6b94522fec2b71af440d8b7eed6
      https://github.com/WebKit/WebKit/commit/a0c299f26e08f6b94522fec2b71af440d8b7eed6
  Author: Alan Baradlay <zalan at apple.com>
  Date:   2024-09-30 (Mon, 30 Sep 2024)

  Changed paths:
    A LayoutTests/fast/block/float/overlapping-float-left-simple-expected.html
    A LayoutTests/fast/block/float/overlapping-float-left-simple.html
    A LayoutTests/fast/block/float/overlapping-float-right-simple-expected.html
    A LayoutTests/fast/block/float/overlapping-float-right-simple.html
    M Source/WebCore/layout/floats/FloatingContext.cpp

  Log Message:
  -----------
  Cherry-pick dffa25228983. rdar://136362683

    Regression (Safari 18.0): WordPress Classic Editor sidebar layout is broken (floats not clearing)
    https://bugs.webkit.org/show_bug.cgi?id=280063
    <rdar://136362683>

    Reviewed by Antti Koivisto.

    This change expands on 279867 at main where we started allowing floats to overlap each other by addressing the "// FIXME: Should we check if placed floats come from outside of this formatting context."
    comment.

    1. Let's check if the left/right side floats (in-between these floats we wanna insert a new incoming float), intersect our containing block (in this case the IFC formatting context root)
    2. Also check if these left/right side floats belong to the current formatting context

    * Source/WebCore/layout/floats/FloatingContext.cpp:
    (WebCore::Layout::findAvailablePosition):

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

  Commit: 9dddcb2198078fa1fa20807370b32a1b21591a7b
      https://github.com/WebKit/WebKit/commit/9dddcb2198078fa1fa20807370b32a1b21591a7b
  Author: Mohsin Qureshi <mohsinq at apple.com>
  Date:   2024-09-30 (Mon, 30 Sep 2024)

  Changed paths:
    R LayoutTests/fast/block/float/overlapping-float-left-simple-expected.html
    R LayoutTests/fast/block/float/overlapping-float-left-simple.html
    R LayoutTests/fast/block/float/overlapping-float-right-simple-expected.html
    R LayoutTests/fast/block/float/overlapping-float-right-simple.html
    M Source/WebCore/layout/floats/FloatingContext.cpp

  Log Message:
  -----------
  Revert "Cherry-pick dffa25228983. rdar://136362683"

This reverts commit a0c299f26e08f6b94522fec2b71af440d8b7eed6.

  Commit: 96e0bd3920cf0fdc1fccea618db2b86b3d8714e8
      https://github.com/WebKit/WebKit/commit/96e0bd3920cf0fdc1fccea618db2b86b3d8714e8
  Author: Mohsin Qureshi <mohsinq at apple.com>
  Date:   2024-09-30 (Mon, 30 Sep 2024)

  Changed paths:
    R LayoutTests/fast/block/float/non-intrusive-float-overlap-expected.html
    R LayoutTests/fast/block/float/non-intrusive-float-overlap.html
    M Source/WebCore/layout/floats/FloatingContext.cpp
    M Source/WebCore/layout/floats/FloatingContext.h

  Log Message:
  -----------
  Revert b424c89ef690. rdar://136988841

  Commit: fed9897875e23af8e00f7302c3829669b4c4e35c
      https://github.com/WebKit/WebKit/commit/fed9897875e23af8e00f7302c3829669b4c4e35c
  Author: Dan Robson <dtr_bugzilla at apple.com>
  Date:   2024-10-02 (Wed, 02 Oct 2024)

  Changed paths:
    M Configurations/Version.xcconfig

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

WebKit-7619.2.8.11.4

Canonical link: https://commits.webkit.org/280938.382@safari-7619.2.8.11-branch

  Commit: 39dd8af30e04e99fb6e05f0abf7e5b0e3126fe06
      https://github.com/WebKit/WebKit/commit/39dd8af30e04e99fb6e05f0abf7e5b0e3126fe06
  Author: Marcus Plutowski <marcus_plutowski at apple.com>
  Date:   2024-10-02 (Wed, 02 Oct 2024)

  Changed paths:
    M Source/JavaScriptCore/jit/ExecutableAllocator.h

  Log Message:
  -----------
  Cherry-pick 34d00da35e69. rdar://137125681

    Provide more crash-info in when checking for runs of zero-bytes
    https://bugs.webkit.org/show_bug.cgi?id=280547
    rdar://136858657

    Reviewed by Keith Miller.

    Previously, the crash told us that zero-bytes were present in the
    destination buffer, but not whether they were present in the source
    buffer. This patch fixes that without performance overhead by checking
    the source buffer only if a run is detected in the destination buffer.
    Moreover, while the crash stack afforded by this diagnostic is more
    useful than the 'raw' crash would be, it does lose us the ability to see
    the actually-corrupted instruction stream: instead of just asserting,
    this patch jumps into the JIT buffer to induce a crash.

    * Source/JavaScriptCore/jit/ExecutableAllocator.h:
    (JSC::dieByJumpingIntoJITBufferWithInfo):
    (JSC::performJITMemcpy):

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

Canonical link: https://commits.webkit.org/280938.383@safari-7619.2.8.11-branch

  Commit: 7caad2117c8ef61854b7706398099dbfa5560c88
      https://github.com/WebKit/WebKit/commit/7caad2117c8ef61854b7706398099dbfa5560c88
  Author: Dan Robson <dtr_bugzilla at apple.com>
  Date:   2024-10-04 (Fri, 04 Oct 2024)

  Changed paths:
    M Configurations/Version.xcconfig

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

WebKit-7619.2.8.11.5

Canonical link: https://commits.webkit.org/280938.384@safari-7619.2.8.11-branch

  Commit: a060ea7ff9f4c10ffb28c1abbba56666a53ca039
      https://github.com/WebKit/WebKit/commit/a060ea7ff9f4c10ffb28c1abbba56666a53ca039
  Author: Kiet Ho <tho22 at apple.com>
  Date:   2024-10-04 (Fri, 04 Oct 2024)

  Changed paths:
    M Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeEventDispatcher.cpp

  Log Message:
  -----------
  Cherry-pick 18fad22e2078. rdar://137283710

    Add missing scrollingTree null checks in WebKit::RemoteLayerTreeEventDispatcher
    rdar://135886162
    https://bugs.webkit.org/show_bug.cgi?id=280842

    Reviewed by Wenson Hsieh.

    * Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeEventDispatcher.cpp:
    (WebKit::RemoteLayerTreeEventDispatcher::handleWheelEvent):
    (WebKit::RemoteLayerTreeEventDispatcher::handleSyntheticWheelEvent):

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

Canonical link: https://commits.webkit.org/280938.385@safari-7619.2.8.11-branch

  Commit: ab15297fd0e3d41d2cb0f61d91fbfb1e4c61d0fb
      https://github.com/WebKit/WebKit/commit/ab15297fd0e3d41d2cb0f61d91fbfb1e4c61d0fb
  Author: Mohsin Qureshi <mohsinq at apple.com>
  Date:   2024-10-08 (Tue, 08 Oct 2024)

  Changed paths:
    M Configurations/Version.xcconfig

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

WebKit-7619.2.8.11.6

Canonical link: https://commits.webkit.org/280938.386@safari-7619.2.8.11-branch

  Commit: 86bc348a59a15b7748c28dc62b86d274c2063936
      https://github.com/WebKit/WebKit/commit/86bc348a59a15b7748c28dc62b86d274c2063936
  Author: Basuke Suzuki <basuke at apple.com>
  Date:   2024-10-08 (Tue, 08 Oct 2024)

  Changed paths:
    M Source/WebCore/html/HTMLMediaElement.cpp

  Log Message:
  -----------
  Cherry-pick 5f8c88f5cf2b. rdar://137522273

    REGRESSION (279761 at main): Returning to inline playback from fullscreen shows only the play/pause button instead of the full controls
    https://bugs.webkit.org/show_bug.cgi?id=280903
    rdar://134924988

    Reviewed by Andy Estes.

    Full control should be displayed when switching back from fullscreen mode, but play/pause button is displayed.

    Steps to reproduce:

    1. Open https://developer.apple.com/videos/play/wwdc2023/10279/ in Safari on macOS
    2. Start video playback
    3. Enter fullscreen
    4. Exit fullscreen

    At this point you’ll notice that the only media control available is the play/pause button instead of the full media controls.

    The issue is introduced with the following commit:
    https://commits.webkit.org/279761@main

    The logic added to HTMLMediaElement::shouldForceControlsDisplay() is for tvOS and no reason to apply it to other platform.
    Wrapping the logic with PLATFORM(APPLETV) should fix the issue.

    * Source/WebCore/html/HTMLMediaElement.cpp:
    (WebCore::HTMLMediaElement::shouldForceControlsDisplay const):

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

  Commit: 3718e03b9aebee4e5e030ba8306aebf0ddbcdb5a
      https://github.com/WebKit/WebKit/commit/3718e03b9aebee4e5e030ba8306aebf0ddbcdb5a
  Author: Mohsin Qureshi <mohsinq at apple.com>
  Date:   2024-10-08 (Tue, 08 Oct 2024)

  Changed paths:
    M Configurations/Version.xcconfig

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

WebKit-7619.2.8.11.7

Canonical link: https://commits.webkit.org/280938.388@safari-7619.2.8.11-branch

  Commit: 2575f80060efb99c66b48a76e31d6e58a78e5379
      https://github.com/WebKit/WebKit/commit/2575f80060efb99c66b48a76e31d6e58a78e5379
  Author: Dan Robson <dtr_bugzilla at apple.com>
  Date:   2024-10-09 (Wed, 09 Oct 2024)

  Changed paths:
    M Configurations/Version.xcconfig

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

WebKit-7619.2.8.11.8

Canonical link: https://commits.webkit.org/280938.389@safari-7619.2.8.11-branch

  Commit: 0cc9ba0c387abe19d4ac238cfcf4d6d9ca655af3
      https://github.com/WebKit/WebKit/commit/0cc9ba0c387abe19d4ac238cfcf4d6d9ca655af3
  Author: Timothy Hatcher <timothy at apple.com>
  Date:   2024-10-09 (Wed, 09 Oct 2024)

  Changed paths:
    M Source/WebKit/WebProcess/Extensions/API/Cocoa/WebExtensionAPIScriptingCocoa.mm
    M Source/WebKit/WebProcess/Extensions/API/Cocoa/WebExtensionAPITabsCocoa.mm
    M Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebExtensionAPIScripting.mm
    M Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebExtensionAPITabs.mm

  Log Message:
  -----------
  Cherry-pick bb35511a7805. rdar://137449521

    Web Extensions: tabs.executeScript ignores frameId parameter.
    https://webkit.org/b/281099
    rdar://137449521

    Reviewed by Brian Weinstein.

    The parsing of options for `tabs.executeScript` was overriding the `frameIdentifier`
    with the main frame since the check for all frames was always returning `true` if
    the `allFrames` option was missing or `false`.

    * Source/WebKit/WebProcess/Extensions/API/Cocoa/WebExtensionAPIScriptingCocoa.mm:
    (WebKit::WebExtensionAPIScripting::parseTargetInjectionOptions): Remove early return
    and add `allFrames` else case.
    * Source/WebKit/WebProcess/Extensions/API/Cocoa/WebExtensionAPITabsCocoa.mm:
    (WebKit::WebExtensionAPITabs::parseScriptOptions): Make `allFrames` be the else case.
    * Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebExtensionAPIScripting.mm:
    (TestWebKitAPI::TEST(WKWebExtensionAPIScripting, ExecuteScriptWithFrameIds)): Replaced
    with a better test that uses pathname to verify the frame is the target.
    * Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebExtensionAPITabs.mm:
    (TestWebKitAPI::TEST(WKWebExtensionAPITabs, ExecuteScriptWithFrameId)): Added.

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

  Commit: 1053ea1bea0d91038d64c32934050c5237a9b3dc
      https://github.com/WebKit/WebKit/commit/1053ea1bea0d91038d64c32934050c5237a9b3dc
  Author: Dan Robson <dtr_bugzilla at apple.com>
  Date:   2024-10-10 (Thu, 10 Oct 2024)

  Changed paths:
    M Configurations/Version.xcconfig

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

WebKit-7619.2.8.11.9

Canonical link: https://commits.webkit.org/280938.391@safari-7619.2.8.11-branch

Compare: https://github.com/WebKit/WebKit/compare/0016e276ff19%5E...1053ea1bea0d

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