[webkit-changes] [WebKit/WebKit] 38ee2f: Cherry-pick 272448.625 at safari-7618-branch (800c12a...

Adrian Perez noreply at github.com
Wed May 15 00:51:12 PDT 2024


  Branch: refs/heads/webkitglib/2.44
  Home:   https://github.com/WebKit/WebKit
  Commit: 38ee2f2a6eaec6aed04443a1b1cbfa8c6c06b35a
      https://github.com/WebKit/WebKit/commit/38ee2f2a6eaec6aed04443a1b1cbfa8c6c06b35a
  Author: Justin Michaud <justin_michaud at apple.com>
  Date:   2024-05-13 (Mon, 13 May 2024)

  Changed paths:
    M Source/JavaScriptCore/API/JSStringRef.cpp
    M Source/JavaScriptCore/API/tests/testapi.c
    M Source/WTF/wtf/unicode/UTF8Conversion.cpp

  Log Message:
  -----------
  Cherry-pick 272448.625 at safari-7618-branch (800c12a28dea). rdar://122388595

    JSStringGetUTF8CString writes beyond the provided buffer size
    rdar://122388595

    Reviewed by Yusuke Suzuki.

    U8_APPEND only checks the capacity in the non-ascii case,
    so we should make sure we always check.

    * Source/WTF/wtf/unicode/UTF8Conversion.cpp:
    (WTF::Unicode::convertLatin1ToUTF8):
    (WTF::Unicode::convertUTF16ToUTF8):
    * Source/WebCore/dom/TextEncoder.cpp:
    (WebCore::TextEncoder::encodeInto):

    Canonical link: https://commits.webkit.org/272448.625@safari-7618-branch

Canonical link: https://commits.webkit.org/274313.215@webkitglib/2.44


  Commit: b5701eb0fe870f8800f146ffbdad35497b4a2e50
      https://github.com/WebKit/WebKit/commit/b5701eb0fe870f8800f146ffbdad35497b4a2e50
  Author: Nicole Rosario <nicole_rosario at apple.com>
  Date:   2024-05-13 (Mon, 13 May 2024)

  Changed paths:
    A LayoutTests/fast/css-grid-layout/css-grid-template-rows-invalid-length-expected.txt
    A LayoutTests/fast/css-grid-layout/css-grid-template-rows-invalid-length.html
    M Source/WebCore/style/StyleBuilderConverter.h

  Log Message:
  -----------
  Cherry-pick 272448.626 at safari-7618-branch (0b6e28662a19). https://bugs.webkit.org/show_bug.cgi?id=269856

    Added default length to createGridTrackBreadth() when length is undefined
    https://bugs.webkit.org/show_bug.cgi?id=269856
    rdar://119619013

    Reviewed by Sammy Gill.

    `convertToLength` returned length undefined to `createGridTrackBreadth`
    which causes an issue when creating GridLength. Added check to see if
    length is undefined and if so returned a default length = 0 instead

    * Source/WebCore/style/StyleBuilderConverter.h:
    (WebCore::Style::BuilderConverter::createGridTrackBreadth):

    Canonical link: https://commits.webkit.org/272448.626@safari-7618-branch

Canonical link: https://commits.webkit.org/274313.216@webkitglib/2.44


  Commit: 5574e48233cdb417c50695039824e6ff0947a2d1
      https://github.com/WebKit/WebKit/commit/5574e48233cdb417c50695039824e6ff0947a2d1
  Author: Matthieu Dubet <m_dubet at apple.com>
  Date:   2024-05-13 (Mon, 13 May 2024)

  Changed paths:
    A LayoutTests/fast/css/css-typed-om-typeerror-coalescing-pair-expected.txt
    A LayoutTests/fast/css/css-typed-om-typeerror-coalescing-pair.html
    M Source/WebCore/css/CSSValuePair.cpp
    M Source/WebCore/css/CSSValuePair.h
    M Source/WebCore/css/typedom/StylePropertyMap.cpp
    M Source/WebCore/style/StyleBuilderConverter.h

  Log Message:
  -----------
  Cherry-pick 272448.627 at safari-7618-branch (51293a58e9dd). rdar://115346002

    [CSS] Fix bug when using a coalesced CSSValuePair with Typed OM
    rdar://115346002

    Reviewed by Chris Dumez.

    We use the CSSParser and the serialization of CSSValue to validate the input of Typed OM set().
    Unfortunately, sometimes a CSSValuePair serializes to a single value while it
    actually contains two values: this confuses the StyleBuilder.

    If the pair has the same values twice "10px 10px", it serializes to only "10px",
    thus pass our string-based check (inside setProperty), but then crash when the actual value is a
    pair of length instead of a simple length.

    The more frequent case when the two values are distincts, such as "10px 30px", is
    already prevented by the string-based check.

    A proper fix would be to have validation method which doesn't work
    on the serialized string value but on the actual typed CSSValue.

    For the moment, we avoid crashing and warn the user with an error.

    * LayoutTests/fast/css/css-typed-om-typeerror-coalescing-pair-expected.txt: Added.
    * LayoutTests/fast/css/css-typed-om-typeerror-coalescing-pair.html: Added.
    * Source/WebCore/css/CSSValuePair.cpp:
    (WebCore::CSSValuePair::canBeCoalesced const):
    * Source/WebCore/css/CSSValuePair.h:
    * Source/WebCore/css/typedom/StylePropertyMap.cpp:
    (WebCore::StylePropertyMap::set):
    * Source/WebCore/style/StyleBuilderConverter.h:
    (WebCore::Style::BuilderConverter::convertLengthSizing):

    Canonical link: https://commits.webkit.org/272448.627@safari-7618-branch

Canonical link: https://commits.webkit.org/274313.217@webkitglib/2.44


  Commit: cac405a2378967ea4801adb6f162d27bdbc52678
      https://github.com/WebKit/WebKit/commit/cac405a2378967ea4801adb6f162d27bdbc52678
  Author: Yusuke Suzuki <ysuzuki at apple.com>
  Date:   2024-05-13 (Mon, 13 May 2024)

  Changed paths:
    A JSTests/stress/decouple-calllinkinfo-from-access-case.js
    M Source/JavaScriptCore/bytecode/AccessCase.cpp
    M Source/JavaScriptCore/bytecode/AccessCase.h
    M Source/JavaScriptCore/bytecode/GetByStatus.cpp
    M Source/JavaScriptCore/bytecode/GetterSetterAccessCase.cpp
    M Source/JavaScriptCore/bytecode/GetterSetterAccessCase.h
    M Source/JavaScriptCore/bytecode/InlineCacheCompiler.cpp
    M Source/JavaScriptCore/bytecode/InlineCacheCompiler.h
    M Source/JavaScriptCore/bytecode/ProxyObjectAccessCase.cpp
    M Source/JavaScriptCore/bytecode/ProxyObjectAccessCase.h
    M Source/JavaScriptCore/bytecode/PutByStatus.cpp
    M Source/JavaScriptCore/bytecode/StructureStubInfo.cpp
    M Source/JavaScriptCore/bytecode/StructureStubInfo.h
    M Source/JavaScriptCore/jit/GCAwareJITStubRoutine.cpp
    M Source/JavaScriptCore/jit/GCAwareJITStubRoutine.h
    M Source/JavaScriptCore/jit/JITStubRoutine.cpp
    M Source/JavaScriptCore/jit/JITStubRoutine.h

  Log Message:
  -----------
  Cherry-pick 272448.633 at safari-7618-branch (f25738c69a33). https://bugs.webkit.org/show_bug.cgi?id=268221

    [JSC] AccessCase should not hold CallLinkInfo*
    https://bugs.webkit.org/show_bug.cgi?id=268221
    rdar://121733122

    Reviewed by Justin Michaud.

    AccessCase holds CallLinkInfo*. But when the underlying JITStubRoutine gets destroyed, this becomes invalid.
    Previously, it does not matter since we always destroy CodeBlock first (synchronously), and then we clean up JITStubRoutine.
    So there were strict ordering.  But now CodeBlock destruction can get delayed.

    But fundamentally speaking, having CallLinkInfo* in AccessCase is not right. This is compiled code's data structure and
    AccessCase should be just a data for IC feedback.

    In this patch we decouple CallLinkInfo* from AccessCase. CallLinkInfo's lifetime should be correctly managed by visitWeak, so,
    we add visitWeak iteration in MarkingGCAwareJITStubRoutine. Then we can remove CallLinkInfo from AccessCase.

    * JSTests/stress/decouple-calllinkinfo-from-access-case.js: Added.
    (F7):
    (f25):
    (f33):
    (C20.prototype.valueOf):
    (C20):
    (f27):
    * Source/JavaScriptCore/bytecode/AccessCase.cpp:
    (JSC::AccessCase::forEachDependentCell const):
    (JSC::AccessCase::doesCalls const):
    (JSC::AccessCase::visitWeak const):
    (JSC::AccessCase::collectDependentCells const):
    * Source/JavaScriptCore/bytecode/AccessCase.h:
    * Source/JavaScriptCore/bytecode/GetByStatus.cpp:
    (JSC::GetByStatus::computeForStubInfoWithoutExitSiteFeedback):
    * Source/JavaScriptCore/bytecode/GetterSetterAccessCase.cpp:
    (JSC::GetterSetterAccessCase::dumpImpl const):
    * Source/JavaScriptCore/bytecode/GetterSetterAccessCase.h:
    * Source/JavaScriptCore/bytecode/InlineCacheCompiler.cpp:
    (JSC::InlineCacheCompiler::generateWithGuard):
    (JSC::InlineCacheCompiler::generate):
    (JSC::InlineCacheCompiler::generateImpl):
    (JSC::InlineCacheCompiler::emitProxyObjectAccess):
    (JSC::InlineCacheCompiler::regenerate):
    (JSC::InlineCacheHandler::callLinkInfoAt):
    (JSC::InlineCacheHandler::visitWeak const):
    * Source/JavaScriptCore/bytecode/InlineCacheCompiler.h:
    * Source/JavaScriptCore/bytecode/ProxyObjectAccessCase.cpp:
    (JSC::ProxyObjectAccessCase::dumpImpl const):
    * Source/JavaScriptCore/bytecode/ProxyObjectAccessCase.h:
    * Source/JavaScriptCore/bytecode/PutByStatus.cpp:
    (JSC::PutByStatus::computeForStubInfo):
    * Source/JavaScriptCore/bytecode/StructureStubInfo.cpp:
    (JSC::StructureStubInfo::callLinkInfoAt):
    * Source/JavaScriptCore/bytecode/StructureStubInfo.h:
    * Source/JavaScriptCore/jit/GCAwareJITStubRoutine.cpp:
    (JSC::MarkingGCAwareJITStubRoutine::MarkingGCAwareJITStubRoutine):
    (JSC::MarkingGCAwareJITStubRoutine::visitWeakImpl):
    (JSC::MarkingGCAwareJITStubRoutine::callLinkInfoAtImpl):
    (JSC::GCAwareJITStubRoutineWithExceptionHandler::GCAwareJITStubRoutineWithExceptionHandler):
    (JSC::createICJITStubRoutine):
    * Source/JavaScriptCore/jit/GCAwareJITStubRoutine.h:
    * Source/JavaScriptCore/jit/JITStubRoutine.cpp:
    (JSC::JITStubRoutine::callLinkInfoAt):
    * Source/JavaScriptCore/jit/JITStubRoutine.h:
    (JSC::JITStubRoutine::callLinkInfoAtImpl):

    Canonical link: https://commits.webkit.org/272448.633@safari-7618-branch

Canonical link: https://commits.webkit.org/274313.218@webkitglib/2.44


  Commit: 1dcc3a85c4b4cf5b7a45c299e95c6452f4f691ab
      https://github.com/WebKit/WebKit/commit/1dcc3a85c4b4cf5b7a45c299e95c6452f4f691ab
  Author: Claudio Saavedra <csaavedra at igalia.com>
  Date:   2024-05-13 (Mon, 13 May 2024)

  Changed paths:
    A LayoutTests/fast/block/multicolumn-with-outline-auto-expected.txt
    A LayoutTests/fast/block/multicolumn-with-outline-auto.html
    M Source/WebCore/rendering/updating/RenderTreeBuilder.cpp
    M Source/WebCore/rendering/updating/RenderTreeBuilder.h
    M Source/WebCore/rendering/updating/RenderTreeBuilderBlock.cpp
    M Source/WebCore/rendering/updating/RenderTreeBuilderBlock.h
    M Source/WebCore/rendering/updating/RenderTreeBuilderMultiColumn.cpp

  Log Message:
  -----------
  Cherry-pick 274097.6 at webkit-2024.2-embargoed (446b237f7e06). https://bugs.webkit.org/show_bug.cgi?id=263180

    Prevent selection repaint in the middle of multicolumn flow destruction
    https://bugs.webkit.org/show_bug.cgi?id=263180

    Reviewed by Alan Baradlay.

    During multicolumn fragmented flow destruction, spanners are moved back
    to their original DOM position in the tree. This is done through calls
    to RenderTreeBuilderBlock::Block::detach(RenderBlockFlow&), which also
    calls the more general RenderBlock ::detach() method for each spanner.
    The former method results in the destruction of the spanner placeholders
    and the merging of the necessary multicolumn sets, but this is not done
    immediately, so the tree is temporarily inconsistent, before the
    RenderBlock detach() method is called.

    RenderTreeBuilderBlock::Block::detach(RenderBlock&), however,
    might inadvertely end up triggering a repaint of the selection that the
    tree is not ready for. I assume that this is an oversight from the possibility
    that this method gets called during RenderBlockFlow detachment. This repaint
    happens because RenderTreeBuilder::detachFromRenderElement() clears the
    selection if the child being detached is to be destroyed. As
    WillBeDestroyed::Yes is the default value in the definition of
    detachFromRenderElement(), this is assumed to be the case, even when
    that's not what happens during fragmented flow destruction.

    The problem with this is that the selection repaint will eventually find itself
    needing a consistent tree, and the fact that multicolumn sets are not merged
    yet and there are spanners without a placehoder will break assumptions made
    in RenderObject::propagateRepaintToParentWithOutlineAutoIfNeeded().

    Fix this by making it possible for both detach() methods to propagate
    WillBeDestroyed, with a default value of WillBeDestroyed::Yes to preserve
    current behavior everywhere, but explicitly passing WillBeDestroyed::No
    during fragmented flow destruction when detaching spanners, as this is what
    is actually happening. This prevents the selection repaint from happening
    before the tree is in a consistent state.

    * LayoutTests/fast/block/multicolumn-with-outline-auto-expected.txt: Added.
    * LayoutTests/fast/block/multicolumn-with-outline-auto.html: Added.
    * Source/WebCore/rendering/updating/RenderTreeBuilder.cpp:
    (WebCore::RenderTreeBuilder::detach):
    * Source/WebCore/rendering/updating/RenderTreeBuilder.h:
    * Source/WebCore/rendering/updating/RenderTreeBuilderBlock.cpp:
    (WebCore::RenderTreeBuilder::Block::detach):
    * Source/WebCore/rendering/updating/RenderTreeBuilderBlock.h:
    * Source/WebCore/rendering/updating/RenderTreeBuilderMultiColumn.cpp:
    (WebCore::RenderTreeBuilder::MultiColumn::destroyFragmentedFlow):

    Canonical link: https://commits.webkit.org/274097.6@webkit-2024.2-embargoed

    Canonical link: https://commits.webkit.org/272448.648@safari-7618-branch

Canonical link: https://commits.webkit.org/274313.219@webkitglib/2.44


  Commit: 7ef599897147aca2433bea7a21e6f9bff2c5230e
      https://github.com/WebKit/WebKit/commit/7ef599897147aca2433bea7a21e6f9bff2c5230e
  Author: Mikhail R. Gadelha <mikhail at igalia.com>
  Date:   2024-05-13 (Mon, 13 May 2024)

  Changed paths:
    A JSTests/wasm/stress/wasm-unreachable-br-block.js
    M Source/JavaScriptCore/wasm/WasmFunctionParser.h

  Log Message:
  -----------
  Cherry-pick 274097.7 at webkit-2024.2-embargoed (ab8e4a4470bb). https://bugs.webkit.org/show_bug.cgi?id=265425

    WASM unreachable code validation is broken https://bugs.webkit.org/show_bug.cgi?id=265425

    Reviewed by Keith Miller.

    This patch fixes an assertion failure in the unreachable code parser
    when the target of a br instruction is a block that was not added into
    the control stack.

    The code that checks the br target now takes into account the number of
    unreachable blocks, if the br instruction is also unreachable. This is
    similar to the solution employed by parseDelegateTarget and should
    support cases when block, if, try, and loop were not added to the control
    stack.

    * JSTests/wasm/stress/wasm-unreachable-br-block.js: Added.
    (async test):
    * Source/JavaScriptCore/wasm/WasmFunctionParser.h:
    (JSC::Wasm::FunctionParser<Context>::parseBranchTarget):
    (JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):

    Canonical link: https://commits.webkit.org/274097.7@webkit-2024.2-embargoed

    Canonical link: https://commits.webkit.org/272448.649@safari-7618-branch

Canonical link: https://commits.webkit.org/274313.220@webkitglib/2.44


  Commit: 9020818f54ed5fbc3ad6bb4a25407dfce6981bcc
      https://github.com/WebKit/WebKit/commit/9020818f54ed5fbc3ad6bb4a25407dfce6981bcc
  Author: Žan Doberšek <zdobersek at igalia.com>
  Date:   2024-05-13 (Mon, 13 May 2024)

  Changed paths:
    A LayoutTests/fast/css/repeating-conic-gradient-small-range-expected.txt
    A LayoutTests/fast/css/repeating-conic-gradient-small-range.html
    A LayoutTests/fast/css/repeating-linear-gradient-small-range-expected.txt
    A LayoutTests/fast/css/repeating-linear-gradient-small-range.html
    A LayoutTests/fast/css/repeating-radial-gradient-small-range-expected.txt
    A LayoutTests/fast/css/repeating-radial-gradient-small-range.html
    M LayoutTests/platform/glib/TestExpectations
    M Source/WebCore/rendering/style/StyleGradientImage.cpp

  Log Message:
  -----------
  Cherry-pick 274097.8 at webkit-2024.2-embargoed (efd994a148b6). https://bugs.webkit.org/show_bug.cgi?id=264639

    ASAN_ILL | WTF::Vector::expandCapacity; WTF::Vector::expandCapacity; WebCore::StyleGradientImage::computeStops
    https://bugs.webkit.org/show_bug.cgi?id=264639

    Reviewed by Antti Koivisto.

    When working with repeating gradients, more care should be put into limiting the
    amount of stops that can be additionally generated. If the original gradient
    range is already too small, the extra stops are not generated. Once the number
    of additional stops is calculated, the generation proceeds only if that number
    is below some reasonable limit. That generation is also improved slightly by
    creating a separate Vector of gradient stops that then simply replaces the
    original one.

    * LayoutTests/fast/css/repeating-conic-gradient-small-range-expected.txt: Added.
    * LayoutTests/fast/css/repeating-conic-gradient-small-range.html: Added.
    * LayoutTests/fast/css/repeating-linear-gradient-small-range-expected.txt: Added.
    * LayoutTests/fast/css/repeating-linear-gradient-small-range.html: Added.
    * LayoutTests/fast/css/repeating-radial-gradient-small-range-expected.txt: Added.
    * LayoutTests/fast/css/repeating-radial-gradient-small-range.html: Added.
    * LayoutTests/platform/glib/TestExpectations:
    * Source/WebCore/rendering/style/StyleGradientImage.cpp:
    (WebCore::StyleGradientImage::computeStops const):

    Canonical link: https://commits.webkit.org/274097.8@webkit-2024.2-embargoed

    Canonical link: https://commits.webkit.org/272448.650@safari-7618-branch

Canonical link: https://commits.webkit.org/274313.221@webkitglib/2.44


  Commit: 9655eabf8a574dd9eff51129c356f5bd1988bfa8
      https://github.com/WebKit/WebKit/commit/9655eabf8a574dd9eff51129c356f5bd1988bfa8
  Author: Yijia Huang <yijia_huang at apple.com>
  Date:   2024-05-13 (Mon, 13 May 2024)

  Changed paths:
    A JSTests/stress/dfg-ai-direct-get-by-id-attribute-change-transition.js
    M Source/JavaScriptCore/bytecode/PutByStatus.cpp
    M Source/JavaScriptCore/runtime/Structure.cpp
    M Source/JavaScriptCore/runtime/Structure.h

  Log Message:
  -----------
  Cherry-pick 272448.651 at safari-7618-branch (4e48bdad7045). https://bugs.webkit.org/show_bug.cgi?id=270265

    [JSC] AI should observe attribute change transitions for PutByIdDirect in DFG compilation
    https://bugs.webkit.org/show_bug.cgi?id=270265
    rdar://122515736

    Reviewed by Yusuke Suzuki.

    Since DirectPutById can trigger and cache attribute change transitions,
    the AI should observe these kinds of transitions when computing for
    GetByStatus in the DFG compilation.

    * JSTests/stress/dfg-ai-attribute-change-transition-1.js: Added.
    (returnObject):
    (Opt):
    (createObjectA):
    (createObjectB):
    (initialize):
    * JSTests/stress/dfg-ai-attribute-change-transition-2.js: Added.
    (returnObject):
    (Opt):
    (createObject):
    (getStructureID):
    (main):
    * Source/JavaScriptCore/bytecode/PutByStatus.cpp:
    (JSC::PutByStatus::computeFor):
    * Source/JavaScriptCore/runtime/Structure.cpp:
    (JSC::Structure::attributeChangeTransitionToExistingStructureImpl):
    (JSC::Structure::attributeChangeTransitionToExistingStructure):
    (JSC::Structure::attributeChangeTransitionToExistingStructureConcurrently):
    * Source/JavaScriptCore/runtime/Structure.h:

    Canonical link: https://commits.webkit.org/272448.651@safari-7618-branch

Canonical link: https://commits.webkit.org/274313.222@webkitglib/2.44


  Commit: 56df757f15f6775393d617ff1dc07981263a343b
      https://github.com/WebKit/WebKit/commit/56df757f15f6775393d617ff1dc07981263a343b
  Author: Justin Michaud <justin_michaud at apple.com>
  Date:   2024-05-13 (Mon, 13 May 2024)

  Changed paths:
    A JSTests/stress/hoist-get-wasm-exports.js
    M Source/JavaScriptCore/dfg/DFGSafeToExecute.h

  Log Message:
  -----------
  Cherry-pick 272448.653 at safari-7618-branch (f6e2c3bb0a72). https://bugs.webkit.org/show_bug.cgi?id=270259

    GetWebAssemblyInstanceExports nodes should not be blindly hoisted
    https://bugs.webkit.org/show_bug.cgi?id=270259
    rdar://123617167

    Reviewed by Alexey Shvayka.

    GetWebAssemblyInstanceExports nodes should not be blindly hoisted above
    their structure check.

    ```
    case WebAssemblyInstanceExportsIntrinsic:
        ...
        addToGraph(CheckStructure, OpInfo(m_graph.addStructureSet(variant.structureSet())), thisNode);
        set(result, addToGraph(GetWebAssemblyInstanceExports, Edge(thisNode, KnownCellUse)));
    ```

    Similar to GetByOffset, we should only hoist this node if we have proven
    that the child has the structure of a WebAssembly Instance.

    * JSTests/stress/hoist-get-wasm-exports.js: Added.
    (opt):
    (main):
    * Source/JavaScriptCore/dfg/DFGSafeToExecute.h:
    (JSC::DFG::safeToExecute):

    Canonical link: https://commits.webkit.org/272448.653@safari-7618-branch

Canonical link: https://commits.webkit.org/274313.223@webkitglib/2.44


  Commit: 6f6c34c057f034796f60ebc0fd7443f2fde24704
      https://github.com/WebKit/WebKit/commit/6f6c34c057f034796f60ebc0fd7443f2fde24704
  Author: Mike Wyrzykowski <mwyrzykowski at apple.com>
  Date:   2024-05-13 (Mon, 13 May 2024)

  Changed paths:
    M Source/WebCore/en.lproj/Localizable.strings
    M Source/WebCore/html/HTMLAnchorElement.cpp
    M Source/WebKit/UIProcess/Cocoa/SystemPreviewControllerCocoa.mm
    M Source/WebKit/UIProcess/SystemPreviewController.h

  Log Message:
  -----------
  Cherry-pick 272448.672 at safari-7618-branch (6b6d3d3e61f6). <radar://122802255>

    Interactionless USDZ Popups in Vision Pro
    <radar://122802255>

    Reviewed by Tim Horton.

    Show a pop-up asking the user to confirm they want to
    quick look preview a USDZ file in WebKit.

    Add a delay if the page constantly tries to open one such
    file otherwise it can be difficult to exit out of the page.

    * Source/WebCore/en.lproj/Localizable.strings:
    * Source/WebKit/UIProcess/Cocoa/SystemPreviewControllerCocoa.mm:
    * Source/WebKit/UIProcess/SystemPreviewController.h:
    * Source/WebCore/html/HTMLAnchorElement.cpp:
    (WebCore::HTMLAnchorElement::handleClick):

    Canonical link: https://commits.webkit.org/272448.672@safari-7618-branch

Canonical link: https://commits.webkit.org/274313.224@webkitglib/2.44


  Commit: 5b0417e4484c6f4eb76e90da35d1ad1743ae07b5
      https://github.com/WebKit/WebKit/commit/5b0417e4484c6f4eb76e90da35d1ad1743ae07b5
  Author: Charlie Wolfe <charliew at apple.com>
  Date:   2024-05-13 (Mon, 13 May 2024)

  Changed paths:
    M Source/JavaScriptCore/inspector/agents/InspectorDebuggerAgent.cpp

  Log Message:
  -----------
  Cherry-pick 272448.684 at safari-7618-branch (cd62341b1dda). https://bugs.webkit.org/show_bug.cgi?id=270139

    Web Inspector: Crash in Inspector::InspectorDebuggerAgent::didScheduleAsyncCall on knowyourmeme.com
    https://bugs.webkit.org/show_bug.cgi?id=270139
    rdar://123667952

    Reviewed by Pascoe.

    Avoid reading past the end of `m_pendingAsyncCalls`.

    * Source/JavaScriptCore/inspector/agents/InspectorDebuggerAgent.cpp:
    (Inspector::InspectorDebuggerAgent::didScheduleAsyncCall):

    Canonical link: https://commits.webkit.org/272448.684@safari-7618-branch

Canonical link: https://commits.webkit.org/274313.225@webkitglib/2.44


  Commit: 15af2b30552cb3b2364242b336431759cde389fe
      https://github.com/WebKit/WebKit/commit/15af2b30552cb3b2364242b336431759cde389fe
  Author: Chris Dumez <cdumez at apple.com>
  Date:   2024-05-13 (Mon, 13 May 2024)

  Changed paths:
    M Source/WebCore/dom/Document.cpp
    M Tools/TestWebKitAPI/Tests/WebKit/WKBackForwardListTests.mm

  Log Message:
  -----------
  Cherry-pick 272448.685 at safari-7618-branch (028628cff473). https://bugs.webkit.org/show_bug.cgi?id=261611

    Calling evaluateJavaScript enables back-button hijacking
    https://bugs.webkit.org/show_bug.cgi?id=261611
    rdar://115561250

    Reviewed by Ben Nham.

    In 253405 at main, I updated our back/forward list hijacking prevention logic by
    treating history items added by JS (e.g. via 'history.pushState()`) as having
    a user gesture if a user gesture had occurred in the last 10 seconds. This was
    needed for backward compatibility with some legit sites.

    The issue now is that if the client app has called evaluateJavaScript on the
    WKWebView in the last 10 seconds, the JS will be able to hijack the back/forward
    list again.

    In 265168 at main, we did some hardening so that the transient activation gets
    consumed after the evaluateJavaScript call has completed. However, it didn't
    fix the back/forward list hijacking prevention logic because it relies on
    user gesture and not transient activation.

    To address the issue, I updated out back/forward list hijacking prevention logic
    to rely on transient user activation rather than whether or not there was a
    user gesture in the last 10 minutes.

    * Source/WebCore/dom/Document.cpp:
    (WebCore::Document::hasRecentUserInteractionForNavigationFromJS const):
    * Tools/TestWebKitAPI/Tests/WebKit/WKBackForwardListTests.mm:
    (TEST):

    Canonical link: https://commits.webkit.org/272448.685@safari-7618-branch

Canonical link: https://commits.webkit.org/274313.226@webkitglib/2.44


  Commit: 94adce30d4b5e29cac6649763c4e3551cd7f3b5c
      https://github.com/WebKit/WebKit/commit/94adce30d4b5e29cac6649763c4e3551cd7f3b5c
  Author: Rob Buis <rbuis at igalia.com>
  Date:   2024-05-13 (Mon, 13 May 2024)

  Changed paths:
    A LayoutTests/security/schedule-request-object-then-move-plugin-to-frameless-document-crash-expected.txt
    A LayoutTests/security/schedule-request-object-then-move-plugin-to-frameless-document-crash.html
    M Source/WebCore/html/HTMLPlugInImageElement.cpp

  Log Message:
  -----------
  Cherry-pick 274097.9 at webkit-2024.2-embargoed (f81d56c47751). https://bugs.webkit.org/show_bug.cgi?id=268769

    HTMLPlugInImageElement: verify that element is in same document before requesting a load
    https://bugs.webkit.org/show_bug.cgi?id=268769

    Reviewed by Ryosuke Niwa.

    The testcase shows a scenario where a plugin is set up to start loading the plugin contents
    from an event loop, however before the event loop is started the rest of the script will run, which
    moves the plugin to a different document, thus hitting an ASSERT in WebFrame::createSubframe when the load
    is performed. Protect against this by returning early when this situation is detected in the event loop.

    * LayoutTests/security/schedule-request-object-then-move-plugin-to-frameless-document-crash-expected.txt: Added.
    * LayoutTests/security/schedule-request-object-then-move-plugin-to-frameless-document-crash.html: Added.
    * Source/WebCore/html/HTMLPlugInImageElement.cpp:
    (WebCore::HTMLPlugInImageElement::requestObject):

    Canonical link: https://commits.webkit.org/274097.9@webkit-2024.2-embargoed

    Canonical link: https://commits.webkit.org/272448.695@safari-7618-branch

Canonical link: https://commits.webkit.org/274313.227@webkitglib/2.44


  Commit: fc7fbeae9b3d19a23379e1b608c40d329623e644
      https://github.com/WebKit/WebKit/commit/fc7fbeae9b3d19a23379e1b608c40d329623e644
  Author: Mikhail R. Gadelha <mikhail at igalia.com>
  Date:   2024-05-13 (Mon, 13 May 2024)

  Changed paths:
    A LayoutTests/fast/dom/set-attribute-and-normalize-in-event-expected.txt
    A LayoutTests/fast/dom/set-attribute-and-normalize-in-event.html
    M Source/WebCore/dom/ContainerNode.cpp

  Log Message:
  -----------
  Cherry-pick 274097.10 at webkit-2024.2-embargoed (65b1fae34533). https://bugs.webkit.org/show_bug.cgi?id=268765

    Use RefPtr local variable for nextChild in insertChildrenBeforeWithoutPreInsertionValidityCheck
    https://bugs.webkit.org/show_bug.cgi?id=268765

    Reviewed by Ryosuke Niwa and Chris Dumez.

    This patch adds a RefPtr to hold a reference to nextChild so that the
    pointer stay valid through the scope of the function.

    In the test case, the removeChild() call (from the before() call in the js
    script) triggers a DOMSubtreeModified event, which eventually calls normalize.
    The normalize() call can destroy text elements when normalizing the content of
    the node if there is no one holding the reference to that node, so holding
    nextChild in a RefPtr prevents us from reading an invalid pointer.

    * LayoutTests/fast/dom/set-attribute-and-normalize-in-event-expected.txt: Added.
    * LayoutTests/fast/dom/set-attribute-and-normalize-in-event.html: Added.
    * Source/WebCore/dom/ContainerNode.cpp:
    (WebCore::ContainerNode::insertChildrenBeforeWithoutPreInsertionValidityCheck):

    Canonical link: https://commits.webkit.org/274097.10@webkit-2024.2-embargoed

    Canonical link: https://commits.webkit.org/272448.696@safari-7618-branch

Canonical link: https://commits.webkit.org/274313.228@webkitglib/2.44


  Commit: 7b3640219893e6de5b3f91d7a19c800d03396ba1
      https://github.com/WebKit/WebKit/commit/7b3640219893e6de5b3f91d7a19c800d03396ba1
  Author: Yijia Huang <yijia_huang at apple.com>
  Date:   2024-05-13 (Mon, 13 May 2024)

  Changed paths:
    A JSTests/stress/ecs-store-with-loop.js
    M Source/JavaScriptCore/b3/B3EliminateCommonSubexpressions.cpp
    M Source/JavaScriptCore/b3/testb3.h
    M Source/JavaScriptCore/b3/testb3_3.cpp

  Log Message:
  -----------
  Cherry-pick 272448.698 at safari-7618-branch (e6aa0aa96d51). https://bugs.webkit.org/show_bug.cgi?id=265426

    [JSC] B3::EliminateCommonSubexpression shouldn't remove reads info after processing each block
    https://bugs.webkit.org/show_bug.cgi?id=265426
    rdar://118832222

    Reviewed by Yusuke Suzuki.

    Eliminate common subexpressions in B3 is used to remove redundant B3 nodes.
    Current algorithm removes block reads info after processing each block. This is wrong
    since some B3 nodes may be deleted erroneously due to the missing reads info from
    the processed blocks. To fix this issue, we should update block reads info after
    processing each node.

    * JSTests/stress/ecs-store-with-loop.js: Added.
    (foo):
    (main):
    * Source/JavaScriptCore/b3/B3EliminateCommonSubexpressions.cpp:
    * Source/JavaScriptCore/b3/testb3.h:
    * Source/JavaScriptCore/b3/testb3_3.cpp:
    (testCSEStoreWithLoop):
    (addShrTests):

    Canonical link: https://commits.webkit.org/272448.698@safari-7618-branch

Canonical link: https://commits.webkit.org/274313.229@webkitglib/2.44


  Commit: ca6f2c7353099c87b8aa521d6c96b3a0077963f2
      https://github.com/WebKit/WebKit/commit/ca6f2c7353099c87b8aa521d6c96b3a0077963f2
  Author: Keith Miller <keith_miller at apple.com>
  Date:   2024-05-13 (Mon, 13 May 2024)

  Changed paths:
    A JSTests/stress/bound-constructor-change-prototype-clears-cache.js
    A JSTests/stress/put-prototype-to-normal-function-shouldnt-be-cached.js
    M Source/JavaScriptCore/bytecode/InternalFunctionAllocationProfile.h
    M Source/JavaScriptCore/bytecode/ObjectAllocationProfileInlines.h
    M Source/JavaScriptCore/dfg/DFGOperations.cpp
    M Source/JavaScriptCore/runtime/CommonSlowPaths.cpp
    M Source/JavaScriptCore/runtime/FunctionRareData.h
    M Source/JavaScriptCore/runtime/InternalFunction.cpp
    M Source/JavaScriptCore/runtime/JSFunction.cpp
    M Source/JavaScriptCore/runtime/JSFunction.h
    M Source/JavaScriptCore/runtime/JSFunctionInlines.h

  Log Message:
  -----------
  Cherry-pick 272448.699 at safari-7618-branch (96283e8a5f10). https://bugs.webkit.org/show_bug.cgi?id=270302

    Changing a JSFunction's prototype property should clear allocation caches
    https://bugs.webkit.org/show_bug.cgi?id=270302
    rdar://121657868

    Reviewed by Alexey Shvayka and Yusuke Suzuki.

    Right now we only clear the allocation watchpoint if a JSFunction `mayHaveNonReifiedPrototype()` when setting
    the .prototype property. This is semantically incorrect in the case of `new.target` bound functions because we will cache
    the wrong value.

    This patch makes it so we always file the allocation profile watchpoint when turning either of the allocation profiles.
    When turning the ObjectAllocationProfile (used by op_create_this) we assert the watchpoint has already been fired as it
    should've already happened when the new .prototype value was set. When turning the InternalFunctionAllocationProfile (used
    by createSubclassStructure when subclassing InternalFunction/Reflect.construct) its possible to pass the same JSFunction
    to two different InternalFunctions, which will turn the profile.

    * JSTests/stress/bound-constructor-change-prototype-clears-cache.js: Added.
    (empty):
    (test1.const.newTarget):
    (test1):
    (test2.const.newTarget):
    (test2.Opt):
    (test2):
    (test3.const.newTarget):
    (main):
    * JSTests/stress/put-prototype-to-normal-function-shouldnt-be-cached.js: Added.
    (opt):
    (main.target):
    (main):
    * Source/JavaScriptCore/bytecode/InternalFunctionAllocationProfile.h:
    (JSC::InternalFunctionAllocationProfile::createAllocationStructureFromBase):
    * Source/JavaScriptCore/bytecode/ObjectAllocationProfileInlines.h:
    (JSC::ObjectAllocationProfileBase<Derived>::initializeProfile):
    * Source/JavaScriptCore/dfg/DFGOperations.cpp:
    (JSC::DFG::JSC_DEFINE_JIT_OPERATION):
    * Source/JavaScriptCore/runtime/CommonSlowPaths.cpp:
    (JSC::JSC_DEFINE_COMMON_SLOW_PATH):
    (JSC::createInternalFieldObject):
    * Source/JavaScriptCore/runtime/FunctionRareData.h:
    * Source/JavaScriptCore/runtime/InternalFunction.cpp:
    (JSC::InternalFunction::createSubclassStructure):
    * Source/JavaScriptCore/runtime/JSFunction.cpp:
    (JSC::JSFunction::prototypeForConstruction):
    (JSC::JSFunction::allocateAndInitializeRareData):
    (JSC::JSFunction::initializeRareData):
    (JSC::JSFunction::put):
    (JSC::JSFunction::defineOwnProperty):
    * Source/JavaScriptCore/runtime/JSFunction.h:
    * Source/JavaScriptCore/runtime/JSFunctionInlines.h:
    (JSC::JSFunction::canUseAllocationProfiles):
    (JSC::JSFunction::ensureRareDataAndObjectAllocationProfile):
    (JSC::JSFunction::canUseAllocationProfile): Deleted.
    (JSC::JSFunction::ensureRareDataAndAllocationProfile): Deleted.

    Canonical link: https://commits.webkit.org/272448.699@safari-7618-branch

Canonical link: https://commits.webkit.org/274313.230@webkitglib/2.44


  Commit: 90134643e6487378454d12e0656e7b7aa9962966
      https://github.com/WebKit/WebKit/commit/90134643e6487378454d12e0656e7b7aa9962966
  Author: Darryl Parkinson <d_parkinson at apple.com>
  Date:   2024-05-13 (Mon, 13 May 2024)

  Changed paths:
    M Source/WebCore/workers/service/server/SWServerWorker.cpp
    M Source/WebCore/workers/service/server/SWServerWorker.h
    M Source/WebKit/NetworkProcess/ServiceWorker/WebSWServerToContextConnection.cpp
    M Source/WebKit/NetworkProcess/ServiceWorker/WebSWServerToContextConnection.h

  Log Message:
  -----------
  Cherry-pick 272448.701 at safari-7618-branch (be630dbb12c9). https://bugs.webkit.org/show_bug.cgi?id=270302

    Ensure that the SWServerWorker is in the correct state before finishing installation
    rdar://121429889

    Reviewed by Youenn Fablet.

    Ensure that the SWServerWorker is in the expected state and bail if this method is triggered on a SWServerWorker in a different state. This method is callable over CoreIPC passing a ServiceWorkerIdentifier. Passing the ID of a service worker in any other state will reach the RELEASE_ASSERT

    * Source/WebCore/workers/service/server/SWServerWorker.cpp:
    (WebCore::SWServerWorker::didFinishInstall):

    Canonical link: https://commits.webkit.org/272448.701@safari-7618-branch

Canonical link: https://commits.webkit.org/274313.231@webkitglib/2.44


  Commit: 48631228bef3c06358719a7522ec29c43198b643
      https://github.com/WebKit/WebKit/commit/48631228bef3c06358719a7522ec29c43198b643
  Author: Aditya Keerthi <akeerthi at apple.com>
  Date:   2024-05-13 (Mon, 13 May 2024)

  Changed paths:
    A LayoutTests/fast/forms/ios/file-upload-panel-dismiss-when-view-removed-from-window-expected.txt
    A LayoutTests/fast/forms/ios/file-upload-panel-dismiss-when-view-removed-from-window.html
    M Source/WebKit/UIProcess/Cocoa/WKContactPicker.h
    M Source/WebKit/UIProcess/Cocoa/WKContactPicker.mm
    M Source/WebKit/UIProcess/ios/WKContentView.mm
    M Source/WebKit/UIProcess/ios/WKContentViewInteraction.h
    M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm

  Log Message:
  -----------
  Cherry-pick 272448.703 at safari-7618-branch (a3524e350ec9). https://bugs.webkit.org/show_bug.cgi?id=265602

    [iOS] File picker dialog remains after opening a new tab in 3rd-party browsers
    https://bugs.webkit.org/show_bug.cgi?id=265602
    rdar://119001046

    Reviewed by Abrar Rahman Protyasha.

    The file upload panel does not dismiss itself after a new tab is opened, and can
    end up displayed over a site that's unrelated to the one requesting the upload.

    The panel itself is a modal view controller that is presented from an appropriate
    view controller containing the `WKWebView`. Safari has explicit logic to dismiss
    presented modal view controllers on tab switch, but it is not reasonable to expect
    other clients to guarantee this behavior.

    Fix by dismissing all pickers if the `WKWebView` is removed from the hierarchy.

    * LayoutTests/fast/forms/ios/file-upload-panel-dismiss-when-view-removed-from-window-expected.txt: Added.
    * LayoutTests/fast/forms/ios/file-upload-panel-dismiss-when-view-removed-from-window.html: Added.
    * Source/WebKit/UIProcess/Cocoa/WKContactPicker.h:
    * Source/WebKit/UIProcess/Cocoa/WKContactPicker.mm:
    (-[WKContactPicker dismiss]):

    Add a new hook to dismiss the contact picker.

    * Source/WebKit/UIProcess/ios/WKContentView.mm:
    (-[WKContentView willMoveToWindow:]):

    If the content view has moved to a `nil` window, it has been removed from the
    view hierarchy, and presented pickers should be dismissed.

    * Source/WebKit/UIProcess/ios/WKContentViewInteraction.h:
    * Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
    (-[WKContentView cleanUpInteraction]):

    Factor out logic into `-[WKContentView dismissPickers]`.

    (-[WKContentView dismissPickers]):

    Dismiss all pickers that the content view is aware of.

    Canonical link: https://commits.webkit.org/272448.703@safari-7618-branch

Canonical link: https://commits.webkit.org/274313.232@webkitglib/2.44


  Commit: 2f99dbcc1ef622fc11f18fb4b46926ddd96fa87c
      https://github.com/WebKit/WebKit/commit/2f99dbcc1ef622fc11f18fb4b46926ddd96fa87c
  Author: Wenson Hsieh <wenson_hsieh at apple.com>
  Date:   2024-05-13 (Mon, 13 May 2024)

  Changed paths:
    M Source/WebCore/Modules/webaudio/AudioBasicProcessorNode.h
    M Source/WebCore/Modules/webaudio/AudioBuffer.cpp
    M Source/WebCore/Modules/webaudio/AudioBuffer.h
    M Source/WebCore/Modules/webaudio/AudioBufferSourceNode.cpp
    M Source/WebCore/Modules/webaudio/AudioBufferSourceNode.h
    M Source/WebCore/Modules/webaudio/AudioNode.h
    M Source/WebCore/Modules/webaudio/AudioNodeOutput.cpp
    M Source/WebCore/Modules/webaudio/AudioNodeOutput.h
    M Source/WebCore/Modules/webaudio/AudioWorkletNode.cpp
    M Source/WebCore/Modules/webaudio/BaseAudioContext.h
    M Source/WebCore/Modules/webaudio/DynamicsCompressorNode.h
    M Source/WebCore/Modules/webaudio/OfflineAudioContext.cpp
    M Source/WebCore/Modules/webaudio/OfflineAudioContext.h
    M Source/WebCore/Modules/webaudio/OscillatorNode.h
    M Source/WebCore/platform/audio/AudioUtilities.cpp
    M Source/WebCore/platform/audio/AudioUtilities.h
    M Tools/TestWebKitAPI/Tests/WebKit/AdvancedPrivacyProtections.mm
    M Tools/TestWebKitAPI/Tests/WebKitCocoa/audio-fingerprinting.html

  Log Message:
  -----------
  Cherry-pick 272448.707 at safari-7618-branch (3c7dd1781475). https://bugs.webkit.org/show_bug.cgi?id=270767

    AudioBuffer noise injection in Private Browsing can be negated using a looping audio buffer source
    https://bugs.webkit.org/show_bug.cgi?id=270767
    rdar://124156971

    Reviewed by Chris Dumez, Charlie Wolfe and Matthew Finkel.

    Implement several mitigations to make it impractical to reverse noise injection by looping a single
    audio sample many times in a single audio buffer and averaging the results.

    1.  Adjust noise injection to use normally-distributed noise, instead of a uniform random
        distribution. This raises the bar for "averaging-style" attacks, which can currently converge on
        a stable result by averaging the min/max values in the random distribution. A similar attack
        will now require more iterations to converge on the original value.

    2.  Store previously-generated random values while applying noise, and reapply these random values
        to the values that are encountered repeatedly. This ensures that an attacker does not gain more
        information about the original value, by causing it to be computed repeatedly in the same audio
        buffer.

    3.  Instead of uniformly applying a fixed noise level (0.001) for all readback using
        `OfflineAudioContext`, allow certain node types that are known to expose hardware or OS
        differences (i.e. `DynamicsCompressorNode` and `OscillatorNode`) to increase the amount of
        injected noise beyond the baseline of 0.1%. `AudioBufferSourceNode`, in particular, will amplify
        the noise level more, depending on the number of times the audio buffer is looped.

    * Source/WebCore/Modules/webaudio/AudioBasicProcessorNode.h:
    * Source/WebCore/Modules/webaudio/AudioBuffer.cpp:
    (WebCore::AudioBuffer::releaseMemory):

    Replace the single boolean flag (`m_needsAdditionalNoise`) with a `m_noiseInjectionMultiplier`,
    which indicates the magnitude of noise injection (the standard deviation of the normal distribution
    used to inject noise).

    (WebCore::AudioBuffer::copyToChannel):
    (WebCore::AudioBuffer::zero):
    (WebCore::AudioBuffer::copyTo const):
    (WebCore::AudioBuffer::applyNoiseIfNeeded):
    * Source/WebCore/Modules/webaudio/AudioBuffer.h:
    (WebCore::AudioBuffer::increaseNoiseInjectionMultiplier):
    (WebCore::AudioBuffer::noiseInjectionMultiplier const):
    (WebCore::AudioBuffer::setNeedsAdditionalNoise): Deleted.
    * Source/WebCore/Modules/webaudio/AudioBufferSourceNode.cpp:
    (WebCore::AudioBufferSourceNode::noiseInjectionMultiplier const):

    Increase the noise injection level for an audio buffer, if it's downstream from an
    `AudioBufferSourceNode` that loops many times. For an audio buffer source that loops more than 200
    times, this boosts the existing noise level for the audio buffer by a factor of 0.005 per loop,
    leading to a massive amount of noise in the case where a tiny sample is looped back-to-back in a
    large buffer.

    * Source/WebCore/Modules/webaudio/AudioBufferSourceNode.h:
    * Source/WebCore/Modules/webaudio/AudioNode.h:
    (WebCore::AudioNode::noiseInjectionMultiplier const):

    Add a subclassing hook that allows each `AudioNode` subclass to inject additional noise when reading
    back the final `AudioBuffer`. This allows us to selectively increase the amount of injected noise
    when using specific types of audio nodes, which are known to expose larger differences w.r.t. the
    underlying OS or CPU architecture.

    * Source/WebCore/Modules/webaudio/AudioNodeOutput.cpp:
    (WebCore::AudioNodeOutput::forEachInputNode const):

    Add a helper method to iterate over each input node (i.e. the next destination in the processing
    graph) that's attached to this output. Note that this must be called from underneath the context's
    graph lock.

    * Source/WebCore/Modules/webaudio/AudioNodeOutput.h:
    * Source/WebCore/Modules/webaudio/AudioWorkletNode.cpp:
    (WebCore::AudioWorkletNode::process):

    Increase the noise level when passing raw data into worklets, to adjust for the new normally-
    distributed noise injection.

    * Source/WebCore/Modules/webaudio/BaseAudioContext.h:
    (WebCore::BaseAudioContext::referencedSourceNodes const):

    Add a helper method to iterate over all source nodes in the audio context; must be called only when
    the context's graph lock is held.

    * Source/WebCore/Modules/webaudio/DynamicsCompressorNode.h:

    Add additional buffer readback noise when using certain audio node types.

    * Source/WebCore/Modules/webaudio/OfflineAudioContext.cpp:
    (WebCore::OfflineAudioContext::OfflineAudioContext):
    (WebCore::OfflineAudioContext::lazyInitialize):
    (WebCore::OfflineAudioContext::increaseNoiseMultiplierIfNeeded):

    Upon initialization, traverse the audio processing graph in search for audio nodes that warrant
    additional noise injection, and accumulate this extra noise on the target buffer.

    * Source/WebCore/Modules/webaudio/OfflineAudioContext.h:
    * Source/WebCore/Modules/webaudio/OscillatorNode.h:
    * Source/WebCore/platform/audio/AudioUtilities.cpp:
    (WebCore::AudioUtilities::applyNoise):

    Switch to normally-distributed noise injection, rather than uniformally random noise. Additionally,
    ensure that if a value appears again in the same buffer, it'll use the same, previously computed
    noise multiplier value instead of a newly generated random value.

    * Source/WebCore/platform/audio/AudioUtilities.h:
    * Tools/TestWebKitAPI/Tests/WebKit/AdvancedPrivacyProtections.mm:
    (TestWebKitAPI::TEST):
    * Tools/TestWebKitAPI/Tests/WebKitCocoa/audio-fingerprinting.html:

    Add a new test case to exercise these mitigations.

    Canonical link: https://commits.webkit.org/272448.707@safari-7618-branch

Canonical link: https://commits.webkit.org/274313.233@webkitglib/2.44


  Commit: 81da5ef39552f1460189deafc42663ad5def64a4
      https://github.com/WebKit/WebKit/commit/81da5ef39552f1460189deafc42663ad5def64a4
  Author: Justin Michaud <justin_michaud at apple.com>
  Date:   2024-05-13 (Mon, 13 May 2024)

  Changed paths:
    A JSTests/stress/getter-setter-ai.js
    M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp
    M Source/JavaScriptCore/runtime/Operations.cpp

  Log Message:
  -----------
  Cherry-pick 272448.708 at safari-7618-branch (b42cc4168b71). https://bugs.webkit.org/show_bug.cgi?id=270659

    Difference in semantics between jsTypeStringForValueWithConcurrency and buildTypeOf
    https://bugs.webkit.org/show_bug.cgi?id=270659
    rdar://124116542

    Reviewed by Yusuke Suzuki.

    Consider the given test case:

    Object1: 0x30000bba0 %DL (should never getByOffset p3 of this, it is a GetterSetter)
    Object2: 0x30000bc10 %DS (p3 is fine)

     Before LICM:
    32  0 40:   D at 26:<!0:->	FilterGetByStatus(Check:Untyped:D at 7, MustGen, (Simple, <id='uid:(p1)', [0x30000bc10:[0xbc10/48144, Function, (0/0, 3/4){p1:64, p2:65, p3:66}, NonArray, Proto:0x11706ddc8, Leaf (Watched)], 0x30000bba0:[0xbba0/48032, Function, (0/0, 3/4){p1:64, p2:65, p3:66}, NonArray, Proto:0x11706ddc8, Leaf (Watched)]], [], offset = 64>, seenInJIT = true), W:SideState, bc#4, ExitValid)
    33  0 40:   D at 15:<!0:->	AssertNotEmpty(Check:Untyped:D at 7, MustGen, W:SideState, Exits, bc#4, ExitValid)
    34  0 40:   D at 28:<!0:->	CheckStructure(Cell:D at 7, MustGen, [%DS:Function, %DL:Function], R:JSCell_structureID, Exits, bc#4, ExitValid)
    35  0 40:   D at 29:< 2:->	GetButterfly(Cell:D at 7, Storage|PureNum|NeedsNegZero|NeedsNaNOrInfinity|UseAsOther, Other, R:JSObject_butterfly, bc#4, ExitValid)
    36  0 40:   D at 30:< 1:->	GetByOffset(Check:Untyped:D at 29, KnownCell:D at 7, JS|PureInt, Int32, id0{p1}, 64, R:NamedProperties(0), bc#4, ExitValid)  predicting Int32

    ... branching

    6  7 40:   D at 87:<!0:->	FilterGetByStatus(Check:Untyped:D at 7, MustGen, (Simple, <id='uid:(p3)', [0x30000bc10:[0xbc10/48144, Function, (0/0, 3/4){p1:64, p2:65, p3:66}, NonArray, Proto:0x11706ddc8, Leaf (Watched)]], [], offset = 66>, seenInJIT = true), W:SideState, bc#45, ExitValid)
    7  7 40:   D at 89:<!0:->	CheckStructure(Cell:D at 7, MustGen, [%DS:Function], R:JSCell_structureID, Exits, bc#45, ExitValid)
    8  7 40:   D at 91:< 2:->	GetByOffset(Check:Untyped:D at 29, KnownCell:D at 7, JS|PureNum|NeedsNegZero|NeedsNaNOrInfinity|UseAsOther, BoolInt32, id3{p3}, 66, R:NamedProperties(3), bc#45, ExitValid)  predicting BoolInt32
    11  7 40:   D at 94:< 2:->	TypeOf(Check:Untyped:Kill:D at 91, JS|PureNum|NeedsNegZero|NeedsNaNOrInfinity|UseAsOther, StringIdent, Exits, bc#51, ExitValid)

    Note that we never get p3 of DL

    After LICM blind hoist:
     34  0 41:   D at 28:<!0:->	CheckStructure(Cell:D at 7, MustGen, [%DS:Function, %DL:Function], R:JSCell_structureID, Exits, bc#4, ExitValid)
     35  0 41:   D at 29:< 2:->	GetButterfly(Cell:D at 7, Storage|PureNum|NeedsNegZero|NeedsNaNOrInfinity|UseAsOther, Other, R:JSObject_butterfly, bc#4, ExitValid)
     36  0 41:   D at 30:< 1:->	GetByOffset(Check:Untyped:D at 29, KnownCell:D at 7, JS|PureInt, Int32, id0{p1}, 64, R:NamedProperties(0), bc#4, ExitValid)  predicting Int32
     44  0 41:   D at 48:<!0:->	CheckIsConstant(Cell:D at 7, MustGen, <0x13908f140, Function>, object1#B5FU55/<nogen>:[0x13909da00], Exits, bc#25, exit: bc#17, ExitValid, WasHoisted)
     45  0 41:   D at 91:< 2:->	GetByOffset(Check:Untyped:D at 29, KnownCell:D at 7, JS|PureNum|NeedsNegZero|NeedsNaNOrInfinity|UseAsOther, BoolInt32, id3{p3}, 66, R:NamedProperties(3), bc#45, exit: bc#17, ExitValid)  predicting BoolInt32
     46  0 41:   D at 94:< 2:->	TypeOf(Check:Untyped:Kill:D at 91, JS|PureNum|NeedsNegZero|NeedsNaNOrInfinity|UseAsOther, StringIdent, Exits, bc#51, exit: bc#17, ExitValid, WasHoisted)

    The GetByOffset is hoisted without its guarding CheckStructure, and it accesses p3 unexpectedly. SafeToExecute says it is
    safe because it won't crash or produce a malformed JSValue. Honestly, fair.

    This patch fixes the semantic difference between AI and runtime for GetterSetter objects.
    Stopping the GetterSetter from being hoisted may be too costly and restrictive, and it
    doesn't get leaked anyway.

    The string result (which was [object] but is now [symbol]) doesn't really matter, it should
    never leak to user code anyway. Even if it does, it is just a string.

    * JSTests/stress/getter-setter-ai.js: Added.
    (opt):
    (watchP3.cache):
    (watchP3):
    (main.let.object1):
    (main.let.object2):
    (main):
    * Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:
    (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
    * Source/JavaScriptCore/runtime/Operations.cpp:
    (JSC::jsTypeStringForValueWithConcurrency):

    Canonical link: https://commits.webkit.org/272448.708@safari-7618-branch

Canonical link: https://commits.webkit.org/274313.234@webkitglib/2.44


  Commit: 21a806bc90ab33ac3d588e10fc0313d9971a2551
      https://github.com/WebKit/WebKit/commit/21a806bc90ab33ac3d588e10fc0313d9971a2551
  Author: Alex Christensen <achristensen at apple.com>
  Date:   2024-05-13 (Mon, 13 May 2024)

  Changed paths:
    M Source/WebCore/bindings/js/SerializedScriptValue.cpp

  Log Message:
  -----------
  Cherry-pick 272448.733 at safari-7618-branch (7d7e9c948a3b). https://bugs.webkit.org/show_bug.cgi?id=270949

    Verify range of ArrayBuffer when deserializing an ArrayBufferView
    https://bugs.webkit.org/show_bug.cgi?id=270949
    rdar://123906915

    Reviewed by Chris Dumez.

    byteOffset and length come from an untrusted source, and if out of bounds they
    can lead to arbitrary reads.  If they are out of bounds, fail to deserialize.

    * Source/WebCore/bindings/js/SerializedScriptValue.cpp:
    (WebCore::CloneDeserializer::readArrayBufferViewImpl):

    Canonical link: https://commits.webkit.org/272448.733@safari-7618-branch

Canonical link: https://commits.webkit.org/274313.235@webkitglib/2.44


  Commit: 86af20805f934d22c283a6158510210b38bd128f
      https://github.com/WebKit/WebKit/commit/86af20805f934d22c283a6158510210b38bd128f
  Author: Simon Fraser <simon.fraser at apple.com>
  Date:   2024-05-13 (Mon, 13 May 2024)

  Changed paths:
    M Source/WebCore/page/scrolling/AsyncScrollingCoordinator.cpp
    M Source/WebCore/page/scrolling/ScrollingStateOverflowScrollProxyNode.cpp
    M Source/WebCore/page/scrolling/ScrollingStateStickyNode.cpp
    M Source/WebCore/page/scrolling/ScrollingTreeOverflowScrollProxyNode.cpp
    M Source/WebCore/page/scrolling/ScrollingTreeStickyNode.cpp

  Log Message:
  -----------
  Cherry-pick 272448.773 at safari-7618-branch (052845bc6c5c). https://bugs.webkit.org/show_bug.cgi?id=271395

    [UIProcess] Unsafe downcast in ScrollingTreeStickyNode::computeLayerPosition leading to type confusion.
    https://bugs.webkit.org/show_bug.cgi?id=271395
    rdar://125084284

    Reviewed by Chris Dumez.

    Fix various places in scrolling tree-related code where we do unchecked `downcast<>`s of
    scrolling tree types.

    * Source/WebCore/page/scrolling/AsyncScrollingCoordinator.cpp:
    (WebCore::AsyncScrollingCoordinator::frameViewVisualViewportChanged):
    (WebCore::AsyncScrollingCoordinator::setViewportConstraintedNodeConstraints):
    * Source/WebCore/page/scrolling/ScrollingStateOverflowScrollProxyNode.cpp:
    (WebCore::ScrollingStateOverflowScrollProxyNode::dumpProperties const):
    * Source/WebCore/page/scrolling/ScrollingStateStickyNode.cpp:
    (WebCore::ScrollingStateStickyNode::computeLayerPosition const):
    * Source/WebCore/page/scrolling/ScrollingTreeOverflowScrollProxyNode.cpp:
    (WebCore::ScrollingTreeOverflowScrollProxyNode::dumpProperties const):
    * Source/WebCore/page/scrolling/ScrollingTreeStickyNode.cpp:
    (WebCore::ScrollingTreeStickyNode::computeLayerPosition const):

    Canonical link: https://commits.webkit.org/272448.773@safari-7618-branch

Canonical link: https://commits.webkit.org/274313.236@webkitglib/2.44


  Commit: ad2702925dfa9f5b690742dee324665a65aa88b3
      https://github.com/WebKit/WebKit/commit/ad2702925dfa9f5b690742dee324665a65aa88b3
  Author: Chris Dumez <cdumez at apple.com>
  Date:   2024-05-13 (Mon, 13 May 2024)

  Changed paths:
    M Source/WebCore/Modules/webaudio/WaveShaperNode.cpp
    M Source/WebCore/Modules/webaudio/WaveShaperNode.h

  Log Message:
  -----------
  Cherry-pick 272448.781 at safari-7618-branch (bc1031419c11). https://bugs.webkit.org/show_bug.cgi?id=271654

    Use-after-free in WebCore::WaveShaperDSPKernel::processCurve()
    https://bugs.webkit.org/show_bug.cgi?id=271654
    rdar://123631199

    Reviewed by Jer Noble.

    Make sure WaveShaperNode::curveForBindings() clones our internal array
    before returning it to JS. This is important so that the JS cannot
    modify our internal array on the main thread while the audio thread is
    using it for rendering.

    * Source/WebCore/Modules/webaudio/WaveShaperNode.cpp:
    (WebCore::WaveShaperNode::curveForBindings):
    * Source/WebCore/Modules/webaudio/WaveShaperNode.h:

    Canonical link: https://commits.webkit.org/272448.781@safari-7618-branch

Canonical link: https://commits.webkit.org/274313.237@webkitglib/2.44


  Commit: 9aa9b7096ce0f2670f25c3a19e4c0460df379970
      https://github.com/WebKit/WebKit/commit/9aa9b7096ce0f2670f25c3a19e4c0460df379970
  Author: Žan Doberšek <zdobersek at igalia.com>
  Date:   2024-05-13 (Mon, 13 May 2024)

  Changed paths:
    A LayoutTests/fast/css/line-break-fixed-position-container-expected.txt
    A LayoutTests/fast/css/line-break-fixed-position-container.html
    M Source/WebCore/rendering/RenderObject.cpp

  Log Message:
  -----------
  Cherry-pick 274097.12 at webkit-2024.2-embargoed (5bd3a1c2b0ac). https://bugs.webkit.org/show_bug.cgi?id=264631

    Special case treatment of out-of-flow RenderLineBreak
    https://bugs.webkit.org/show_bug.cgi?id=264631
    rdar://114719845

    Reviewed by Alan Baradlay.

    Out-of-flow RenderLineBreaks have problems when relying on default out-of-flow support of the render
    tree, see https://bugs.webkit.org/show_bug.cgi?id=270977.

    To fix the problem we change containerForElement and containingBlock to treat RenderLineBreak that are out-of-flow as
    if they have position: static.

    * LayoutTests/fast/css/line-break-fixed-position-container-expected.txt: Added.
    * LayoutTests/fast/css/line-break-fixed-position-container.html: Added.
    * Source/WebCore/rendering/RenderObject.cpp:
    (WebCore::RenderObject::containingBlock const):
    (WebCore::containerForElement):

    Canonical link: https://commits.webkit.org/274097.12@webkit-2024.2-embargoed

    Canonical link: https://commits.webkit.org/272448.783@safari-7618-branch

Canonical link: https://commits.webkit.org/274313.238@webkitglib/2.44


  Commit: 538c80da087b299c0ab548e9c93acbeb7c73997b
      https://github.com/WebKit/WebKit/commit/538c80da087b299c0ab548e9c93acbeb7c73997b
  Author: Justin Michaud <justin at justinmichaud.com>
  Date:   2024-05-13 (Mon, 13 May 2024)

  Changed paths:
    A JSTests/stress/get-by-val-hoist-above-structure-2.js
    A JSTests/stress/get-by-val-hoist-above-structure.js
    M Source/JavaScriptCore/dfg/DFGBasicBlock.h
    M Source/JavaScriptCore/dfg/DFGConstantFoldingPhase.cpp
    M Source/JavaScriptCore/dfg/DFGInPlaceAbstractState.cpp
    M Source/JavaScriptCore/dfg/DFGInPlaceAbstractState.h

  Log Message:
  -----------
  Cherry-pick 272448.796 at safari-7618-branch (8d5ba1eecf30). https://bugs.webkit.org/show_bug.cgi?id=271435

    DFG Constant Folding phase can see inconsistent view of world, causing LICM to miscompile
    https://bugs.webkit.org/show_bug.cgi?id=271435
    rdar://124506508

    Reviewed by Yusuke Suzuki.

    Consider the following example:

    ============================================================================================================
    FIRST SLEEP (before performCFA)

         D at 80:< 10:->	JSConstant(JS|PureNum|NeedsNegZero|NeedsNaNOrInfinity|UseAsOther, Final, Weak:Object: 0x13a0e8140 with butterfly 0x0(base=0xfffffffffffffff8) (Structure %AJ:Object), StructureID: 40640, bc#0, ExitValid)

         D at 126:<!0:->	FilterGetByStatus(Check:Untyped:D at 80, MustGen, (Simple, <id='uid:(x)', [0x300009ec0:[0x9ec0/40640, Object, (2/2, 0/0){x:0, toJSON:1}, NonArray, Proto:0x1180348d8]], [], offset = 0>, seenInJIT = true), W:SideState, bc#112, ExitValid)
         D at 128:<!0:->	CheckStructure(Cell:D at 80, MustGen, [%AJ:Object], R:JSCell_structureID, Exits, bc#112, ExitValid)
         D at 133:<!0:->	FilterGetByStatus(Check:Untyped:D at 80, MustGen, (Simple, <id='uid:(toJSON),cell:(String (atomic),8Bit:(1),length:(6): toJSON, StructureID: 16976)', [0x300009ec0:[0x9ec0/40640, Object, (2/2, 0/0){x:0, toJSON:1}, NonArray, Proto:0x1180348d8]], [], offset = 1>, seenInJIT = true), W:SideState, bc#118, ExitValid)
         D at 136:< 4:->	GetByOffset(KnownCell:D at 80, KnownCell:D at 80, JS|PureNum|NeedsNaNOrInfinity|UseAsOther|ReallyWantsInt, BoolInt32, id6{toJSON}, 1, R:NamedProperties(6), bc#118, ExitValid)  predicting BoolInt32
         D at 138:<!0:->	Check(Check:Int32:D at 136, MustGen, Exits, bc#118, exit: bc#124, ExitValid)
         D at 140:<!0:->	Branch(Boolean:D at 35, MustGen, T:#9/w:10.000000, F:#12/w:10.000000, W:SideState, bc#124, ExitValid)

         D at 4:< 1:->	GetButterfly(Cell:D at 104, Storage|PureInt, R:JSObject_butterfly, bc#127, ExitValid)
         D at 1:<!1:->	CheckInBounds(Int32:D at 136, KnownInt32:D at 151, JS|MustGen|PureInt, Int32, Exits, bc#127, ExitValid)
         D at 143:< 3:->	GetByVal(KnownCell:D at 104, Int32:Kill:D at 136, Check:Untyped:Kill:D at 4, Check:Untyped:Kill:D at 1, JS|VarArgs|PureNum|NeedsNegZero|NeedsNaNOrInfinity|UseAsOther, StringIdent, Contiguous+OriginalCopyOnWriteArray+InBoundsSaneChain+AsIs+Read, R:Butterfly_publicLength,IndexedContiguousProperties, Exits, bc#127, ExitValid)  predicting StringIdent

         %AJ:Object                                  = 0x300009ec0:[0x9ec0/40640, Object, (2/2, 0/0){x:0, toJSON:1}, NonArray, Proto:0x1180348d8]

    Execution:
         AI GetByOffset D at 136 AI says (BoolInt32, Int32: 0, none:StructuresAreClobbered) base: (Final, NonArray, [0x300009ec0:[0x9ec0/40640, Object, (2/2, 0/0){x:0, toJSON:1}, NonArray, Proto:0x1180348d8]], Object: 0x13a0e8140 with butterfly 0x0(base=0xfffffffffffffff8) (Structure 0x300009ec0:[0x9ec0/40640, Object, (2/2, 0/0){x:0, toJSON:1}, NonArray, Proto:0x1180348d8]), StructureID: 40640, 1:StructuresAreWatched) state StructuresAreWatched
         AI CheckInBounds D at 1 AI says left Int32:D at 136 is Int32: 0

    SECOND SLEEP (after performCFA, before performConstantFolding)

    Note that the jsconstant has a structure transition at this point.

         D at 80:< 10:->	JSConstant(JS|PureNum|NeedsNegZero|NeedsNaNOrInfinity|UseAsOther, Final, Weak:Object: 0x13a0e8140 with butterfly 0x8014002388(base=0x8014002380) (Structure %AR:Object), StructureID: 40976, bc#0, ExitValid)

         D at 126:<!0:->	FilterGetByStatus(Check:Untyped:D at 80, MustGen, (Simple, <id='uid:(x)', [0x300009ec0:[0x9ec0/40640, Object, (2/2, 0/0){toJSON:1, x:0}, NonArray, Proto:0x1180348d8]], [], offset = 0>, seenInJIT = true), W:SideState, bc#112, ExitValid)
         D at 128:<!0:->	CheckStructure(Cell:D at 80, MustGen, [%AR:Object], R:JSCell_structureID, Exits, bc#112, ExitValid)
         D at 133:<!0:->	FilterGetByStatus(Check:Untyped:D at 80, MustGen, (Simple, <id='uid:(toJSON),cell:(String (atomic),8Bit:(1),length:(6): toJSON, StructureID: 16976)', [0x300009ec0:[0x9ec0/40640, Object, (2/2, 0/0){toJSON:1, x:0}, NonArray, Proto:0x1180348d8]], [], offset = 1>, seenInJIT = true), W:SideState, bc#118, ExitValid)
         D at 136:< 4:->	GetByOffset(KnownCell:D at 80, KnownCell:D at 80, JS|PureNum|NeedsNaNOrInfinity|UseAsOther|ReallyWantsInt, BoolInt32, id6{toJSON}, 1, R:NamedProperties(6), bc#118, ExitValid)  predicting BoolInt32

         D at 4:< 1:->	GetButterfly(Cell:D at 104, Storage|PureInt, R:JSObject_butterfly, bc#127, ExitValid)
         D at 1:<!1:->	CheckInBounds(Int32:D at 136, KnownInt32:D at 151, JS|MustGen|PureInt, Int32, Exits, bc#127, ExitValid)
         D at 143:< 3:->	GetByVal(KnownCell:D at 104, Int32:Kill:D at 136, Check:Untyped:Kill:D at 4, Check:Untyped:Kill:D at 1, JS|VarArgs|PureNum|NeedsNegZero|NeedsNaNOrInfinity|UseAsOther, StringIdent, Contiguous+OriginalCopyOnWriteArray+InBoundsSaneChain+AsIs+Read, R:Butterfly_publicLength,IndexedContiguousProperties, Exits, bc#127, ExitValid)  predicting StringIdent

         %AR:Object                                  = 0x300009ec0:[0x9ec0/40640, Object, (2/2, 0/0){toJSON:1, x:0}, NonArray, Proto:0x1180348d8]
         %B6:Object                                  = 0x30000a010:[0xa010/40976, Object, (2/2, 1/4){y:64, toJSON:1, x:0}, NonArray, Proto:0x1180348d8, Leaf (Watched)]

    Execution:
         AI GetByOffset D at 136 AI says (HeapTop, TOP, TOP, none:StructuresAreClobbered) base: (Final, NonArray, [0x300009ec0:[0x9ec0/40640, Object, (2/2, 0/0){toJSON:1, x:0}, NonArray, Proto:0x1180348d8]], Object: 0x13a0e8140 with butterfly 0x8014002388(base=0x8014002360) (Structure 0x30000a010:[0xa010/40976, Object, (2/2, 1/4){y:64, toJSON:1, x:0}, NonArray, Proto:0x1180348d8, Leaf (Watched)]), StructureID: 40976, 1:StructuresAreWatched) state StructuresAreWatched
         GetByOffset D at 136 AI says (HeapTop, TOP, TOP, 1:StructuresAreWatched)
         CheckInBounds D at 1 AI says left Int32:D at 136 is Int32: 0
         AI GetByOffset D at 136 AI says (HeapTop, TOP, TOP, none:StructuresAreClobbered) base: (Final, NonArray, [0x300009ec0:[0x9ec0/40640, Object, (2/2, 0/0){toJSON:1, x:0}, NonArray, Proto:0x1180348d8]], Object: 0x13a0e8140 with butterfly 0x8014002388(base=0x8014002360) (Structure 0x30000a010:[0xa010/40976, Object, (2/2, 1/4){y:64, toJSON:1, x:0}, NonArray, Proto:0x1180348d8, Leaf (Watched)]), StructureID: 40976, 1:StructuresAreWatched) state StructuresAreWatched

    SLEEP DONE
    ============================================================================================================

    The constant folding phase chooses to fold the CheckInBounds, but not the GetByOffset. At this point, this is still correct (although sub-optimal).

    1) Why does AI disagree in these two places?

    The constant folding phase doesn't re-run AI. It runs it from top to bottom on certain blocks only.
    In this example, The CheckInBounds AI proof is read directly from the block, but the GetByOffset
    has its value computed.

    1) Why can the JSConstant's structure change without triggering a watchpoint?

    The constant remains constant. We never used the fact that that it had a certain
    structure anywhere, our proofs stem from the fact that we have a CheckStructure.

    1) Why does the re-run AI pass in performConstantFolding not predict the GetByOffset to be constant?

    The structure change causes GetPropertyConcurrently to fail to get the value concurrently.
    We must assume that it is always safe to produce a more conservative result in this phase.

    Note though that if the phase returned the same value as the first time around, that would still have been
    correct! The answer to this question didn't change, we just lost the ability to compute it.

    ============================================================================================================
    Why this is a problem

    This is a classic example of a broad class of bugs affecting the JIT. Different passes can see different values as the mutator
    changes the object graph, even for the same pass. Normally this is fine, because the compiler is always narrowing its assumptions.

    Specifically, with each pass we assume more and more detailed things about the code, and guard against these assumptions
    being wrong either with watchpoints or runtime checks.

    In this example, we see that we CheckStructure. Then, as a result, we can elide nodes that are dominated by that check (like the
    GetByOffset or the CheckInBounds). As long as we never loosen that assumption again, we are fine.

    In this example, our CFA pass assumes that the GetByOffset is constant. The Constant Folding phase then assumes sometimes that it is constant,
    and sometimes that it is not. This puts us in opposition to another principle, that is the idea that we should always
    be able to answer any question asked of us conservatively and be safe. Up until this point, both of these ideas are holding true.

    Unfortunately, we also need LICM. LICM needs to run after many assumptions have already been made, and it dramatically loosens
    assumptions. In this example, LICM comes along and hoists the GetByVal(GetByOffset()) above the CheckStructure.

    If we had indeed constant folded the GetByOffset too, we would be fine to do.

    We should always be able to avoid constant folding safely.

    LICM should be able to hoist constant values safely.

    ============================================================================================================
    How to fix this generally

    1) If AI says something is constant, just make it constant then.

    This is the simplest solution, and should just work. This makes sure that what AI says is true, even if LICM moves stuff around.

    This would require some re-work of the AI phase though.

    1) LCIM should see that this isn't safe to move

    The effects here are super specific. If LICM asked the question "If I move this, is this still safe to execute?" it would
    have answered "no" in this case (without the structure check). Of course, if we hadn't removed the CheckInBounds, the answer
    would be "yes," which is also fine.

    One could imagine that this analysis would be pretty difficult.

    1) Always run the constant folder on each block.

    ```
    // This method is evil - it causes a huge maintenance headache and there is a gross amount of
    // code devoted to it. It would be much nicer to just always run the constant folder on each
    // block. But, the last time we did it, it was a 1% SunSpider regression:
    // https://bugs.webkit.org/show_bug.cgi?id=133947
    // So, we should probably keep this method.
    void setShouldTryConstantFolding(bool tryConstantFolding) { m_shouldTryConstantFolding = tryConstantFolding; }
    ```

    This would fix the issue though, as a failure to prove something at any point in time would not permit
    that proof to be used later on.

    This patch chooses the third option.

    This appears to be perf-neutral on modern hardware on JS2/3 and SP2/3.

    * JSTests/stress/get-by-val-hoist-above-structure.js: Added.
    (opt):
    (createObjectOfS1):
    (createObjectOfS2):
    (main):
    * Source/JavaScriptCore/dfg/DFGConstantFoldingPhase.cpp:
    (JSC::DFG::ConstantFoldingPhase::foldConstants):

    Canonical link: https://commits.webkit.org/272448.796@safari-7618-branch

Canonical link: https://commits.webkit.org/274313.239@webkitglib/2.44


  Commit: b541497ce00e7fa11bbaa3e06aee0d3e6de2bc63
      https://github.com/WebKit/WebKit/commit/b541497ce00e7fa11bbaa3e06aee0d3e6de2bc63
  Author: Justin Michaud <justin at justinmichaud.com>
  Date:   2024-05-13 (Mon, 13 May 2024)

  Changed paths:
    A JSTests/stress/sbfx-offset-overflow.js
    M Source/JavaScriptCore/b3/B3LowerToAir.cpp

  Log Message:
  -----------
  Cherry-pick 272448.797 at safari-7618-branch (d7ad67d3fe10). https://bugs.webkit.org/show_bug.cgi?id=271491

    SBFX should not allow imm overflow
    https://bugs.webkit.org/show_bug.cgi?id=271491
    rdar://125127373

    Reviewed by Yusuke Suzuki.

    These isel patterns should be a bit more careful with overflow.

    * JSTests/stress/sbfx-offset-overflow.js: Added.
    (foo):
    * Source/JavaScriptCore/b3/B3LowerToAir.cpp:

    Canonical link: https://commits.webkit.org/272448.797@safari-7618-branch

Canonical link: https://commits.webkit.org/274313.240@webkitglib/2.44


  Commit: 9b1e21b56b92db047d2a1d587bee2bebe7bc5b32
      https://github.com/WebKit/WebKit/commit/9b1e21b56b92db047d2a1d587bee2bebe7bc5b32
  Author: Kimmo Kinnunen <kkinnunen at apple.com>
  Date:   2024-05-13 (Mon, 13 May 2024)

  Changed paths:
    M Source/WebCore/platform/graphics/angle/GraphicsContextGLANGLE.cpp
    M Source/WebCore/platform/graphics/angle/GraphicsContextGLANGLE.h
    M Tools/TestWebKitAPI/Tests/WebCore/cocoa/TestGraphicsContextGLCocoa.mm

  Log Message:
  -----------
  Cherry-pick 272448.803 at safari-7618-branch (89ee93bd2ea4). https://bugs.webkit.org/show_bug.cgi?id=271634

    GraphicsContextGLANGLE does not validate clearBuffers value length
    https://bugs.webkit.org/show_bug.cgi?id=271634
    rdar://125222153

    Reviewed by Dan Glastonbury.

    Avoid passing too long or small arrays as GL_clearBuffer*v values.

    * Source/WebCore/platform/graphics/angle/GraphicsContextGLANGLE.cpp:
    (WebCore::GraphicsContextGLANGLE::clearBufferiv):
    (WebCore::GraphicsContextGLANGLE::clearBufferuiv):
    (WebCore::GraphicsContextGLANGLE::clearBufferfv):
    (WebCore::GraphicsContextGLANGLE::validateClearBufferv):
    * Source/WebCore/platform/graphics/angle/GraphicsContextGLANGLE.h:
    * Tools/TestWebKitAPI/Tests/WebCore/cocoa/TestGraphicsContextGLCocoa.mm:
    (TestWebKitAPI::TEST_F):

    Canonical link: https://commits.webkit.org/272448.803@safari-7618-branch

Canonical link: https://commits.webkit.org/274313.241@webkitglib/2.44


  Commit: 605bed709013ec8202b994f836c78597da139e41
      https://github.com/WebKit/WebKit/commit/605bed709013ec8202b994f836c78597da139e41
  Author: Charlie Wolfe <charliew at apple.com>
  Date:   2024-05-13 (Mon, 13 May 2024)

  Changed paths:
    A LayoutTests/ipc/dirty-region-overflow-expected.txt
    A LayoutTests/ipc/dirty-region-overflow.html
    M Source/WebCore/platform/graphics/Region.cpp
    M Source/WebCore/platform/graphics/Region.h
    M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in

  Log Message:
  -----------
  Cherry-pick 272448.816 at safari-7618-branch (63e5787d715c). https://bugs.webkit.org/show_bug.cgi?id=271741

    Add IPC validation for `WebCore::Region::Shape`
    https://bugs.webkit.org/show_bug.cgi?id=271741
    rdar://125348548

    Reviewed by Matt Woodrow.

    * LayoutTests/ipc/dirty-region-overflow-expected.txt: Added.
    * LayoutTests/ipc/dirty-region-overflow.html: Added.
    * Source/WebCore/platform/graphics/Region.cpp:
    (WebCore::Region::Shape::isValid const):
    * Source/WebCore/platform/graphics/Region.h:
    * Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:

    Canonical link: https://commits.webkit.org/272448.816@safari-7618-branch

Canonical link: https://commits.webkit.org/274313.242@webkitglib/2.44


  Commit: 9091cf27248d0185109dd39bd46134c016328db4
      https://github.com/WebKit/WebKit/commit/9091cf27248d0185109dd39bd46134c016328db4
  Author: Charlie Wolfe <charliew at apple.com>
  Date:   2024-05-13 (Mon, 13 May 2024)

  Changed paths:
    A LayoutTests/ipc/validate-media-constraint-expected.txt
    A LayoutTests/ipc/validate-media-constraint.html
    M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in

  Log Message:
  -----------
  Cherry-pick 272448.817 at safari-7618-branch (a734205bc9a9). https://bugs.webkit.org/show_bug.cgi?id=271816

    Add IPC validation for `WebCore::MediaConstraint`
    https://bugs.webkit.org/show_bug.cgi?id=271816
    rdar://125343106

    Reviewed by Pascoe.

    * LayoutTests/ipc/validate-media-constraint-expected.txt: Added.
    * LayoutTests/ipc/validate-media-constraint.html: Added.
    * Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:

    Canonical link: https://commits.webkit.org/272448.817@safari-7618-branch

Canonical link: https://commits.webkit.org/274313.243@webkitglib/2.44


  Commit: 2eb29aa574ae1a1b8a6cf4dd5990bd3a3d5d9a92
      https://github.com/WebKit/WebKit/commit/2eb29aa574ae1a1b8a6cf4dd5990bd3a3d5d9a92
  Author: Aditya Keerthi <akeerthi at apple.com>
  Date:   2024-05-13 (Mon, 13 May 2024)

  Changed paths:
    A Source/WebKit/UIProcess/Cocoa/PickerDismissalReason.h
    M Source/WebKit/UIProcess/Cocoa/WKContactPicker.h
    M Source/WebKit/UIProcess/Cocoa/WKContactPicker.mm
    M Source/WebKit/UIProcess/Cocoa/WKShareSheet.h
    M Source/WebKit/UIProcess/Cocoa/WKShareSheet.mm
    M Source/WebKit/UIProcess/ios/UIKitUtilities.h
    M Source/WebKit/UIProcess/ios/UIKitUtilities.mm
    M Source/WebKit/UIProcess/ios/WKContentView.mm
    M Source/WebKit/UIProcess/ios/WKContentViewInteraction.h
    M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
    M Source/WebKit/UIProcess/ios/WKPDFView.mm
    M Source/WebKit/UIProcess/ios/forms/WKFileUploadPanel.h
    M Source/WebKit/UIProcess/ios/forms/WKFileUploadPanel.mm
    M Source/WebKit/UIProcess/mac/WebViewImpl.mm
    M Source/WebKit/WebKit.xcodeproj/project.pbxproj

  Log Message:
  -----------
  Cherry-pick 272448.818 at safari-7618-branch (1db2f6a6a042). rdar://125046135

    REGRESSION (272448.703 at safari-7618-branch): [iOS] <input type=file> camera capture instantly dismisses
    rdar://125046135

    Reviewed by Abrar Rahman Protyasha and Wenson Hsieh.

    272448.703 at safari-7618-branch added logic to dismiss presented pickers, such as
    the file upload panel, when the `WKWebView` was removed from the hierarchy. The
    behavior is necessary to avoid scenarios where a picker can be displayed over a
    site that's unrelated to the one requesting the information.

    While that solution is correct for modal presentations, it is incorrect for
    fullscreen presentations, which remove views from the hierarchy following
    presentation. The camera view controller uses a fullscreen presentation.
    Consequently, once it gets presented, the web view is removed from the
    hierarchy, and following 272448.703 at safari-7618-branch, it is instantly
    dismissed.

    To fix, reduce the scope of the previous fix to exclude fullscreen presentations.
    In this case, there is no need to dismiss presented view controllers, as the
    web view content is already hidden.

    Note that there is no way to detect whether a view was removed from the hierarchy
    due to a fullscreen presentation. Consequently, the solution checks the status
    of various presented pickers.

    * Source/WebKit/UIProcess/Cocoa/PickerDismissalReason.h:

    Introduce `PickerDismissalReason`s to control the dimissal behavior.

    In particular, `ViewRemoved` now checks for fullscreen presentations, to avoid
    instant dismissal.

    * Source/WebKit/UIProcess/Cocoa/WKContactPicker.h:
    * Source/WebKit/UIProcess/Cocoa/WKContactPicker.mm:
    (-[WKContactPicker dismissIfNeededWithReason:]):
    * Source/WebKit/UIProcess/Cocoa/WKShareSheet.h:
    * Source/WebKit/UIProcess/Cocoa/WKShareSheet.mm:
    (-[WKShareSheet dismissIfNeededWithReason:]):
    * Source/WebKit/UIProcess/ios/UIKitUtilities.h:
    * Source/WebKit/UIProcess/ios/UIKitUtilities.mm:
    (-[UIViewController _wk_isInFullscreenPresentation]):
    * Source/WebKit/UIProcess/ios/WKContentView.mm:
    (-[WKContentView willMoveToWindow:]):
    * Source/WebKit/UIProcess/ios/WKContentViewInteraction.h:
    * Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
    (-[WKContentView cleanUpInteraction]):
    (-[WKContentView dismissFilePicker]):
    (-[WKContentView _showShareSheet:inRect:completionHandler:]):
    (-[WKContentView dismissPickersIfNeededWithReason:]):
    (-[WKContentView dismissPickers]): Deleted.
    * Source/WebKit/UIProcess/ios/WKPDFView.mm:
    (-[WKPDFView dealloc]):

    `ProcessExited` is used here, since it has the desired semantics.

    In effect, the remote process of the host view controller is exited here.

    (-[WKPDFView actionSheetAssistant:shareElementWithURL:rect:]):
    * Source/WebKit/UIProcess/ios/forms/WKFileUploadPanel.h:
    * Source/WebKit/UIProcess/ios/forms/WKFileUploadPanel.mm:
    (-[WKFileUploadPanel dismissIfNeededWithReason:]):
    * Source/WebKit/UIProcess/mac/WebViewImpl.mm:
    (WebKit::WebViewImpl::showShareSheet):
    * Source/WebKit/WebKit.xcodeproj/project.pbxproj:

    Canonical link: https://commits.webkit.org/272448.818@safari-7618-branch

Canonical link: https://commits.webkit.org/274313.244@webkitglib/2.44


  Commit: 7823ed2f90405961e0fae4c95352555265dff36c
      https://github.com/WebKit/WebKit/commit/7823ed2f90405961e0fae4c95352555265dff36c
  Author: Matthew Finkel <sysrqb at apple.com>
  Date:   2024-05-13 (Mon, 13 May 2024)

  Changed paths:
    M Source/WebKit/UIProcess/Cocoa/WebPageProxyCocoa.mm

  Log Message:
  -----------
  Cherry-pick 272448.832 at safari-7618-branch (61f821826ece). https://bugs.webkit.org/show_bug.cgi?id=271793

    [cocoa] Explicitly check the file extension for webarchives when deciding quarantine
    https://bugs.webkit.org/show_bug.cgi?id=271793
    rdar://123902597

    Reviewed by Brent Fulgham and Sihui Liu.

    Currently we only check the string suffix to see if the requested file path is
    a webarchive, but this isn't sufficient because the file extension isn't
    guaranteed to be at the end of the string. This patch parses the string as a
    file URL and then checks the file extension.

    * Source/WebKit/UIProcess/Cocoa/WebPageProxyCocoa.mm:
    (WebKit::WebPageProxy::isQuarantinedAndNotUserApproved):

    Canonical link: https://commits.webkit.org/272448.832@safari-7618-branch

Canonical link: https://commits.webkit.org/274313.245@webkitglib/2.44


  Commit: a7b995817b733dab2b83334a2b0eb15d19754bc4
      https://github.com/WebKit/WebKit/commit/a7b995817b733dab2b83334a2b0eb15d19754bc4
  Author: Pascoe <pascoe at apple.com>
  Date:   2024-05-13 (Mon, 13 May 2024)

  Changed paths:
    M Source/WebCore/Modules/webauthn/fido/U2fResponseConverter.cpp

  Log Message:
  -----------
  Cherry-pick 272448.931 at safari-7618-branch (595fc4594d77). https://bugs.webkit.org/show_bug.cgi?id=272698

    Fix issue in createFidoAttestationStatementFromU2fRegisterResponse
    https://bugs.webkit.org/show_bug.cgi?id=272698
    rdar://125024119

    Reviewed by Charlie Wolfe.

    Since the x509 length here is user supplied, the addition of the offset
    could overflow. We fix this issue by using the CheckedArithmetic header.

    Canonical link: https://commits.webkit.org/272448.931@safari-7618-branch

Canonical link: https://commits.webkit.org/274313.246@webkitglib/2.44


  Commit: 4c39e2a089ba5ebe46c3a33ba2031068f9099239
      https://github.com/WebKit/WebKit/commit/4c39e2a089ba5ebe46c3a33ba2031068f9099239
  Author: Keith Miller <keith_miller at apple.com>
  Date:   2024-05-13 (Mon, 13 May 2024)

  Changed paths:
    M Source/JavaScriptCore/assembler/MacroAssemblerARM64E.h
    M Source/JavaScriptCore/dfg/DFGOSRExitCompilerCommon.cpp
    M Source/JavaScriptCore/jit/ThunkGenerators.cpp
    M Source/JavaScriptCore/llint/LLIntThunks.cpp
    M Source/JavaScriptCore/runtime/Options.cpp
    M Source/JavaScriptCore/runtime/OptionsList.h
    M Source/WTF/wtf/PtrTag.h
    M Source/WebKit/WebProcess/WebProcess.cpp
    M Tools/Scripts/run-jsc-stress-tests

  Log Message:
  -----------
  Cherry-pick f442fbe222f3. https://bugs.webkit.org/show_bug.cgi?id=272750

    Make it harder to get a PAC signing gadget in JIT code.
    https://bugs.webkit.org/show_bug.cgi?id=272750
    rdar://125596635

    Reviewed by Yusuke Suzuki.

    Right now if an attacker can control where code is allocated they can overlap code to create a PAC bypass.
    This patch makes that harder (in the WebContent process) by only allowing pacibsp and pacizb. This means
    that during arity fixup we now tag the return PC with pacizb. This is ok because we don't use the zero
    diversifier for anything. For reifying inlined call frames during OSR exit things are a bit more complicated.
    First we have be careful to only move signed return addresses into lr then untag them there. Also, we have
    to shuffle SP to point to where it would in reified frame. This means that there is technically live data
    below our SP, which on many OSes causes problems. Talking to our kernel folks however this isn't a problem
    as long as we don't have any signal handlers or run lldb expressions in this window. We don't use signal
    handlers in the WebContent process and this patch tries to limit/document the window of JIT code where lldb
    would trash the stack.

    * Source/JavaScriptCore/assembler/MacroAssemblerARM64E.h:
    (JSC::MacroAssemblerARM64E::tagPtr):
    * Source/JavaScriptCore/dfg/DFGOSRExitCompilerCommon.cpp:
    (JSC::DFG::reifyInlinedCallFrames):
    (JSC::AssemblyHelpers::transferReturnPC):
    * Source/JavaScriptCore/jit/ThunkGenerators.cpp:
    (JSC::arityFixupGenerator):
    * Source/JavaScriptCore/llint/LLIntThunks.cpp:
    (JSC::LLInt::tagGateThunk):
    (JSC::LLInt::untagGateThunk):
    * Source/JavaScriptCore/runtime/OptionsList.h:
    * Source/WTF/wtf/PtrTag.h:
    * Source/WebKit/WebProcess/WebProcess.cpp:
    (WebKit::WebProcess::initializeProcess):
    * Tools/Scripts/run-jsc-stress-tests:

    Canonical link: https://commits.webkit.org/272448.948@safari-7618-branch

    Canonical link: https://commits.webkit.org/272448.941@safari-7618.2.12.13-branch

Canonical link: https://commits.webkit.org/274313.247@webkitglib/2.44


  Commit: d8509fbff591d5ba3f1db7dba6ae2c44e40be9e3
      https://github.com/WebKit/WebKit/commit/d8509fbff591d5ba3f1db7dba6ae2c44e40be9e3
  Author: Kimmo Kinnunen <kkinnunen at apple.com>
  Date:   2024-05-13 (Mon, 13 May 2024)

  Changed paths:
    M Source/ThirdParty/ANGLE/src/compiler/translator/msl/Name.cpp
    M Source/ThirdParty/ANGLE/src/compiler/translator/msl/TranslatorMSL.cpp
    M Source/ThirdParty/ANGLE/src/tests/gl_tests/GLSLTest.cpp

  Log Message:
  -----------
  Cherry-pick bce91c8033e3. https://bugs.webkit.org/show_bug.cgi?id=272750

    WebGL fails to compile shaders with out variables that are arrays and start with underscore
    rdar://126944294

    Reviewed by Chris Dumez.

    Integrates upstream commit:
    commit e0e91b8cbb2e096d2d009cd0d1fbe20d785f2263
    Author: Kimmo Kinnunen <kkinnunen at apple.com>
    Date:   Mon Apr 22 18:11:30 2024 -0700
    Metal: Fix rewritten out variables with underscores

    Fix compilation in case of output variables start with underscores.
    Make name emission always emit MSL name ANGLE_{name}, so that GLSL `_e`
    and `e` cannot clash. This regressed in angleproject:8558.

    Bug: b/335744344
    Change-Id: Ibae4dba4a24888acc1461582e69d48218ba11176
    Canonical link: https://commits.webkit.org/272448.959@safari-7618-branch

    Canonical link: https://commits.webkit.org/272448.946@safari-7618.2.12.11-branch

Canonical link: https://commits.webkit.org/274313.248@webkitglib/2.44


  Commit: 203ecc053827d64a27957b067b227b493f4ac9f9
      https://github.com/WebKit/WebKit/commit/203ecc053827d64a27957b067b227b493f4ac9f9
  Author: David Degazio <d_degazio at apple.com>
  Date:   2024-05-13 (Mon, 13 May 2024)

  Changed paths:
    M Source/JavaScriptCore/bytecode/CodeBlock.cpp
    M Source/JavaScriptCore/bytecode/MetadataTable.cpp
    M Source/JavaScriptCore/bytecode/MetadataTable.h
    M Source/JavaScriptCore/bytecode/UnlinkedMetadataTable.h

  Log Message:
  -----------
  Cherry-pick 4cac7925aca4. https://bugs.webkit.org/show_bug.cgi?id=272787

    [JSC] Mitigate null UnlinkedMetadataTable pointer in CodeBlock destructor
    https://bugs.webkit.org/show_bug.cgi?id=272787
    rdar://121747906

    Reviewed by Yusuke Suzuki.

    Attempts to fix a rare bug where the UnlinkedMetadataTable pointer accessed
    in the CodeBlock destructor can become null. We think this may be due to a
    series of thread-unsafe reference count operations that might allow the
    destructor to happen twice, perhaps simultaneously on two threads. This
    patch attempts to mitigate this by:

     1. Making UnlinkedMetadataTable and MetadataTable thread-safe refcounted.

     2. Checking for the presence of a null UnlinkedMetadataTable pointer in the
        appropriate functions, and attempting to handle it nonfatally. This means
        we skip updating the didOptimize state in the CodeBlock destructor, and
        that we intentionally leak MetadataTables if they have this null pointer.

    * Source/JavaScriptCore/bytecode/CodeBlock.cpp:
    (JSC::CodeBlock::~CodeBlock):
    * Source/JavaScriptCore/bytecode/MetadataTable.cpp:
    (JSC::MetadataTable::destroy):
    (JSC::MetadataTable::sizeInBytesForGC):
    * Source/JavaScriptCore/bytecode/MetadataTable.h:
    (JSC::MetadataTable::forEachValueProfile):
    (JSC::MetadataTable::valueProfileForOffset):
    (JSC::MetadataTable::deref):
    (JSC::MetadataTable::unlinkedMetadata const):
    (JSC::MetadataTable::totalSize const):
    * Source/JavaScriptCore/bytecode/UnlinkedMetadataTable.h:

    Canonical link: https://commits.webkit.org/272448.937@safari-7618-branch

Canonical link: https://commits.webkit.org/274313.249@webkitglib/2.44


  Commit: 5a9234b48235fe47163c5fc603e4b786956f1d9b
      https://github.com/WebKit/WebKit/commit/5a9234b48235fe47163c5fc603e4b786956f1d9b
  Author: Kimmo Kinnunen <kkinnunen at apple.com>
  Date:   2024-05-13 (Mon, 13 May 2024)

  Changed paths:
    M Source/ThirdParty/ANGLE/src/tests/gl_tests/GLSLTest.cpp

  Log Message:
  -----------
  Cherry-pick bce91c8033e3. <bug>

    WebGL fails to compile shaders with out variables that are arrays and start with underscore
    rdar://126944294

    Reviewed by Chris Dumez.

    Integrates upstream commit:
    commit e0e91b8cbb2e096d2d009cd0d1fbe20d785f2263
    Author: Kimmo Kinnunen <kkinnunen at apple.com>
    Date:   Mon Apr 22 18:11:30 2024 -0700
    Metal: Fix rewritten out variables with underscores

    Fix compilation in case of output variables start with underscores.
    Make name emission always emit MSL name ANGLE_{name}, so that GLSL `_e`
    and `e` cannot clash. This regressed in angleproject:8558.

    Bug: b/335744344
    Change-Id: Ibae4dba4a24888acc1461582e69d48218ba11176
    Canonical link: https://commits.webkit.org/272448.959@safari-7618-branch

    Canonical link: https://commits.webkit.org/272448.958@safari-7618.2.12.10-branch

Canonical link: https://commits.webkit.org/274313.250@webkitglib/2.44


  Commit: 8f9e9493af4b730830a2988847ec1a61e7d036bd
      https://github.com/WebKit/WebKit/commit/8f9e9493af4b730830a2988847ec1a61e7d036bd
  Author: Pascoe <pascoe at apple.com>
  Date:   2024-05-13 (Mon, 13 May 2024)

  Changed paths:
    M Source/WebKit/UIProcess/WebPageProxy.cpp
    M Tools/TestWebKitAPI/Tests/WebKitCocoa/Download.mm

  Log Message:
  -----------
  Cherry-pick 272448.740 at safari-7618-branch (c369f5018e91). https://bugs.webkit.org/show_bug.cgi?id=271003

    PDFs should be downloaded in lockdown mode
    https://bugs.webkit.org/show_bug.cgi?id=271003
    rdar://124636755

    Reviewed by Chris Dumez.

    This functionality was first introduced in https://bugs.webkit.org/show_bug.cgi?id=237245, but
    was disabled for macOS in https://bugs.webkit.org/show_bug.cgi?id=241741. This patch is to re-enable it.

    This functionality should be covered by WKDownload.LockdownModePDF. Which is also fixed in this change
    such that it fails whenever the conditional doesn't exist.

    * Source/WebKit/UIProcess/WebPageProxy.cpp:
    (WebKit::WebPageProxy::decidePolicyForResponseShared):
    * Tools/TestWebKitAPI/Tests/WebKitCocoa/Download.mm:

    Canonical link: https://commits.webkit.org/272448.740@safari-7618-branch

Canonical link: https://commits.webkit.org/274313.251@webkitglib/2.44


  Commit: f736325e66bfa8e85f85387299448476f3e1fb3c
      https://github.com/WebKit/WebKit/commit/f736325e66bfa8e85f85387299448476f3e1fb3c
  Author: Adrian Perez de Castro <aperez at igalia.com>
  Date:   2024-05-14 (Tue, 14 May 2024)

  Changed paths:
    M Source/WebKit/wpe/NEWS
    M Source/cmake/OptionsWPE.cmake

  Log Message:
  -----------
  Unreviewed. Update OptionsWPE.cmake and NEWS for the 2.44.2 release

* Source/WebKit/wpe/NEWS: Add release notes for 2.44.2.
* Source/cmake/OptionsWPE.cmake: Bump version numbers.

Canonical link: https://commits.webkit.org/274313.252@webkitglib/2.44


Compare: https://github.com/WebKit/WebKit/compare/f6aae85eee6b...f736325e66bf

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


More information about the webkit-changes mailing list