Branch: refs/heads/safari-7621.2.5.10-branch
Home: https://github.com/WebKit/WebKit
Commit: 3f32080739f018d5d4a56ccb3a848617946b76f5
https://github.com/WebKit/WebKit/commit/3f32080739f018d5d4a56ccb3a848617946b76f5
Author: Mohsin Qureshi <mohs...@apple.com>
Date: 2025-04-15 (Tue, 15 Apr 2025)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7621.2.5.10.1
Canonical link: https://commits.webkit.org/289651.427@safari-7621.2.5.10-branch
Commit: a764eb66ded0888b957af516a47924e710c15bf4
https://github.com/WebKit/WebKit/commit/a764eb66ded0888b957af516a47924e710c15bf4
Author: Razvan Caliman <rcali...@apple.com>
Date: 2025-04-16 (Wed, 16 Apr 2025)
Changed paths:
M Source/WebInspectorUI/UserInterface/Views/OverrideDeviceSettingsPopover.js
Log Message:
-----------
Cherry-pick 3d0966402274. rdar://144707833
Web Inspector: Update User Agent string overrides aligned with Safari 18.4
https://bugs.webkit.org/show_bug.cgi?id=290920
rdar://144707833
Reviewed by Anne van Kesteren.
*
Source/WebInspectorUI/UserInterface/Views/OverrideDeviceSettingsPopover.js:
(WI.OverrideDeviceSettingsPopover.prototype._createUserAgentSection):
Canonical link: https://commits.webkit.org/293112@main
Canonical link: https://commits.webkit.org/289651.428@safari-7621.2.5.10-branch
Commit: 0cd88c9f5434c2feeb8576fe67eed955e320fb12
https://github.com/WebKit/WebKit/commit/0cd88c9f5434c2feeb8576fe67eed955e320fb12
Author: Daniel Liu <danl...@umich.edu>
Date: 2025-04-16 (Wed, 16 Apr 2025)
Changed paths:
M Source/WebCore/bindings/js/SerializedScriptValue.cpp
Log Message:
-----------
Cherry-pick 94ec0f4523cc. rdar://144781310
Re-land missing exception checks
https://bugs.webkit.org/show_bug.cgi?id=291290
rdar://144781310
Reviewed by Yijia Huang and Yusuke Suzuki.
Re-land the exception checks added in 292722@main, but fixing some issues
that
occurred when running Debug layout tests.
* Source/WebCore/bindings/js/SerializedScriptValue.cpp:
(WebCore::CloneDeserializer::deserialize):
(WebCore::SerializedScriptValue::create):
(WebCore::SerializedScriptValue::deserialize):
Canonical link: https://commits.webkit.org/293437@main
Canonical link: https://commits.webkit.org/289651.429@safari-7621.2.5.10-branch
Commit: 99909cc234681e5902a2b74ae7619cd89de71747
https://github.com/WebKit/WebKit/commit/99909cc234681e5902a2b74ae7619cd89de71747
Author: Rob Buis <rb...@igalia.com>
Date: 2025-04-16 (Wed, 16 Apr 2025)
Changed paths:
A LayoutTests/css3/masking/shared-clip-path-reference-crash-expected.txt
A LayoutTests/css3/masking/shared-clip-path-reference-crash.html
M Source/WebCore/rendering/RenderLayer.cpp
M Source/WebCore/rendering/RenderLayer.h
M Source/WebCore/rendering/svg/legacy/LegacyRenderSVGResourceContainer.cpp
Log Message:
-----------
Cherry-pick 441eda47158d. rdar://144407636
Cherry-pick 289651.9@webkit-2025.2-embargoed (ff0112ba3d52).
rdar://144407636
ASAN_TRAP | WTF::HashTable::lookup;
WebCore::LegacyRenderSVGResource::markForLayoutAndParentResourceInvalidation;
WebCore::SVGResourcesCache::clientStyleChanged
https://bugs.webkit.org/show_bug.cgi?id=288442
Reviewed by Simon Fraser.
LegacyRenderSVGResourceClipper.m_clipperMap is used to keep track of
clipper data per client, the client
can be a HTML element referencing the clipper by using the clip-path
property. The registering for that is done
in RenderLayer::setupClipPath but there is no code to deregister on
HTML element removal, so the m_clipperMap
keys will become a WeakRef with empty internal pointer for HTML
elements, causing a RELEASE_ASSERT.
To fix this, include deregistering code on RenderLayer destruction.
*
LayoutTests/css3/masking/shared-clip-path-reference-crash-expected.txt: Added.
* LayoutTests/css3/masking/shared-clip-path-reference-crash.html: Added.
* Source/WebCore/rendering/RenderLayer.cpp:
(WebCore::RenderLayer::~RenderLayer):
(WebCore::RenderLayer::removeClipperClientIfNeeded const):
* Source/WebCore/rendering/RenderLayer.h:
*
Source/WebCore/rendering/svg/legacy/LegacyRenderSVGResourceContainer.cpp:
(WebCore::LegacyRenderSVGResourceContainer::markClientForInvalidation):
Canonical link:
https://commits.webkit.org/289651.9@webkit-2025.2-embargoed
Canonical link: https://commits.webkit.org/289651.427@safari-7621-branch
Canonical link: https://commits.webkit.org/289651.430@safari-7621.2.5.10-branch
Commit: db05c9885349fb538f7ce8c0165d5563b10d600c
https://github.com/WebKit/WebKit/commit/db05c9885349fb538f7ce8c0165d5563b10d600c
Author: Daniel Liu <danl...@umich.edu>
Date: 2025-04-16 (Wed, 16 Apr 2025)
Changed paths:
A JSTests/wasm/stress/array-get-large-i64-index.js
M Source/JavaScriptCore/wasm/WasmBBQJIT64.cpp
Log Message:
-----------
Cherry-pick 341845413761. rdar://149185657
BBQJIT array operations should mask index to 32 bits
https://bugs.webkit.org/show_bug.cgi?id=291506
rdar://149185657
Reviewed by Keith Miller.
BBQ array operations (get/set) assume that the index passed
in will be 32 bits. While this is correct by spec behavior,
we do not check that the upper 32 bits of the value are set
to zero, but use the value directly. This creates potential
OOB opportunities, where we can influence the upper 32 bits
of the pointer to index out of bounds. To fix this, we must
mask off the upper 32 bits of the index value before it can
be used in a load/store.
* JSTests/wasm/stress/array-get-large-i64-index.js: Added.
* Source/JavaScriptCore/wasm/WasmBBQJIT64.cpp:
(JSC::Wasm::BBQJITImpl::BBQJIT::addArrayGet):
(JSC::Wasm::BBQJITImpl::BBQJIT::addArraySet):
Canonical link: https://commits.webkit.org/289651.431@safari-7621-branch
Canonical link: https://commits.webkit.org/289651.431@safari-7621.2.5.10-branch
Commit: bfcb45a246a91c86d2328bb3738fa52f201c8f46
https://github.com/WebKit/WebKit/commit/bfcb45a246a91c86d2328bb3738fa52f201c8f46
Author: Brent Fulgham <bfulg...@apple.com>
Date: 2025-04-16 (Wed, 16 Apr 2025)
Changed paths:
M LayoutTests/TestExpectations
M LayoutTests/platform/glib/tables/mozilla/bugs/bug30332-1-expected.txt
M LayoutTests/platform/glib/tables/mozilla/bugs/bug30332-2-expected.txt
M LayoutTests/platform/glib/tables/mozilla/bugs/bug9879-1-expected.txt
M
LayoutTests/platform/glib/tables/mozilla_expected_failures/bugs/bug9879-1-expected.txt
M LayoutTests/platform/ios/tables/mozilla/bugs/bug30332-1-expected.txt
M LayoutTests/platform/ios/tables/mozilla/bugs/bug30332-2-expected.txt
M LayoutTests/platform/ios/tables/mozilla/bugs/bug9879-1-expected.txt
M
LayoutTests/platform/ios/tables/mozilla_expected_failures/bugs/bug9879-1-expected.txt
M LayoutTests/platform/mac/tables/mozilla/bugs/bug30332-1-expected.txt
M LayoutTests/platform/mac/tables/mozilla/bugs/bug30332-2-expected.txt
M LayoutTests/platform/mac/tables/mozilla/bugs/bug9879-1-expected.txt
M
LayoutTests/platform/mac/tables/mozilla_expected_failures/bugs/bug9879-1-expected.txt
M Source/WebCore/html/HTMLTableCellElement.cpp
Log Message:
-----------
Cherry-pick 7106a5905d11. rdar://149318862
Unreviewed, reverting 288746@main (75a5507d4d8f)
https://bugs.webkit.org/show_bug.cgi?id=291584
rdar://149318862
Exposes an underlying performance bug
Reverted change:
rowspan="0" results in different table layout than Firefox/Chrome
https://bugs.webkit.org/show_bug.cgi?id=185341
rdar://133910430
288746@main (75a5507d4d8f)
Canonical link: https://commits.webkit.org/289651.432@safari-7621-branch
Canonical link: https://commits.webkit.org/289651.432@safari-7621.2.5.10-branch
Commit: 86426e4277ce94878044a07789cb09d73c12d43c
https://github.com/WebKit/WebKit/commit/86426e4277ce94878044a07789cb09d73c12d43c
Author: Dan Robson <dtr_bugzi...@apple.com>
Date: 2025-04-17 (Thu, 17 Apr 2025)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7621.2.5.10.2
Canonical link: https://commits.webkit.org/289651.433@safari-7621.2.5.10-branch
Commit: 6f027e4046981b5f3d99571e3a33174b617e8cd4
https://github.com/WebKit/WebKit/commit/6f027e4046981b5f3d99571e3a33174b617e8cd4
Author: Jean-Yves Avenard <j...@apple.com>
Date: 2025-04-17 (Thu, 17 Apr 2025)
Changed paths:
A LayoutTests/media/content/test-vp9-yuv422p10.webm
A LayoutTests/media/content/test-vp9-yuv422p10.webm.png
A LayoutTests/media/media-vp9-yuv422p10-expected.html
A LayoutTests/media/media-vp9-yuv422p10.html
M LayoutTests/platform/ios/TestExpectations
M LayoutTests/platform/mac-wk1/TestExpectations
M
Source/ThirdParty/libwebrtc/Source/webrtc/webkit_sdk/WebKit/WebKitDecoderReceiver.cpp
M
Source/ThirdParty/libwebrtc/Source/webrtc/webkit_sdk/WebKit/WebKitDecoderReceiver.h
M
Source/ThirdParty/libwebrtc/Source/webrtc/webkit_sdk/WebKit/WebKitUtilities.h
M
Source/ThirdParty/libwebrtc/Source/webrtc/webkit_sdk/WebKit/WebKitUtilities.mm
M Source/WebCore/platform/libwebrtc/LibWebRTCVPXVideoDecoder.cpp
M Source/WebCore/platform/mediastream/libwebrtc/VideoFrameLibWebRTC.cpp
Log Message:
-----------
Cherry-pick 0dec430870a0. rdar://148703791
Some Steam webm videos don't play in Safari
https://bugs.webkit.org/show_bug.cgi?id=291420
rdar://148703791
Reviewed by Jer Noble.
Video was made of a vp9 10 bits video for which we don't have hardware
decoder.
In addition, the software video decoder only supported YUV 420 (NV12) in
either 8 or 10 bits.
We add support for YUV 422 in either 8 or 10 bits in both WebCodec and VP9
macOS VideoToolbox plugin.
YUV 422 8 bits will be converted to NV12 as libyuv doesn't provide the
required utility.
Added test.
* LayoutTests/media/content/test-vp9-yuv422p10.webm: Added.
* LayoutTests/media/content/test-vp9-yuv422p10.webm.png: Added.
* LayoutTests/media/media-vp9-yuv422p10-expected.html: Added.
* LayoutTests/media/media-vp9-yuv422p10.html: Added.
* LayoutTests/platform/mac-wk1/TestExpectations:
*
Source/ThirdParty/libwebrtc/Source/webrtc/webkit_sdk/WebKit/WebKitDecoderReceiver.cpp:
(webrtc::WebKitDecoderReceiver::initializeFromFormatDescription):
(webrtc::WebKitDecoderReceiver::pixelBufferPool):
(webrtc::WebKitDecoderReceiver::Decoded):
*
Source/ThirdParty/libwebrtc/Source/webrtc/webkit_sdk/WebKit/WebKitDecoderReceiver.h:
*
Source/ThirdParty/libwebrtc/Source/webrtc/webkit_sdk/WebKit/WebKitUtilities.h:
*
Source/ThirdParty/libwebrtc/Source/webrtc/webkit_sdk/WebKit/WebKitUtilities.mm:
(webrtc::CopyVideoFrameToPixelBuffer):
(webrtc::createPixelBufferFromFrameBuffer):
* Source/WebCore/platform/libwebrtc/LibWebRTCVPXVideoDecoder.cpp:
(WebCore::LibWebRTCVPXInternalVideoDecoder::createPixelBuffer):
* Source/WebCore/platform/mediastream/libwebrtc/VideoFrameLibWebRTC.cpp:
(WebCore::VideoFrameLibWebRTC::create):
(WebCore::VideoFrameLibWebRTC::VideoFrameLibWebRTC):
Canonical link: https://commits.webkit.org/293620@main
Canonical link: https://commits.webkit.org/289651.434@safari-7621.2.5.10-branch
Commit: f02385a04af9abbc61b280b19ce83e5f344cf401
https://github.com/WebKit/WebKit/commit/f02385a04af9abbc61b280b19ce83e5f344cf401
Author: Said Abou-Hallawa <s...@apple.com>
Date: 2025-04-17 (Thu, 17 Apr 2025)
Changed paths:
M Source/WebCore/PAL/PAL.xcodeproj/project.pbxproj
A Source/WebCore/PAL/pal/cocoa/LockdownModeCocoa.h
A Source/WebCore/PAL/pal/cocoa/LockdownModeCocoa.mm
R Source/WebCore/PAL/pal/cocoa/LockdownModeSoftLink.h
R Source/WebCore/PAL/pal/cocoa/LockdownModeSoftLink.mm
M Source/WebCore/platform/graphics/cg/UTIRegistry.mm
M Source/WebKit/UIProcess/API/Cocoa/_WKSystemPreferences.mm
M Source/WebKit/WebProcess/WebProcess.cpp
Log Message:
-----------
Cherry-pick 69431ee57734. rdar://149401615
REGRESSION(289593@main): Images are still restricted even after opting out
pages from Lockdown Mode
https://bugs.webkit.org/show_bug.cgi?id=291614#
rdar://147500578
Reviewed by Tim Horton.
In 289593@main we made UTIRegistry call PAL::isLockdownModeEnabled() to
detect
whether the Lockdown Mode is enabled. But this function ends up calling the
system
LockdownModeLibrary. This does not take into consideration the opted out
pages.
So this causes the restricted images to be always restricted in Lockdown
Mode.
The fix is to used WebProcess::isLockdownModeEnabled() instead because this
will
return false when opting out the page. To propagate this to WebCore a
getter and
a setter for isLockdownModeEnabledForCurrentProcess will be added in PAL.
UTIRegistry will call PAL::isLockdownModeEnabledForCurrentProcess() instead.
* Source/WebCore/PAL/PAL.xcodeproj/project.pbxproj:
* Source/WebCore/PAL/pal/cocoa/LockdownModeCocoa.h: Renamed from
Source/WebCore/PAL/pal/cocoa/LockdownModeSoftLink.h.
* Source/WebCore/PAL/pal/cocoa/LockdownModeCocoa.mm: Renamed from
Source/WebCore/PAL/pal/cocoa/LockdownModeSoftLink.mm.
(PAL::isLockdownModeEnabled):
(PAL::isLockdownModeEnabledForCurrentProcessCached):
(PAL::isLockdownModeEnabledForCurrentProcess):
(PAL::setLockdownModeEnabledForCurrentProcess):
* Source/WebCore/platform/graphics/cg/UTIRegistry.mm:
(WebCore::supportedImageTypes):
(WebCore::setAdditionalSupportedImageTypes):
(WebCore::allowableSupportedImageTypes):
(WebCore::isLockdownModeEnabled): Deleted.
* Source/WebKit/UIProcess/API/Cocoa/_WKSystemPreferences.mm:
* Source/WebKit/WebProcess/WebProcess.cpp:
(WebKit::WebProcess::initializeWebProcess):
Canonical link: https://commits.webkit.org/293755@main
Canonical link: https://commits.webkit.org/289651.435@safari-7621.2.5.10-branch
Commit: 691795bc7806636b227395232205e27543528d04
https://github.com/WebKit/WebKit/commit/691795bc7806636b227395232205e27543528d04
Author: Kiet Ho <kiet...@apple.com>
Date: 2025-04-17 (Thu, 17 Apr 2025)
Changed paths:
A
LayoutTests/http/tests/security/access-cssstylesheet-after-removing-from-document-expected.txt
A
LayoutTests/http/tests/security/access-cssstylesheet-after-removing-from-document.html
A
LayoutTests/http/tests/security/access-imported-cssstylesheet-after-removing-from-document-expected.txt
A
LayoutTests/http/tests/security/access-imported-cssstylesheet-after-removing-from-document.html
M LayoutTests/http/tests/security/cannot-read-cssrules-redirect-expected.txt
M
LayoutTests/imported/w3c/web-platform-tests/service-workers/service-worker/fetch-request-css-cross-origin.https-expected.txt
M Source/WebCore/css/CSSImportRule.cpp
M Source/WebCore/css/CSSStyleSheet.cpp
M Source/WebCore/css/CSSStyleSheet.h
M Source/WebCore/dom/ProcessingInstruction.cpp
M Source/WebCore/html/HTMLLinkElement.cpp
Log Message:
-----------
Cherry-pick be53cebfe0d9. rdar://148513087
Tighten up cross-site access to CSSStyleSheet
rdar://148513087
https://bugs.webkit.org/show_bug.cgi?id=290992
Reviewed by Youenn Fablet.
CSSStyleSheet::canAccessRules() gates access to rules within
CSSStyleSheet, depending on whether the JS code and stylesheet comes
from the same origin.
bool CSSStyleSheet::canAccessRules() const
{
if (m_isOriginClean) // (1)
return m_isOriginClean.value();
URL baseURL = m_contents->baseURL(); // (2)
if (baseURL.isEmpty())
return true;
Document* document = ownerDocument(); // (3)
if (!document)
return true; // (4)
return document->protectedSecurityOrigin()->canRequest(baseURL,
OriginAccessPatternsForWebProcess::singleton()); // (5)
}
If CSSStyleSheet is constructed with an explicit same-origin flag, (which
indicates the origin status of the JS code and stylesheet), that flag is
used (1). Otherwise, it manually checks the origin:
* get the base URL of the stylesheet (2)
* get the document owner of the CSSStyleSheet
(also the document that the JS code is in) (3)
* check whether the JS code and the stylesheet is same-origin (5)
There's a bug at (4) - it grants access if the CSSStyleSheet doesn't
belong to a Document. Malicious JS code can manipulate a cross-origin
CSSStyleSheet into this state:
* If the CSSStyleSheet comes from HTMLLinkElement.sheet (<link
rel="stylesheet">)
or HTMLStyleElement.sheet (<style>), remove the <link> or <style> element
from the document e.g using Node.removeChild
* If it comes from CSSImportRule.styleSheet (@import), remove the
stylesheet containing the @import rule from the document
Following the removal, ownerDocument() returns nullptr, and access is
granted. Fix this by changing (4) to return false instead.
Unfortunately, many places in the codebase construct CSSStyleSheet
without supplying the same-origin flag, instead relying on the
fallback check. For those cases, this change introduces a regression
where if a same-origin stylesheet is created without the same-origin
flag, then is removed from the document, the fallback check will
incorrectly deny access. Fix this by hunting down places that
construct CSSStyleSheet and supply the flag if possible.
Also fix CSSStyleSheet.{insert,delete}Rule to always check with
canAccessRules() before allowing insertion/deletion.
*
LayoutTests/http/tests/security/access-cssstylesheet-after-removing-from-document-expected.txt:
Added.
*
LayoutTests/http/tests/security/access-cssstylesheet-after-removing-from-document.html:
Added.
*
LayoutTests/http/tests/security/access-imported-cssstylesheet-after-removing-from-document-expected.txt:
Added.
*
LayoutTests/http/tests/security/access-imported-cssstylesheet-after-removing-from-document.html:
Added.
*
LayoutTests/http/tests/security/cannot-read-cssrules-redirect-expected.txt:
- Adjust expectation. This now matches Chrome's output.
*
LayoutTests/imported/w3c/web-platform-tests/service-workers/service-worker/fetch-request-css-cross-origin.https-expected.txt:
* Source/WebCore/css/CSSImportRule.cpp:
(WebCore::CSSImportRule::styleSheet const):
- Supply same-origin flag when creating CSSStyleSheet if possible.
* Source/WebCore/css/CSSStyleSheet.cpp:
(WebCore::CSSStyleSheet::create):
- Make ::create for @import rules take an optional same-origin flag.
(WebCore::CSSStyleSheet::createInline):
- Take an optional same-origin flag.
(WebCore::CSSStyleSheet::canAccessRules const):
- Deny access if the CSSStyleSheet does not belong to a Document.
(WebCore::CSSStyleSheet::insertRule):
- Deny access if not allowed (using canAccessRules())
(WebCore::CSSStyleSheet::deleteRule):
- Deny access if not allowed (using canAccessRules())
* Source/WebCore/css/CSSStyleSheet.h:
* Source/WebCore/dom/ProcessingInstruction.cpp:
(WebCore::ProcessingInstruction::setCSSStyleSheet):
- Supply same-origin flag when creating CSSStyleSheet.
* Source/WebCore/html/HTMLLinkElement.cpp:
(WebCore::HTMLLinkElement::initializeStyleSheet):
- Always set the origin clean flag, regardless whether the fetch
request is CORS or not.
Canonical link: https://commits.webkit.org/289651.433@safari-7621-branch
Canonical link: https://commits.webkit.org/289651.436@safari-7621.2.5.10-branch
Commit: 0370f4ea904fbc41fa9aa061e01e913c591df745
https://github.com/WebKit/WebKit/commit/0370f4ea904fbc41fa9aa061e01e913c591df745
Author: Sihui Liu <sihui_...@apple.com>
Date: 2025-04-17 (Thu, 17 Apr 2025)
Changed paths:
M Source/WebCore/platform/network/ResourceResponseBase.cpp
M Source/WebCore/platform/network/ResourceResponseBase.h
Log Message:
-----------
Cherry-pick cdd407b46a54. rdar://148182167
ResourceResponseData::proxyName is not properly isolated copied
https://bugs.webkit.org/show_bug.cgi?id=291646
rdar://148182167
Reviewed by Chris Dumez.
In existing implementation, ResourceResponseData::proxyName is not isolated
copied or moved correctly at the places it
is supposed to be, and this can be the cause of increasing crashes we saw
in recent builds. Credits to Chris who found
the issue.
* Source/WebCore/platform/network/ResourceResponseBase.cpp:
(WebCore::ResourceResponseData::isolatedCopy const):
(WebCore::ResourceResponseBase::crossThreadData const):
(WebCore::ResourceResponseBase::fromCrossThreadData):
* Source/WebCore/platform/network/ResourceResponseBase.h:
(WebCore::ResourceResponseBase::setProxyName):
(WebCore::ResourceResponseBase::proxyName const):
Canonical link: https://commits.webkit.org/289651.434@safari-7621-branch
Canonical link: https://commits.webkit.org/289651.437@safari-7621.2.5.10-branch
Commit: 9f3822bac19a4af5b28755b98f0cfa082547c98b
https://github.com/WebKit/WebKit/commit/9f3822bac19a4af5b28755b98f0cfa082547c98b
Author: Sihui Liu <sihui_...@apple.com>
Date: 2025-04-17 (Thu, 17 Apr 2025)
Changed paths:
M Source/WebCore/platform/graphics/ImageAdapter.h
M Source/WebCore/platform/graphics/ImageUtilities.h
M Source/WebCore/platform/graphics/ShareableBitmap.cpp
M Source/WebCore/platform/graphics/ShareableBitmap.h
M Source/WebCore/platform/graphics/cg/ImageUtilitiesCG.cpp
M Source/WebKit/UIProcess/Cocoa/WebPageProxyCocoa.mm
M Source/WebKit/WebProcess/WebPage/Cocoa/WebPageCocoa.mm
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKit/WebProcess/WebPage/WebPage.messages.in
Log Message:
-----------
Cherry-pick db75e4455949. rdar://143579665
Make web process send ShareableBitmap instead of SharedBuffer for icon data
https://bugs.webkit.org/show_bug.cgi?id=290873
rdar://143579665
Reviewed by Said Abou-Hallawa and Anne van Kesteren.
In existing implementation of icon data generation, UI process sends image
data to web process, and web process decodes
image from data, generates images with different sizes, combines them into
one ico image and sends back image data to UI
process. To make the process more safe, this patch makes web process send
images (bitmaps) with different sizes to UI
process, and UI process is responsible for combining them into an ico image.
* Source/WebCore/platform/graphics/ImageAdapter.h:
(WebCore::ImageAdapter::image const):
* Source/WebCore/platform/graphics/ImageUtilities.h:
* Source/WebCore/platform/graphics/ShareableBitmap.cpp:
(WebCore::ShareableBitmap::createFromImageDraw):
* Source/WebCore/platform/graphics/ShareableBitmap.h:
* Source/WebCore/platform/graphics/cg/ImageUtilitiesCG.cpp:
(WebCore::createBitmapsFromNativeImage):
(WebCore::createNativeImageFromSVGImage):
(WebCore::createBitmapsFromSVGImage):
(WebCore::createBitmapsFromImageData):
(WebCore::createIconDataFromBitmaps):
(WebCore::expandNativeImageToData): Deleted.
(WebCore::expandSVGImageToData): Deleted.
(WebCore::createIconDataFromImageData): Deleted.
* Source/WebKit/UIProcess/Cocoa/WebPageProxyCocoa.mm:
(WebKit::WebPageProxy::createIconDataFromImageData):
* Source/WebKit/WebProcess/WebPage/Cocoa/WebPageCocoa.mm:
(WebKit::WebPage::createBitmapsFromImageData):
(WebKit::WebPage::createIconDataFromImageData): Deleted.
* Source/WebKit/WebProcess/WebPage/WebPage.h:
* Source/WebKit/WebProcess/WebPage/WebPage.messages.in:
* Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* Tools/TestWebKitAPI/Tests/WebKit/icon-svg-16.tiff: Added.
* Tools/TestWebKitAPI/Tests/WebKit/icon-svg-256.tiff: Added.
* Tools/TestWebKitAPI/Tests/WebKitCocoa/LoadAndDecodeImage.mm:
(TestWebKitAPI::tiffRepresentation):
(TestWebKitAPI::TEST(WebKit, CreateIconDataFromImageDataSVG)):
Canonical link: https://commits.webkit.org/293430@main
Canonical link: https://commits.webkit.org/289651.438@safari-7621.2.5.10-branch
Commit: fa253abaa7d184bb7926d4f94012ac1710d40a26
https://github.com/WebKit/WebKit/commit/fa253abaa7d184bb7926d4f94012ac1710d40a26
Author: Matthieu Dubet <m_du...@apple.com>
Date: 2025-04-17 (Thu, 17 Apr 2025)
Changed paths:
M Source/WebCore/css/CSSStyleRule.cpp
M Source/WebCore/css/CSSStyleSheet.cpp
Log Message:
-----------
Cherry-pick 79a886fb157b. rdar://147446595
[CSS] Clear StyleSheetContents hasNestingRuleCache on any rule mutation
https://bugs.webkit.org/show_bug.cgi?id=291695
rdar://147446595
Reviewed by Antti Koivisto.
Currently only CSSStyleRule::insertRule() API clear the cache,
however we can also insert a first StyleRuleWithNesting directly at the
top level which will use CSSStyleSheet::insertRule() or
inside a group rule (like @media) which would go
through CSSGroupingRule::insertRule().
We already have a mechanism to deal with any rule mutation
(RuleMutationScope),
let's use it to clear hasNestingRulesCache.
* Source/WebCore/css/CSSStyleRule.cpp:
(WebCore::CSSStyleRule::insertRule):
* Source/WebCore/css/CSSStyleSheet.cpp:
(WebCore::CSSStyleSheet::RuleMutationScope::~RuleMutationScope):
Canonical link: https://commits.webkit.org/293824@main
Commit: a18a39af0bdd5977819f9d3db711eb031ab3920e
https://github.com/WebKit/WebKit/commit/a18a39af0bdd5977819f9d3db711eb031ab3920e
Author: Mohsin Qureshi <mohs...@apple.com>
Date: 2025-04-18 (Fri, 18 Apr 2025)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7621.2.5.10.3
Canonical link: https://commits.webkit.org/289651.440@safari-7621.2.5.10-branch
Commit: 360b008dd71e25d3c7c9e29433fff6eddd922742
https://github.com/WebKit/WebKit/commit/360b008dd71e25d3c7c9e29433fff6eddd922742
Author: Daniel Liu <danl...@umich.edu>
Date: 2025-04-18 (Fri, 18 Apr 2025)
Changed paths:
A JSTests/wasm/stress/initialize-100k-functions.js
A JSTests/wasm/stress/initialize-100k-functions.wasm
M Source/JavaScriptCore/wasm/WasmFunctionCodeBlockGenerator.h
M Source/JavaScriptCore/wasm/WasmFunctionIPIntMetadataGenerator.h
M Source/JavaScriptCore/wasm/WasmIPIntGenerator.cpp
M Source/JavaScriptCore/wasm/WasmLLIntGenerator.cpp
Log Message:
-----------
Cherry-pick 16455b07fc9f. rdar://149554265
Cherry-pick 2faf0a6395f4. rdar://149554409
Clean up dead callee BitVector in LLInt/IPInt generators
https://bugs.webkit.org/show_bug.cgi?id=291699
rdar://149052721
Reviewed by Yijia Huang.
Previously, we used this BitVector to track external functions, but now
it is no
longer used by the code. We can remove this unnecessary allocation.
* JSTests/wasm/stress/initialize-100k-functions.js: Added.
(async main):
* JSTests/wasm/stress/initialize-100k-functions.wasm: Added.
* Source/JavaScriptCore/wasm/WasmFunctionCodeBlockGenerator.h:
(JSC::Wasm::FunctionCodeBlockGenerator::tailCallSuccessors const):
(JSC::Wasm::FunctionCodeBlockGenerator::takeCallees): Deleted.
* Source/JavaScriptCore/wasm/WasmFunctionIPIntMetadataGenerator.h:
(JSC::Wasm::FunctionIPIntMetadataGenerator::takeCallees): Deleted.
* Source/JavaScriptCore/wasm/WasmIPIntGenerator.cpp:
(JSC::Wasm::IPIntGenerator::IPIntGenerator):
(JSC::Wasm::IPIntGenerator::addCall):
* Source/JavaScriptCore/wasm/WasmLLIntGenerator.cpp:
(JSC::Wasm::LLIntGenerator::LLIntGenerator):
(JSC::Wasm::LLIntGenerator::addCall):
Canonical link: https://commits.webkit.org/293831@main
Commit: 98f31781f76944687f355f2a565b1af5350afe9a
https://github.com/WebKit/WebKit/commit/98f31781f76944687f355f2a565b1af5350afe9a
Author: Elijah Sawyers <esawy...@apple.com>
Date: 2025-04-18 (Fri, 18 Apr 2025)
Changed paths:
M
Source/WebKit/UIProcess/Extensions/Cocoa/API/WebExtensionContextAPIPermissionsCocoa.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebExtensionAPIPermissions.mm
Log Message:
-----------
Cherry-pick 0ea6caec83cb. rdar://149249321
permissions.getAll() is wrong if all hosts and URLs access was granted with
implicit request
https://bugs.webkit.org/show_bug.cgi?id=291757
rdar://149249321
Reviewed by Timothy Hatcher.
Fix a bug where permissions.getAll() doesn't return the all hosts and URLs
match
pattern if access was granted through an implicit request.
To fix this, if none of the match patterns in the manifest match all hosts
and
URLs, but access has been granted, return the match pattern.
Wrote a new test to validate the fix.
*
Source/WebKit/UIProcess/Extensions/Cocoa/API/WebExtensionContextAPIPermissionsCocoa.mm:
(WebKit::WebExtensionContext::permissionsGetAll):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebExtensionAPIPermissions.mm:
(TestWebKitAPI::TEST(WKWebExtensionAPIPermissions,
ImplicitAllHostsAndURLsPermissions)):
Canonical link: https://commits.webkit.org/293872@main
Commit: 4f4f4d8c66465f0485e294bae81a3d3a7096ded0
https://github.com/WebKit/WebKit/commit/4f4f4d8c66465f0485e294bae81a3d3a7096ded0
Author: Marcus Plutowski <marcus_plutow...@apple.com>
Date: 2025-04-21 (Mon, 21 Apr 2025)
Changed paths:
M Source/JavaScriptCore/runtime/OptionsList.h
Log Message:
-----------
[JSC] Disable DFG loop unrolling
https://bugs.webkit.org/show_bug.cgi?id=291852
rdar://147263376
Reviewed by Yijia Huang
This is known to cause compiler crashes; while a fix is in the pipeline,
we should disable it to prevent issues downstream.
* Source/JavaScriptCore/runtime/OptionsList.h:
Canonical link: https://commits.webkit.org/289651.443@safari-7621.2.5.10-branch
Commit: 259e3b9ff0adf56f281000e38d559e5d102f30a8
https://github.com/WebKit/WebKit/commit/259e3b9ff0adf56f281000e38d559e5d102f30a8
Author: Dan Robson <dtr_bugzi...@apple.com>
Date: 2025-04-21 (Mon, 21 Apr 2025)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7621.2.5.10.4
Canonical link: https://commits.webkit.org/289651.444@safari-7621.2.5.10-branch
Commit: e6e4c02585b10dd177e581188a84563f3c68e687
https://github.com/WebKit/WebKit/commit/e6e4c02585b10dd177e581188a84563f3c68e687
Author: Ryosuke Niwa <rn...@webkit.org>
Date: 2025-04-22 (Tue, 22 Apr 2025)
Changed paths:
M Source/WebCore/platform/network/cf/DNSResolveQueueCFNet.cpp
Log Message:
-----------
Cherry-pick 59247a7628dd. rdar://149710049
Crash in TimerBase::stopSlowCase() via
DNSResolveQueueCFNet::performDNSLookup
https://bugs.webkit.org/show_bug.cgi?id=291212
Reviewed by Chris Dumez.
The crash appears to be caused by DNSResolveQueueCFNet::performDNSLookup
updating WebCore timer
without grabbing WebThread lock. Speculatively fixed the crash by grabbing
WebThread lock.
* Source/WebCore/platform/network/cf/DNSResolveQueueCFNet.cpp:
(WebCore::DNSResolveQueueCFNet::performDNSLookup):
Canonical link: https://commits.webkit.org/293419@main
Canonical link: https://commits.webkit.org/289651.445@safari-7621.2.5.10-branch
Commit: bc6722fb83f6c32c03c2f9f936e0e7b60fe740e7
https://github.com/WebKit/WebKit/commit/bc6722fb83f6c32c03c2f9f936e0e7b60fe740e7
Author: Dan Robson <dtr_bugzi...@apple.com>
Date: 2025-04-22 (Tue, 22 Apr 2025)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7621.2.5.10.5
Canonical link: https://commits.webkit.org/289651.446@safari-7621.2.5.10-branch
Commit: b6e5e797e866e18548874342fd48cf74479adc85
https://github.com/WebKit/WebKit/commit/b6e5e797e866e18548874342fd48cf74479adc85
Author: Dan Robson <dtr_bugzi...@apple.com>
Date: 2025-04-24 (Thu, 24 Apr 2025)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7621.2.5.10.6
Canonical link: https://commits.webkit.org/289651.447@safari-7621.2.5.10-branch
Commit: 7f85641cb0abc4f95a203f29aed1992ceada7b5b
https://github.com/WebKit/WebKit/commit/7f85641cb0abc4f95a203f29aed1992ceada7b5b
Author: Dan Robson <dtr_bugzi...@apple.com>
Date: 2025-04-25 (Fri, 25 Apr 2025)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7621.2.5.10.7
Canonical link: https://commits.webkit.org/289651.448@safari-7621.2.5.10-branch
Commit: f1fba063ab6474a6d3076e8f5d3caadf2d953473
https://github.com/WebKit/WebKit/commit/f1fba063ab6474a6d3076e8f5d3caadf2d953473
Author: Alex Christensen <achristen...@apple.com>
Date: 2025-04-25 (Fri, 25 Apr 2025)
Changed paths:
M Source/WTF/wtf/cocoa/RuntimeApplicationChecksCocoa.h
M Source/WTF/wtf/cocoa/RuntimeApplicationChecksCocoa.mm
M Source/WTF/wtf/spi/darwin/dyldSPI.h
M Source/WebKit/UIProcess/WebPageProxy.cpp
Log Message:
-----------
Cherry-pick 9fa51266df3a. rdar://149887382
Add linked-on-or-after check for WKNavigationAction.sourceFrame being never
null
rdar://149887382
Reviewed by Wenson Hsieh.
rdar://144600565 changed the nullness of WKNavigationAction.sourceFrame
to make it never non-null as it is annotated in the header. This was
a change to become more correct, but it was also a change that broke
bincompat with a few third party apps. This restores existing behavior
until the apps update. I manually verified this fixes the app in the radar.
* Source/WTF/wtf/cocoa/RuntimeApplicationChecksCocoa.h:
* Source/WTF/wtf/cocoa/RuntimeApplicationChecksCocoa.mm:
(WTF::computeSDKAlignedBehaviors):
* Source/WTF/wtf/spi/darwin/dyldSPI.h:
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::decidePolicyForNavigationAction):
Canonical link: https://commits.webkit.org/289651.461@safari-7621-branch
Canonical link: https://commits.webkit.org/289651.449@safari-7621.2.5.10-branch
Commit: e4528821693f02b028300b45cbaa67623bbc708b
https://github.com/WebKit/WebKit/commit/e4528821693f02b028300b45cbaa67623bbc708b
Author: Dan Robson <dtr_bugzi...@apple.com>
Date: 2025-04-29 (Tue, 29 Apr 2025)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7621.2.5.10.8
Canonical link: https://commits.webkit.org/289651.450@safari-7621.2.5.10-branch
Compare: https://github.com/WebKit/WebKit/compare/3f32080739f0%5E...e4528821693f
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
