[webkit-changes] [WebKit/WebKit] 53ec7b: Cherry-pick 280938.177 at safari-7619-branch (417d191...

Mon Oct 28 13:49:56 PDT 2024

  Branch: refs/heads/webkitglib/2.46
  Home:   https://github.com/WebKit/WebKit
  Commit: 53ec7b74910013293ba23611294d84a199e72d05
      https://github.com/WebKit/WebKit/commit/53ec7b74910013293ba23611294d84a199e72d05
  Author: Chris Dumez <cdumez at apple.com>
  Date:   2024-10-25 (Fri, 25 Oct 2024)

  Changed paths:
    M Source/WTF/wtf/text/StringImpl.h

  Log Message:
  -----------
  Cherry-pick 280938.177 at safari-7619-branch (417d191bc537). https://bugs.webkit.org/show_bug.cgi?id=277596

Guard against constructing Strings with a length greater than MaxLength from a StringBuffer.
https://bugs.webkit.org/show_bug.cgi?id=277596
rdar://132984553

Reviewed by Darin Adler.

* Source/WTF/wtf/text/StringImpl.cpp:
(WTF::StringImpl::adopt):

Canonical link: https://commits.webkit.org/282416.236@webkitglib/2.46

  Commit: f0042e4c037bb7d913e8d80c7cb497d0c668c298
      https://github.com/WebKit/WebKit/commit/f0042e4c037bb7d913e8d80c7cb497d0c668c298
  Author: Chris Dumez <cdumez at apple.com>
  Date:   2024-10-25 (Fri, 25 Oct 2024)

  Changed paths:
    M Source/WebCore/Modules/webaudio/AudioWorkletProcessor.cpp

  Log Message:
  -----------
  Cherry-pick 280938.195 at safari-7619-branch (1bac059fd67b). https://bugs.webkit.org/show_bug.cgi?id=277639

[WebAudio] Potential out of bounds read in copyDataFromBusesToJSArray()
https://bugs.webkit.org/show_bug.cgi?id=277639
rdar://132984512

Reviewed by Yusuke Suzuki.

The AudioWorkletProcessor constructs a JSArray of JSFloat32Arrays that is frozen.
Then it passes the JSArray to arbitrary JavaScript so it can modify the data in
the JSFloat32Arrays. Finally, we memcpy the data from the JSFloat32Arrays to our
audio buses. Because the array is frozen, we expected that the arrays couldn't
change. However, one could set a shared array buffer at a particular index by
modifying Array.prototype. This would render our memcpy logic unsafe since the
size of the array could change on the main thread while we memcpy on the audio
worklet thread.

To address the issue, I now call `getDirectIndex()` instead of `getIndex()` to
ignore values set on the Array prototype and only consider the ones I populated
the array with. I'm also adding validation to make sure the the JSFloat32Arrays
are not shared since I'm constructing unshared ones.

* Source/WebCore/Modules/webaudio/AudioWorkletProcessor.cpp:
(WebCore::getArrayAtIndex):
(WebCore::copyDataFromJSArrayToBuses):
(WebCore::copyDataFromBusesToJSArray):
(WebCore::zeroJSArray):

Canonical link: https://commits.webkit.org/282416.237@webkitglib/2.46

  Commit: 92355808154e80c545422a23205a1d6a043bc540
      https://github.com/WebKit/WebKit/commit/92355808154e80c545422a23205a1d6a043bc540
  Author: Youenn Fablet <youenn at apple.com>
  Date:   2024-10-25 (Fri, 25 Oct 2024)

  Changed paths:
    A LayoutTests/fetch/fetch-empty-blob-crash-expected.txt
    A LayoutTests/fetch/fetch-empty-blob-crash.html
    M Source/WebCore/Modules/fetch/FormDataConsumer.cpp

  Log Message:
  -----------
  Cherry-pick 280938.254 at safari-7619-branch (76167250cbca). rdar://134411748

Use-after-free in FormDataConsumer::consume
rdar://134411748

Reviewed by Chris Dumez.

FormDataConsumer is notifying of end of load with an empty span.
Form datas can be using blobs as element, the blobs having zero data.
In this case, FormDataConsumer will send an empty span for the zero data and then an empty span for the end of load.
This confuses FetchBodyConsumer which then triggers a UAF.

To prevent this, we update FormDataConsumer to execute the callback when receiving data only if data is not empty.
An empty span is solely used to convey the end of the load.

* LayoutTests/fetch/fetch-empty-blob-crash-expected.txt: Added.
* LayoutTests/fetch/fetch-empty-blob-crash.html: Added.
* Source/WebCore/Modules/fetch/FormDataConsumer.cpp:
(WebCore::FormDataConsumer::consume):

Canonical link: https://commits.webkit.org/282416.238@webkitglib/2.46

  Commit: 47785848d04adeadf2ccf69777fb363598f78870
      https://github.com/WebKit/WebKit/commit/47785848d04adeadf2ccf69777fb363598f78870
  Author: Rupin Mittal <rupin at apple.com>
  Date:   2024-10-25 (Fri, 25 Oct 2024)

  Changed paths:
    M Source/WebKit/NetworkProcess/storage/CacheStorageCache.cpp
    M Source/WebKit/NetworkProcess/storage/CacheStorageDiskStore.cpp
    M Source/WebKit/NetworkProcess/storage/CacheStorageDiskStore.h
    M Source/WebKit/NetworkProcess/storage/NetworkStorageManager.cpp
    M Source/WebKit/NetworkProcess/storage/NetworkStorageManager.h

  Log Message:
  -----------
  Cherry-pick 280938.255 at safari-7619-branch (8150063459d1). https://bugs.webkit.org/show_bug.cgi?id=278357

CrossThreadRecord allows you to control uint64_t responseBodySize
rdar://124960263
https://bugs.webkit.org/show_bug.cgi?id=278357

Reviewed by Sihui Liu.

There are two problems in this bug that we fix:
(1) In the function CacheStorageCache::putRecords, uint64_t responseBodySize
    is added and subtracted from int64_t spaceRequested. We fix this mismatch
    by changing the type of spaceRequested to CheckedUint64 and then checking
    for overflow.

    Some of the records being added already exist in the cache. We keep track
    of whether the new version of that record needs more or less space than
    the existing record and request additional space only if needed.

(2) When the client sends the records over IPC, they also send the record's
    size--and this size is used to calculate and then allocate space. But
    because the client is sending the size, it's possible an attacker sends
    a false value for the size. This size is calculated on the client side
    in CacheStorageConnection::computeRecordBodySize. It does not return the
    exact size of the body, but rather a size that has a random padding added.
    We do this for security concerns: https://github.com/whatwg/storage/issues/31.
    Since this size is random, we cannot check the size by re-calculating it.
    What we can do is ensure that the size is greater than the actual size
    because a smaller size would be a clear indication that the size has been
    tampered with. So we add a check to at least ensure that the size is greater
    since all the randomly padded sizes are indeed greater than the true sizes.

    This check is done in NetworkStorageManager::cacheStoragePutRecords using
    MESSAGE_CHECK so the WebContent process can be killed if the size is invalid,
    indicating that the process is compromised.

* Source/WebKit/NetworkProcess/storage/CacheStorageCache.cpp:
(WebKit::CacheStorageCache::putRecords):
* Source/WebKit/NetworkProcess/storage/CacheStorageDiskStore.cpp:
(WebKit::encodeRecordBody):
(WebKit::CacheStorageDiskStore::computeRealBodySizeForStorage):
(WebKit::CacheStorageDiskStore::writeRecords):
* Source/WebKit/NetworkProcess/storage/CacheStorageDiskStore.h:
* Source/WebKit/NetworkProcess/storage/NetworkStorageManager.cpp:
(WebKit::NetworkStorageManager::cacheStoragePutRecords):
* Source/WebKit/NetworkProcess/storage/NetworkStorageManager.h:

Canonical link: https://commits.webkit.org/282416.239@webkitglib/2.46

  Commit: 7db0f7c4c8dbb1cd72d0bf50bb357604d8f00ed4
      https://github.com/WebKit/WebKit/commit/7db0f7c4c8dbb1cd72d0bf50bb357604d8f00ed4
  Author: Yijia Huang <yijia_huang at apple.com>
  Date:   2024-10-25 (Fri, 25 Oct 2024)

  Changed paths:
    A JSTests/stress/clobber-new-index-reg-in-enumerator-next-update-index-and-mode.js
    M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp
    M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.h

  Log Message:
  -----------
  Cherry-pick 280938.256 at safari-7619-branch (2936053b96d6). https://bugs.webkit.org/show_bug.cgi?id=278427

[JSC] Should preserve the index in compileHasIndexedProperty if needed
https://bugs.webkit.org/show_bug.cgi?id=278427
rdar://129328633

Reviewed by Keith Miller.

The EnumeratorNextUpdateIndexAndMode node is expected to return two results.
In the fast path for case IndexedMode, the index value should be returned as
one of the results. However, the slow path of compileHasIndexedProperty
triggers a operation call with a single result. So, compileHasIndexedProperty
should preserve the index in compileHasIndexedProperty if needed.

* Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp:
* Source/JavaScriptCore/dfg/DFGSpeculativeJIT.h:

Canonical link: https://commits.webkit.org/282416.240@webkitglib/2.46

  Commit: 74a083bec410a7620e86a70d5301fa8549c825bb
      https://github.com/WebKit/WebKit/commit/74a083bec410a7620e86a70d5301fa8549c825bb
  Author: Rupin Mittal <rupin at apple.com>
  Date:   2024-10-25 (Fri, 25 Oct 2024)

  Changed paths:
    M Source/WebCore/platform/sql/SQLiteStatement.h
    M Source/WebCore/platform/sql/SQLiteStatementAutoResetScope.cpp
    M Source/WebCore/platform/sql/SQLiteStatementAutoResetScope.h
    M Source/WebKit/NetworkProcess/storage/SQLiteStorageArea.cpp

  Log Message:
  -----------
  Cherry-pick 280938.269 at safari-7619-branch (d76a8be1ba40). https://bugs.webkit.org/show_bug.cgi?id=278538

Ensure SQLiteStorageArea does not use SQLiteStatement after it's been freed
https://bugs.webkit.org/show_bug.cgi?id=278538
rdar://127866416

Reviewed by Chris Dumez, Geoffrey Garen, and Sihui Liu.

SQLiteStorageArea::getItemFromDatabase() holds a SQLiteStatementAutoResetScope
statement variable. This goes out of scope at the end of getItemFromDatabase()
and so it's destructor is called. There is a crash occurring here. It turns out
that SQLiteStatementAutoResetScope holds a raw pointer to a SQLiteStatement.
A series of function calls: getItemFromDatabase() -> handleDatabaseErrorIfNeeded()
-> close() results in this SQLiteStatement object being destroyed
(SQLiteStorageArea holds a unique pointer to this SQLiteStatement object which is
destroyed in close()). After this destruction, the SQLiteStatementAutoResetScope
statement variable goes out of scope and it's destructor attempts to access the
raw pointer to the now-destroyed SQLiteStatement object. This use-after-free
causes the crash.

We fix this problem by using a block-scope to ensure the SQLiteStatementAutoResetScope
statement variable is destroyed before handleDatabaseErrorIfNeeded() is called. Although
the crash was only in getItemFromDatabase(), there are other functions in SQLiteStorageArea
that follow this same pattern and could potentially have a use-after-free. We make this
block-scope change there as well. Additionally, we change the SQLiteStatement raw pointer
in SQLiteStatementAutoResetScope to a CheckedPtr.

We use a block-scope rather than declare a new function SQLiteStatementAutoResetScope that
could call reset on the SQLiteStatement object because we want the object to live and be
reset in sync with the scope's lifetime.

* Source/WebCore/platform/sql/SQLiteStatement.h:
* Source/WebCore/platform/sql/SQLiteStatementAutoResetScope.cpp:
(WebCore::SQLiteStatementAutoResetScope::operator=): Deleted.
* Source/WebCore/platform/sql/SQLiteStatementAutoResetScope.h:
(WebCore::SQLiteStatementAutoResetScope::operator bool const):
(WebCore::SQLiteStatementAutoResetScope::get):
(WebCore::SQLiteStatementAutoResetScope::operator->):
* Source/WebKit/NetworkProcess/storage/SQLiteStorageArea.cpp:
(WebKit::SQLiteStorageArea::getItemFromDatabase):
(WebKit::SQLiteStorageArea::allItems):
(WebKit::SQLiteStorageArea::setItem):
(WebKit::SQLiteStorageArea::removeItem):
(WebKit::SQLiteStorageArea::clear):

Canonical link: https://commits.webkit.org/282416.241@webkitglib/2.46

  Commit: 854410afa00da8e2ae2110a3b0af66173485b3cb
      https://github.com/WebKit/WebKit/commit/854410afa00da8e2ae2110a3b0af66173485b3cb
  Author: Nitin Mahendru <nitinmahendru at apple.com>
  Date:   2024-10-25 (Fri, 25 Oct 2024)

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

  Log Message:
  -----------
  Cherry-pick 280938.270 at safari-7619-branch (e2a2faccf8a5). https://bugs.webkit.org/show_bug.cgi?id=278605

Correctly terminate deserialization in CloneDeserializer::readRTCCertificate
https://bugs.webkit.org/show_bug.cgi?id=278605
rdar://134026541

Reviewed by Chris Dumez.

Calling fail() as added in this change will terminate the deserialization process
instead of further trying to parse the data that is left. This can lead to arbitrary
data being forced into the deserializer.

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

Canonical link: https://commits.webkit.org/282416.242@webkitglib/2.46

  Commit: 00fb9c2ce15740f4b1519f9159b2768fd780f10b
      https://github.com/WebKit/WebKit/commit/00fb9c2ce15740f4b1519f9159b2768fd780f10b
  Author: Nitin Mahendru <nitinmahendru at apple.com>
  Date:   2024-10-25 (Fri, 25 Oct 2024)

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

  Log Message:
  -----------
  Cherry-pick 280938.275 at safari-7619-branch (b5e222d47875). https://bugs.webkit.org/show_bug.cgi?id=278642

Correctly terminate serialization in case wrapCryptoKey fails
https://bugs.webkit.org/show_bug.cgi?id=278642
rdar://134026604

Reviewed by Chris Dumez.

Stop serialization with an error when wrapCryptoKey fails.

* Source/WebCore/bindings/js/SerializedScriptValue.cpp:
(WebCore::CloneSerializer::dumpIfTerminal):

Canonical link: https://commits.webkit.org/282416.243@webkitglib/2.46

  Commit: 0b71f474e0a80ed5d2b47242bfc75ae8078c3f2e
      https://github.com/WebKit/WebKit/commit/0b71f474e0a80ed5d2b47242bfc75ae8078c3f2e
  Author: Basuke Suzuki <basuke.suzuki at sony.com>
  Date:   2024-10-25 (Fri, 25 Oct 2024)

  Changed paths:
    A LayoutTests/js/structuredClone/structured-clone-of-ResizableSharedArrayBuffer-expected.txt
    A LayoutTests/js/structuredClone/structured-clone-of-ResizableSharedArrayBuffer.html
    M Source/WebCore/bindings/js/SerializedScriptValue.cpp

  Log Message:
  -----------
  Cherry-pick 280938.277 at safari-7619-branch (22e102ecb215). https://bugs.webkit.org/show_bug.cgi?id=278657

Race condition in CloneSerializer::dumpIfTerminal allows for injecting arbitrary deserialization data
https://bugs.webkit.org/show_bug.cgi?id=278657
rdar://132388209

Reviewed by Chris Dumez and Geoffrey Garen.

Fix the exploit by using consistent byteLength fetched from the array buffer.

This is part 1 of security fix. In part 2, we'll introduce a new write method for std::span and consistently use that in all cases of std::span<const uint8_t>. This requires for changing the byte format and need more code.

* LayoutTests/js/structuredClone/structured-clone-of-ResizableSharedArrayBuffer-expected.txt: Added.
* LayoutTests/js/structuredClone/structured-clone-of-ResizableSharedArrayBuffer.html: Added.
* Source/WebCore/bindings/js/SerializedScriptValue.cpp:
(WebCore::CloneSerializer::dumpIfTerminal):
(WebCore::CloneSerializer::writeResizableArrayBuffer):

Canonical link: https://commits.webkit.org/282416.244@webkitglib/2.46

  Commit: e554e17e7cc4b684ac6c84f931c4e5db6596f01c
      https://github.com/WebKit/WebKit/commit/e554e17e7cc4b684ac6c84f931c4e5db6596f01c
  Author: Nitin Mahendru <nitinmahendru at apple.com>
  Date:   2024-10-25 (Fri, 25 Oct 2024)

  Changed paths:
    A LayoutTests/http/tests/security/contentSecurityPolicy/connect-src-ping-allowed-expected.txt
    A LayoutTests/http/tests/security/contentSecurityPolicy/connect-src-ping-allowed.html
    A LayoutTests/http/tests/security/contentSecurityPolicy/connect-src-ping-blocked-expected.txt
    A LayoutTests/http/tests/security/contentSecurityPolicy/connect-src-ping-blocked.html
    A LayoutTests/http/tests/security/contentSecurityPolicy/resources/sample.html
    M Source/WebCore/loader/PingLoader.cpp

  Log Message:
  -----------
  Cherry-pick 280938.286 at safari-7619-branch (03fe2d2f0fa8). https://bugs.webkit.org/show_bug.cgi?id=278765

Honor the connect-src value for <a ping="">
https://bugs.webkit.org/show_bug.cgi?id=278765
rdar://131054895

Reviewed by Chris Dumez.

At the moment, even though connect-src is set to one origin, cross origin pings
originating from the ping attribute of HTMLAnchorElement are not blocked. They should be.
This adds that check using CSP and adds a +/- tests to validate the same.

* LayoutTests/http/tests/security/contentSecurityPolicy/connect-src-ping-allowed-expected.txt: Added.
* LayoutTests/http/tests/security/contentSecurityPolicy/connect-src-ping-allowed.html: Added.
* LayoutTests/http/tests/security/contentSecurityPolicy/connect-src-ping-blocked-expected.txt: Added.
* LayoutTests/http/tests/security/contentSecurityPolicy/connect-src-ping-blocked.html: Added.
* LayoutTests/http/tests/security/contentSecurityPolicy/resources/sample.html: Added.
* Source/WebCore/loader/PingLoader.cpp:
(WebCore::PingLoader::sendPing):

Canonical link: https://commits.webkit.org/282416.245@webkitglib/2.46

  Commit: a2a190aaaae92c8fa91907a3aad6d933d3bd9fc1
      https://github.com/WebKit/WebKit/commit/a2a190aaaae92c8fa91907a3aad6d933d3bd9fc1
  Author: Rupin Mittal <rupin at apple.com>
  Date:   2024-10-25 (Fri, 25 Oct 2024)

  Changed paths:
    M LayoutTests/inspector/indexeddb/clearObjectStore-expected.txt
    M LayoutTests/inspector/indexeddb/clearObjectStore.html
    M LayoutTests/inspector/indexeddb/requestData-expected.txt
    M LayoutTests/inspector/indexeddb/requestData.html
    M LayoutTests/inspector/indexeddb/requestDatabase.html
    M Source/WebCore/Headers.cmake
    A Source/WebCore/Modules/indexeddb/IDBObjectStoreIdentifier.h
    M Source/WebCore/Modules/indexeddb/IDBRequest.cpp
    M Source/WebCore/Modules/indexeddb/IDBRequest.h
    M Source/WebCore/Modules/indexeddb/IDBTransaction.cpp
    M Source/WebCore/Modules/indexeddb/IDBTransaction.h
    M Source/WebCore/Modules/indexeddb/client/IDBConnectionProxy.cpp
    M Source/WebCore/Modules/indexeddb/client/IDBConnectionProxy.h
    M Source/WebCore/Modules/indexeddb/client/IDBConnectionToServer.cpp
    M Source/WebCore/Modules/indexeddb/client/IDBConnectionToServer.h
    M Source/WebCore/Modules/indexeddb/client/IDBConnectionToServerDelegate.h
    M Source/WebCore/Modules/indexeddb/client/TransactionOperation.h
    M Source/WebCore/Modules/indexeddb/server/IDBBackingStore.h
    M Source/WebCore/Modules/indexeddb/server/IDBServer.cpp
    M Source/WebCore/Modules/indexeddb/server/IDBServer.h
    M Source/WebCore/Modules/indexeddb/server/MemoryIDBBackingStore.cpp
    M Source/WebCore/Modules/indexeddb/server/MemoryIDBBackingStore.h
    M Source/WebCore/Modules/indexeddb/server/SQLiteIDBBackingStore.cpp
    M Source/WebCore/Modules/indexeddb/server/SQLiteIDBBackingStore.h
    M Source/WebCore/Modules/indexeddb/server/SQLiteIDBCursor.cpp
    M Source/WebCore/Modules/indexeddb/server/SQLiteIDBCursor.h
    M Source/WebCore/Modules/indexeddb/server/SQLiteIDBTransaction.cpp
    M Source/WebCore/Modules/indexeddb/server/SQLiteIDBTransaction.h
    M Source/WebCore/Modules/indexeddb/server/UniqueIDBDatabase.cpp
    M Source/WebCore/Modules/indexeddb/server/UniqueIDBDatabase.h
    M Source/WebCore/Modules/indexeddb/server/UniqueIDBDatabaseTransaction.cpp
    M Source/WebCore/Modules/indexeddb/server/UniqueIDBDatabaseTransaction.h
    M Source/WebCore/Modules/indexeddb/shared/IDBCursorInfo.cpp
    M Source/WebCore/Modules/indexeddb/shared/IDBCursorInfo.h
    M Source/WebCore/Modules/indexeddb/shared/IDBDatabaseInfo.cpp
    M Source/WebCore/Modules/indexeddb/shared/IDBDatabaseInfo.h
    M Source/WebCore/Modules/indexeddb/shared/IDBGetAllRecordsData.h
    M Source/WebCore/Modules/indexeddb/shared/IDBIndexInfo.cpp
    M Source/WebCore/Modules/indexeddb/shared/IDBIndexInfo.h
    M Source/WebCore/Modules/indexeddb/shared/IDBObjectStoreInfo.cpp
    M Source/WebCore/Modules/indexeddb/shared/IDBObjectStoreInfo.h
    M Source/WebCore/Modules/indexeddb/shared/IDBRequestData.cpp
    M Source/WebCore/Modules/indexeddb/shared/IDBRequestData.h
    M Source/WebCore/WebCore.xcodeproj/project.pbxproj
    M Source/WebCore/loader/EmptyClients.cpp
    M Source/WebKit/NetworkProcess/storage/NetworkStorageManager.cpp
    M Source/WebKit/NetworkProcess/storage/NetworkStorageManager.h
    M Source/WebKit/NetworkProcess/storage/NetworkStorageManager.messages.in
    M Source/WebKit/Scripts/webkit/messages.py
    M Source/WebKit/Scripts/webkit/tests/MessageArgumentDescriptions.cpp
    M Source/WebKit/Shared/WTFArgumentCoders.serialization.in
    M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
    M Source/WebKit/WebProcess/Databases/IndexedDB/WebIDBConnectionToServer.cpp
    M Source/WebKit/WebProcess/Databases/IndexedDB/WebIDBConnectionToServer.h
    M Source/WebKitLegacy/Storage/InProcessIDBServer.cpp
    M Source/WebKitLegacy/Storage/InProcessIDBServer.h

  Log Message:
  -----------
  Cherry-pick 280938.304 at safari-7619-branch (f27c5d5f0368). https://bugs.webkit.org/show_bug.cgi?id=278602

Use ObjectIdentifier for IDBObjectStore IDs instead of uint64_t
https://bugs.webkit.org/show_bug.cgi?id=278602
rdar://134411784

Reviewed by Sihui Liu.

As the radar (rdar://134411784) explains:

There are multiple NetworkStorageManager functions that recieve a
uint64_t objectStoreIdentifier as an ID for IDBObjectStore objects.
This objectStoreIdentifier is fully controlled by the WebContent
process which sets it and sends it to the Network process over IPC.
Some of these functions end up using this objectStoreIdentifier as a
key for a HashMap which can lead to memory corruption as shown in
rdar://130158277.

This patch fixes this problem by using a new type called
IDBObjectStoreIdentifier instead of uint64_t for the IDs of
IDBObjectStore objects. The identifier is held by IDBObjectStoreInfo.

Initially, this change caused three tests (requestData.html,
requestDatabase.html, and clearObjectStore.html) to fail. It turns
out that these tests were retrieving ObjectStores using
IDBDatabaseInfo::ObjectStoreNames() and relying on the order of the
ObjectStores being the same every time. These ObjectStores are stored
in a HashMap and this function uses a for-each loop to iterate through
the HashMap and return the ObjectStore names. But HashMaps are not
ordered and so iteration through them does not occur in any guaranteed
order. Yet these tests were relying on this iteration occuring in the
same order each time. When the identifiers changed from uint64_t to
ObjectIdentifiers, the hashes for the ObjectStores changed, and
so the ObjectStores were returned in a different order--causing
the tests to fail. Expecting iteration through a HashMap to occur
in the same order each time is incorrect, so we fix this problem
by sorting the ObjectStores by name after they are returned. This
ensures the order is always what we expect and so the tests pass.

To clearly point out the issue in the code, we can look at
requestData.html. The test calls database.objectStores. This 'database'
is a DatabaseWithObjectStores object, which is a JSON object. We create
this object and give it an objectStores field in the execute() function
in DatabaseLoader in InspectorIndexedDBAgent.cpp. Here, we see that the
objectStores field is set using databaseInfo.objectStoreNames(). This is
where the HashMap is iterated. The test expects the iteration to return
the stores [emptyObjectStore, reviewersObjectStore, statsObjectStore] in
that specific order each time. But there is no guarantee that this will be
the iteration order. We fix this by getting the ObjectStores, sorting them,
and then using them so we can be sure that they're in this order. This code
logic is the same in requestDatabase.html and clearObjectStore.html as well.

* LayoutTests/inspector/indexeddb/clearObjectStore-expected.txt:
* LayoutTests/inspector/indexeddb/clearObjectStore.html:
* LayoutTests/inspector/indexeddb/requestData-expected.txt:
* LayoutTests/inspector/indexeddb/requestData.html:
* LayoutTests/inspector/indexeddb/requestDatabase.html:
* Source/WebCore/Headers.cmake:
* Source/WebCore/Modules/indexeddb/IDBObjectStoreIdentifier.h: Copied from Source/WebCore/Modules/indexeddb/shared/IDBGetAllRecordsData.h.
* Source/WebCore/Modules/indexeddb/IDBRequest.cpp:
(WebCore::IDBRequest::sourceObjectStoreIdentifier const):
* Source/WebCore/Modules/indexeddb/IDBRequest.h:
* Source/WebCore/Modules/indexeddb/IDBTransaction.cpp:
(WebCore::IDBTransaction::abortInternal):
(WebCore::IDBTransaction::renameObjectStore):
(WebCore::IDBTransaction::renameObjectStoreOnServer):
(WebCore::IDBTransaction::renameIndex):
(WebCore::IDBTransaction::renameIndexOnServer):
(WebCore::IDBTransaction::requestClearObjectStore):
(WebCore::IDBTransaction::clearObjectStoreOnServer):
(WebCore::IDBTransaction::deleteIndex):
(WebCore::IDBTransaction::deleteIndexOnServer):
* Source/WebCore/Modules/indexeddb/IDBTransaction.h:
* Source/WebCore/Modules/indexeddb/client/IDBConnectionProxy.cpp:
(WebCore::IDBClient::IDBConnectionProxy::renameObjectStore):
(WebCore::IDBClient::IDBConnectionProxy::renameIndex):
(WebCore::IDBClient::IDBConnectionProxy::clearObjectStore):
(WebCore::IDBClient::IDBConnectionProxy::deleteIndex):
* Source/WebCore/Modules/indexeddb/client/IDBConnectionProxy.h:
* Source/WebCore/Modules/indexeddb/client/IDBConnectionToServer.cpp:
(WebCore::IDBClient::IDBConnectionToServer::renameObjectStore):
(WebCore::IDBClient::IDBConnectionToServer::clearObjectStore):
(WebCore::IDBClient::IDBConnectionToServer::deleteIndex):
(WebCore::IDBClient::IDBConnectionToServer::renameIndex):
* Source/WebCore/Modules/indexeddb/client/IDBConnectionToServer.h:
* Source/WebCore/Modules/indexeddb/client/IDBConnectionToServerDelegate.h:
* Source/WebCore/Modules/indexeddb/client/TransactionOperation.h:
(WebCore::IDBClient::TransactionOperation::objectStoreIdentifier const):
* Source/WebCore/Modules/indexeddb/server/IDBBackingStore.h:
* Source/WebCore/Modules/indexeddb/server/IDBServer.cpp:
(WebCore::IDBServer::IDBServer::renameObjectStore):
(WebCore::IDBServer::IDBServer::clearObjectStore):
(WebCore::IDBServer::IDBServer::deleteIndex):
(WebCore::IDBServer::IDBServer::renameIndex):
* Source/WebCore/Modules/indexeddb/server/IDBServer.h:
* Source/WebCore/Modules/indexeddb/server/MemoryIDBBackingStore.cpp:
(WebCore::IDBServer::MemoryIDBBackingStore::createObjectStore):
(WebCore::IDBServer::MemoryIDBBackingStore::deleteObjectStore):
(WebCore::IDBServer::MemoryIDBBackingStore::renameObjectStore):
(WebCore::IDBServer::MemoryIDBBackingStore::clearObjectStore):
(WebCore::IDBServer::MemoryIDBBackingStore::deleteIndex):
(WebCore::IDBServer::MemoryIDBBackingStore::renameIndex):
(WebCore::IDBServer::MemoryIDBBackingStore::keyExistsInObjectStore):
(WebCore::IDBServer::MemoryIDBBackingStore::deleteRange):
(WebCore::IDBServer::MemoryIDBBackingStore::getRecord):
(WebCore::IDBServer::MemoryIDBBackingStore::getIndexRecord):
(WebCore::IDBServer::MemoryIDBBackingStore::getCount):
(WebCore::IDBServer::MemoryIDBBackingStore::generateKeyNumber):
(WebCore::IDBServer::MemoryIDBBackingStore::revertGeneratedKeyNumber):
(WebCore::IDBServer::MemoryIDBBackingStore::maybeUpdateKeyGeneratorNumber):
(WebCore::IDBServer::MemoryIDBBackingStore::openCursor):
(WebCore::IDBServer::MemoryIDBBackingStore::takeObjectStoreByIdentifier):
(WebCore::IDBServer::MemoryIDBBackingStore::infoForObjectStore):
* Source/WebCore/Modules/indexeddb/server/MemoryIDBBackingStore.h:
* Source/WebCore/Modules/indexeddb/server/SQLiteIDBBackingStore.cpp:
(WebCore::IDBServer::SQLiteIDBBackingStore::migrateIndexInfoTableForIDUpdate):
(WebCore::IDBServer::SQLiteIDBBackingStore::migrateIndexRecordsTableForIDUpdate):
(WebCore::IDBServer::SQLiteIDBBackingStore::addExistingIndex):
(WebCore::IDBServer::SQLiteIDBBackingStore::extractExistingDatabaseInfo):
(WebCore::IDBServer::SQLiteIDBBackingStore::createObjectStore):
(WebCore::IDBServer::SQLiteIDBBackingStore::deleteObjectStore):
(WebCore::IDBServer::SQLiteIDBBackingStore::renameObjectStore):
(WebCore::IDBServer::SQLiteIDBBackingStore::clearObjectStore):
(WebCore::IDBServer::SQLiteIDBBackingStore::createIndex):
(WebCore::IDBServer::SQLiteIDBBackingStore::uncheckedPutIndexRecord):
(WebCore::IDBServer::SQLiteIDBBackingStore::deleteIndex):
(WebCore::IDBServer::SQLiteIDBBackingStore::renameIndex):
(WebCore::IDBServer::SQLiteIDBBackingStore::keyExistsInObjectStore):
(WebCore::IDBServer::SQLiteIDBBackingStore::deleteRecord):
(WebCore::IDBServer::SQLiteIDBBackingStore::deleteRange):
(WebCore::IDBServer::SQLiteIDBBackingStore::updateAllIndexesForAddRecord):
(WebCore::IDBServer::SQLiteIDBBackingStore::addRecord):
(WebCore::IDBServer::SQLiteIDBBackingStore::getRecord):
(WebCore::IDBServer::SQLiteIDBBackingStore::getAllObjectStoreRecords):
(WebCore::IDBServer::SQLiteIDBBackingStore::getIndexRecord):
(WebCore::IDBServer::SQLiteIDBBackingStore::uncheckedGetIndexRecordForOneKey):
(WebCore::IDBServer::SQLiteIDBBackingStore::getCount):
(WebCore::IDBServer::SQLiteIDBBackingStore::uncheckedGetKeyGeneratorValue):
(WebCore::IDBServer::SQLiteIDBBackingStore::uncheckedSetKeyGeneratorValue):
(WebCore::IDBServer::SQLiteIDBBackingStore::generateKeyNumber):
(WebCore::IDBServer::SQLiteIDBBackingStore::revertGeneratedKeyNumber):
(WebCore::IDBServer::SQLiteIDBBackingStore::maybeUpdateKeyGeneratorNumber):
(WebCore::IDBServer::SQLiteIDBBackingStore::infoForObjectStore):
* Source/WebCore/Modules/indexeddb/server/SQLiteIDBBackingStore.h:
* Source/WebCore/Modules/indexeddb/server/SQLiteIDBCursor.cpp:
(WebCore::IDBServer::SQLiteIDBCursor::maybeCreateBackingStoreCursor):
(WebCore::IDBServer::SQLiteIDBCursor::SQLiteIDBCursor):
(WebCore::IDBServer::SQLiteIDBCursor::establishStatement):
(WebCore::IDBServer::SQLiteIDBCursor::internalFetchNextRecord):
* Source/WebCore/Modules/indexeddb/server/SQLiteIDBCursor.h:
(WebCore::IDBServer::SQLiteIDBCursor::objectStoreID const):
* Source/WebCore/Modules/indexeddb/server/SQLiteIDBTransaction.cpp:
(WebCore::IDBServer::SQLiteIDBTransaction::maybeOpenBackingStoreCursor):
(WebCore::IDBServer::SQLiteIDBTransaction::notifyCursorsOfChanges):
* Source/WebCore/Modules/indexeddb/server/SQLiteIDBTransaction.h:
* Source/WebCore/Modules/indexeddb/server/UniqueIDBDatabase.cpp:
(WebCore::IDBServer::UniqueIDBDatabase::renameObjectStore):
(WebCore::IDBServer::UniqueIDBDatabase::clearObjectStore):
(WebCore::IDBServer::UniqueIDBDatabase::deleteIndex):
(WebCore::IDBServer::UniqueIDBDatabase::renameIndex):
(WebCore::IDBServer::scopesOverlap):
(WebCore::IDBServer::UniqueIDBDatabase::takeNextRunnableTransaction):
* Source/WebCore/Modules/indexeddb/server/UniqueIDBDatabase.h:
* Source/WebCore/Modules/indexeddb/server/UniqueIDBDatabaseTransaction.cpp:
(WebCore::IDBServer::UniqueIDBDatabaseTransaction::renameObjectStore):
(WebCore::IDBServer::UniqueIDBDatabaseTransaction::clearObjectStore):
(WebCore::IDBServer::UniqueIDBDatabaseTransaction::deleteIndex):
(WebCore::IDBServer::UniqueIDBDatabaseTransaction::renameIndex):
(WebCore::IDBServer::UniqueIDBDatabaseTransaction::objectStoreIdentifiers):
* Source/WebCore/Modules/indexeddb/server/UniqueIDBDatabaseTransaction.h:
* Source/WebCore/Modules/indexeddb/shared/IDBCursorInfo.cpp:
(WebCore::IDBCursorInfo::objectStoreCursor):
(WebCore::IDBCursorInfo::indexCursor):
(WebCore::IDBCursorInfo::IDBCursorInfo):
* Source/WebCore/Modules/indexeddb/shared/IDBCursorInfo.h:
(WebCore::IDBCursorInfo::objectStoreIdentifier const):
* Source/WebCore/Modules/indexeddb/shared/IDBDatabaseInfo.cpp:
(WebCore::IDBDatabaseInfo::IDBDatabaseInfo):
(WebCore::IDBDatabaseInfo::createNewObjectStore):
(WebCore::IDBDatabaseInfo::addExistingObjectStore):
(WebCore::IDBDatabaseInfo::getInfoForExistingObjectStore):
(WebCore::IDBDatabaseInfo::infoForExistingObjectStore const):
(WebCore::IDBDatabaseInfo::infoForExistingObjectStore):
(WebCore::IDBDatabaseInfo::renameObjectStore):
(WebCore::IDBDatabaseInfo::deleteObjectStore):
* Source/WebCore/Modules/indexeddb/shared/IDBDatabaseInfo.h:
(WebCore::IDBDatabaseInfo::IDBDatabaseInfo):
(WebCore::IDBDatabaseInfo::objectStoreMap const):
* Source/WebCore/Modules/indexeddb/shared/IDBGetAllRecordsData.h:
* Source/WebCore/Modules/indexeddb/shared/IDBIndexInfo.cpp:
(WebCore::IDBIndexInfo::IDBIndexInfo):
* Source/WebCore/Modules/indexeddb/shared/IDBIndexInfo.h:
(WebCore::IDBIndexInfo::objectStoreIdentifier const):
(WTF::HashTraits<WebCore::IDBIndexInfo>::emptyValue):
* Source/WebCore/Modules/indexeddb/shared/IDBObjectStoreInfo.cpp:
(WebCore::IDBObjectStoreInfo::IDBObjectStoreInfo):
* Source/WebCore/Modules/indexeddb/shared/IDBObjectStoreInfo.h:
(WebCore::IDBObjectStoreInfo::IDBObjectStoreInfo):
(WebCore::IDBObjectStoreInfo::identifier const):
(WTF::HashTraits<WebCore::IDBObjectStoreInfo>::emptyValue):
* Source/WebCore/Modules/indexeddb/shared/IDBRequestData.cpp:
(WebCore::IDBRequestData::IDBRequestData):
(WebCore::IDBRequestData::objectStoreIdentifier const):
* Source/WebCore/Modules/indexeddb/shared/IDBRequestData.h:
* Source/WebCore/WebCore.xcodeproj/project.pbxproj:
* Source/WebCore/loader/EmptyClients.cpp:
* Source/WebKit/NetworkProcess/storage/NetworkStorageManager.cpp:
(WebKit::NetworkStorageManager::renameObjectStore):
(WebKit::NetworkStorageManager::clearObjectStore):
(WebKit::NetworkStorageManager::deleteIndex):
(WebKit::NetworkStorageManager::renameIndex):
* Source/WebKit/NetworkProcess/storage/NetworkStorageManager.h:
* Source/WebKit/NetworkProcess/storage/NetworkStorageManager.messages.in:
* Source/WebKit/Scripts/webkit/messages.py:
(serialized_identifiers):
* Source/WebKit/Scripts/webkit/tests/MessageArgumentDescriptions.cpp:
(IPC::serializedIdentifiers):
* Source/WebKit/Shared/WTFArgumentCoders.serialization.in:
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:
* Source/WebKit/WebProcess/Databases/IndexedDB/WebIDBConnectionToServer.cpp:
(WebKit::WebIDBConnectionToServer::renameObjectStore):
(WebKit::WebIDBConnectionToServer::clearObjectStore):
(WebKit::WebIDBConnectionToServer::deleteIndex):
(WebKit::WebIDBConnectionToServer::renameIndex):
* Source/WebKit/WebProcess/Databases/IndexedDB/WebIDBConnectionToServer.h:
* Source/WebKitLegacy/Storage/InProcessIDBServer.cpp:
(InProcessIDBServer::renameObjectStore):
(InProcessIDBServer::clearObjectStore):
(InProcessIDBServer::deleteIndex):
(InProcessIDBServer::renameIndex):
* Source/WebKitLegacy/Storage/InProcessIDBServer.h:

Canonical link: https://commits.webkit.org/282416.246@webkitglib/2.46

  Commit: 57ef088f505c9caa4229632a993e61208e0ecaa7
      https://github.com/WebKit/WebKit/commit/57ef088f505c9caa4229632a993e61208e0ecaa7
  Author: Yusuke Suzuki <ysuzuki at apple.com>
  Date:   2024-10-25 (Fri, 25 Oct 2024)

  Changed paths:
    M Source/JavaScriptCore/wasm/WasmIRGeneratorHelpers.h
    M Source/JavaScriptCore/wasm/WasmOMGIRGenerator.cpp
    M Source/JavaScriptCore/wasm/WasmOMGIRGenerator32_64.cpp

  Log Message:
  -----------
  Cherry-pick 280938.323 at safari-7619-branch (8898391fae62). https://bugs.webkit.org/show_bug.cgi?id=279480

[JSC] Catch entering stack map computation in OMG is wrong for CallRef
https://bugs.webkit.org/show_bug.cgi?id=279480
rdar://133868556

Reviewed by David Degazio.

preparePatchpointForExceptions was assuming that we are appending stack
map generation constraints at the end of the sequence in Patchpoint.
But this is wrong for CallRef since we append a value after we set up
these stack map constraints. As a result, generated stack map is
offsetted by 2 in CallRef, using wrong values. This patch makes these
computation more robust: saving the current params offset and children
offset and use it later. This makes it possible to put stack map
generation whenever we would like to do.

* Source/JavaScriptCore/wasm/WasmIRGeneratorHelpers.h:
(JSC::Wasm::PatchpointExceptionHandle::PatchpointExceptionHandle):
(JSC::Wasm::PatchpointExceptionHandle::generate const):
* Source/JavaScriptCore/wasm/WasmOMGIRGenerator.cpp:
(JSC::Wasm::OMGIRGenerator::preparePatchpointForExceptions):
* Source/JavaScriptCore/wasm/WasmOMGIRGenerator32_64.cpp:
(JSC::Wasm::OMGIRGenerator::preparePatchpointForExceptions):

Canonical link: https://commits.webkit.org/282416.247@webkitglib/2.46

  Commit: a9f6d8e362c98cb2e3eeaf6827ea046260e2d621
      https://github.com/WebKit/WebKit/commit/a9f6d8e362c98cb2e3eeaf6827ea046260e2d621
  Author: Chris Dumez <cdumez at apple.com>
  Date:   2024-10-25 (Fri, 25 Oct 2024)

  Changed paths:
    M Source/WebKit/Platform/IPC/Decoder.cpp

  Log Message:
  -----------
  Cherry-pick 280938.329 at safari-7619-branch (ba52e5dc13c9). https://bugs.webkit.org/show_bug.cgi?id=279574

Do more validation of IPC::Decoder's destinationID
https://bugs.webkit.org/show_bug.cgi?id=279574
rdar://135525328

Reviewed by Darin Adler.

Do more validation of IPC::Decoder's destinationID. We have to keep allowing 0
since it is a valid destinationID. However, we can reject -1 which is the
HashTable's deleted value.

This is important since we sometimes constructor ObjectIdentifiers from the
decoder's destinationID and these ObjectIdentifiers may be used to look up
in a HashMap.

283525 at main also added more validation of the raw identifier when constructing
an ObjectIdentifier which will further protect us.

* Source/WebKit/Platform/IPC/Decoder.cpp:

Canonical link: https://commits.webkit.org/282416.248@webkitglib/2.46

  Commit: 8a12cae2351c22e9e6f33c84541cc904b8936ebd
      https://github.com/WebKit/WebKit/commit/8a12cae2351c22e9e6f33c84541cc904b8936ebd
  Author: Michael Catanzaro <mcatanzaro at redhat.com>
  Date:   2024-10-25 (Fri, 25 Oct 2024)

  Changed paths:
    M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp
    M Source/WebKit/NetworkProcess/ServiceWorker/WebSWServerToContextConnection.cpp

  Log Message:
  -----------
  Guard against constructor an ObjectIdentifier from a IPC::Decoder::destinationID that is 0
https://bugs.webkit.org/show_bug.cgi?id=279640

Unreviewed stable branch commit.

This is a simplified version of 280938.332 at safari-7619-branch with GPU
process and model process code removed, for webkitglib/2.46 branch. This
is based on a commit by Chris Dumez.

* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:
(WebKit::NetworkConnectionToWebProcess::didReceiveMessage):
* Source/WebKit/NetworkProcess/ServiceWorker/WebSWServerToContextConnection.cpp:
(WebKit::WebSWServerToContextConnection::didReceiveFetchTaskMessage):

Canonical link: https://commits.webkit.org/282416.249@webkitglib/2.46

  Commit: 42042266fd20e4ae14fa064931cb6bf35e9ff579
      https://github.com/WebKit/WebKit/commit/42042266fd20e4ae14fa064931cb6bf35e9ff579
  Author: Youenn Fablet <youenn at apple.com>
  Date:   2024-10-25 (Fri, 25 Oct 2024)

  Changed paths:
    A LayoutTests/imported/w3c/web-platform-tests/cors/preflight-cache-partitioning.sub.window-expected.txt
    A LayoutTests/imported/w3c/web-platform-tests/cors/preflight-cache-partitioning.sub.window.html
    A LayoutTests/imported/w3c/web-platform-tests/cors/preflight-cache-partitioning.sub.window.js
    A LayoutTests/imported/w3c/web-platform-tests/cors/resources/preflight-cache-partitioning-iframe.sub.html
    A LayoutTests/imported/w3c/web-platform-tests/cors/resources/preflight-cache-partitioning.sub.html
    A LayoutTests/imported/w3c/web-platform-tests/cors/resources/preflight-partitioning.py
    M Source/WebCore/loader/CrossOriginAccessControl.cpp
    M Source/WebCore/loader/CrossOriginAccessControl.h
    M Source/WebCore/loader/CrossOriginPreflightChecker.cpp
    M Source/WebCore/loader/CrossOriginPreflightResultCache.cpp
    M Source/WebCore/loader/CrossOriginPreflightResultCache.h
    M Source/WebCore/loader/DocumentThreadableLoader.cpp
    M Source/WebCore/loader/DocumentThreadableLoader.h
    M Source/WebKit/NetworkProcess/NetworkCORSPreflightChecker.cpp
    M Source/WebKit/NetworkProcess/NetworkCORSPreflightChecker.h
    M Source/WebKit/NetworkProcess/NetworkLoadChecker.cpp

  Log Message:
  -----------
  Cherry-pick 280938.345 at safari-7619-branch (77592f3b8e28). rdar://135272104

CORS-preflight cache is not partitioned by top-level site
rdar://135272104

Reviewed by Anne van Kesteren.

We were keying the preflight cache with a partition based on the fetch context origin.
After this patch, the partitioning will be based on the fetch context client origin (aka top context origin and fetch context origin).
This follows how other stored data like service workers or IDB are keyed.

This patch is switching NetworkCORSPreflightChecker topOrigin from a RefPtr to a Ref.
NetworkCORSPreflightChecker gets it from NetworkLoadChecker which is created by PingLoad and NetworkResourceLoader from its NetworkResourceLoadParameters.
As can be seen from WebLoaderStrategy code, NetworkResourceLoadParameters source origin and top origin are set even though they are made as RefPtr.
A follow-up patch should change NetworkResourceLoadParameters to use Ref instead of RefPtr.

Covered by imported WPT test.

* LayoutTests/imported/w3c/web-platform-tests/cors/preflight-cache-partitioning.sub.window-expected.txt: Added.
* LayoutTests/imported/w3c/web-platform-tests/cors/preflight-cache-partitioning.sub.window.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/cors/preflight-cache-partitioning.sub.window.js: Added.
(promise_test.async t):
* LayoutTests/imported/w3c/web-platform-tests/cors/resources/preflight-cache-partitioning-iframe.sub.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/cors/resources/preflight-cache-partitioning.sub.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/cors/resources/preflight-partitioning.py: Added.
(main):
* Source/WebCore/loader/CrossOriginAccessControl.cpp:
(WebCore::validatePreflightResponse):
* Source/WebCore/loader/CrossOriginAccessControl.h:
* Source/WebCore/loader/CrossOriginPreflightChecker.cpp:
(WebCore::CrossOriginPreflightChecker::validatePreflightResponse):
* Source/WebCore/loader/CrossOriginPreflightResultCache.cpp:
(WebCore::CrossOriginPreflightResultCache::appendEntry):
(WebCore::CrossOriginPreflightResultCache::canSkipPreflight):
* Source/WebCore/loader/CrossOriginPreflightResultCache.h:
* Source/WebCore/loader/DocumentThreadableLoader.cpp:
(WebCore::DocumentThreadableLoader::makeCrossOriginAccessRequest):
(WebCore::DocumentThreadableLoader::topOrigin const):
* Source/WebCore/loader/DocumentThreadableLoader.h:
* Source/WebKit/NetworkProcess/NetworkCORSPreflightChecker.cpp:
(WebKit::NetworkCORSPreflightChecker::didReceiveChallenge):
(WebKit::NetworkCORSPreflightChecker::didCompleteWithError):
* Source/WebKit/NetworkProcess/NetworkCORSPreflightChecker.h:
* Source/WebKit/NetworkProcess/NetworkLoadChecker.cpp:
(WebKit::NetworkLoadChecker::checkCORSRequestWithPreflight):

Canonical link: https://commits.webkit.org/282416.250@webkitglib/2.46

  Commit: 135cab6161b31a3e700108733c3837a3b21f7f05
      https://github.com/WebKit/WebKit/commit/135cab6161b31a3e700108733c3837a3b21f7f05
  Author: Daniel Liu <danlliu at umich.edu>
  Date:   2024-10-25 (Fri, 25 Oct 2024)

  Changed paths:
    M JSTests/stress/regexp-vflag-property-of-strings.js
    M Source/JavaScriptCore/yarr/YarrPattern.cpp

  Log Message:
  -----------
  Cherry-pick 280938.353 at safari-7619-branch (85d061be2854). https://bugs.webkit.org/show_bug.cgi?id=279780

Perform a second sort on characters in case-insensitive disjunction
https://bugs.webkit.org/show_bug.cgi?id=279780
rdar://135576504

Reviewed by Yusuke Suzuki and Michael Saboff.

Certain ASCII characters can introduce Unicode characters (and vice versa)
when we add all case variations in a case insensitive regex. This leads to
incorrect behavior in performSetOpWithMatches, since we assume that the
matches are in sorted order.

* Source/JavaScriptCore/yarr/YarrPattern.cpp:
(JSC::Yarr::CharacterClassConstructor::atomClassStringDisjunction):

Canonical link: https://commits.webkit.org/282416.251@webkitglib/2.46

  Commit: 8698023f244fc078f83955d277759a734e68e86f
      https://github.com/WebKit/WebKit/commit/8698023f244fc078f83955d277759a734e68e86f
  Author: Frédéric Wang <fwang at igalia.com>
  Date:   2024-10-25 (Fri, 25 Oct 2024)

  Changed paths:
    A LayoutTests/platform/glib/svg/stroke/nan-stroke-width-crash-expected.txt
    A LayoutTests/platform/ios/svg/stroke/nan-stroke-width-crash-expected.txt
    A LayoutTests/platform/mac/svg/stroke/nan-stroke-width-crash-expected.txt
    A LayoutTests/svg/stroke/nan-stroke-width-crash.html
    M Source/WebCore/rendering/svg/RenderSVGShape.cpp
    M Source/WebCore/rendering/svg/legacy/LegacyRenderSVGShape.cpp

  Log Message:
  -----------
  Cherry-pick 280938.2 at webkit-2024.7-embargoed (c044da77e2dd). https://bugs.webkit.org/show_bug.cgi?id=276898

Interpret NaN values in (Legacy)RenderSVGShape::strokeWidth() as 0.
https://bugs.webkit.org/show_bug.cgi?id=276898
rdar://126635831

Reviewed by Simon Fraser.

* LayoutTests/platform/gtk/svg/stroke/nan-stroke-width-crash-expected.txt: Added.
* LayoutTests/svg/stroke/nan-stroke-width-crash.html: Added.
* Source/WebCore/rendering/svg/RenderSVGShape.cpp:
(WebCore::RenderSVGShape::strokeWidth const): Map NaN values to 0.
* Source/WebCore/rendering/svg/legacy/LegacyRenderSVGShape.cpp:
(WebCore::LegacyRenderSVGShape::strokeWidth const): Ditto.

Canonical link: https://commits.webkit.org/280938.2@webkit-2024.7-embargoed

Canonical link: https://commits.webkit.org/282416.252@webkitglib/2.46

  Commit: ec1731b0544ff63e179e01a46247b8f7272f8bcb
      https://github.com/WebKit/WebKit/commit/ec1731b0544ff63e179e01a46247b8f7272f8bcb
  Author: Philippe Normand <philn at igalia.com>
  Date:   2024-10-28 (Mon, 28 Oct 2024)

  Changed paths:
    R LayoutTests/platform/glib/imported/w3c/web-platform-tests/webcodecs/video-encoder-h264.https.any.worker_baseline-expected.txt
    R LayoutTests/platform/glib/imported/w3c/web-platform-tests/webcodecs/video-encoder-h264.https.any.worker_high-expected.txt
    R LayoutTests/platform/glib/imported/w3c/web-platform-tests/webcodecs/video-encoder-h264.https.any.worker_main-expected.txt
    R LayoutTests/platform/glib/imported/w3c/web-platform-tests/webcodecs/video-encoder-h264.https.any_baseline-expected.txt
    R LayoutTests/platform/glib/imported/w3c/web-platform-tests/webcodecs/video-encoder-h264.https.any_high-expected.txt
    R LayoutTests/platform/glib/imported/w3c/web-platform-tests/webcodecs/video-encoder-h264.https.any_main-expected.txt
    M Source/WebCore/platform/gstreamer/GStreamerCodecUtilities.cpp
    M Source/WebCore/platform/gstreamer/VideoEncoderPrivateGStreamer.cpp

  Log Message:
  -----------
  Cherry-pick 285691 at main (019a912ac61b). https://bugs.webkit.org/show_bug.cgi?id=281977

    [GStreamer][WebCodecs] H.264 encoding fixes
    https://bugs.webkit.org/show_bug.cgi?id=281977

    Reviewed by Xabier Rodriguez-Calvar.

    While debugging some mediarecorder test failure a caps negotiation issue was detected in our video
    encoder. Encodebin2 was expecting an avc stream on the encoder output. Updating our encoder
    accordingly made some WebCodec tests pass. In addition to that change, the X264 encoder is
    explicitely configured according to the requested H.264 profile.

    * LayoutTests/platform/glib/imported/w3c/web-platform-tests/webcodecs/video-encoder-h264.https.any.worker_baseline-expected.txt: Removed.
    * LayoutTests/platform/glib/imported/w3c/web-platform-tests/webcodecs/video-encoder-h264.https.any.worker_high-expected.txt: Removed.
    * LayoutTests/platform/glib/imported/w3c/web-platform-tests/webcodecs/video-encoder-h264.https.any.worker_main-expected.txt: Removed.
    * LayoutTests/platform/glib/imported/w3c/web-platform-tests/webcodecs/video-encoder-h264.https.any_baseline-expected.txt: Removed.
    * LayoutTests/platform/glib/imported/w3c/web-platform-tests/webcodecs/video-encoder-h264.https.any_high-expected.txt: Removed.
    * LayoutTests/platform/glib/imported/w3c/web-platform-tests/webcodecs/video-encoder-h264.https.any_main-expected.txt: Removed.
    * Source/WebCore/platform/gstreamer/VideoEncoderPrivateGStreamer.cpp:
    (webkit_video_encoder_class_init):

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

Canonical link: https://commits.webkit.org/282416.253@webkitglib/2.46

Compare: https://github.com/WebKit/WebKit/compare/80a156c32bbc...ec1731b0544f

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