Branch: refs/heads/safari-7621.2.5.14-branch
Home: https://github.com/WebKit/WebKit
Commit: 9c6eb843e4f9281c994803a7c2faadfe62147e0d
https://github.com/WebKit/WebKit/commit/9c6eb843e4f9281c994803a7c2faadfe62147e0d
Author: Dan Robson <[email protected]>
Date: 2025-04-15 (Tue, 15 Apr 2025)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7621.2.5.14.1
Canonical link: https://commits.webkit.org/[email protected]
Commit: 825b5bcc2a282aca5c8b7e643ec27494943930ad
https://github.com/WebKit/WebKit/commit/825b5bcc2a282aca5c8b7e643ec27494943930ad
Author: Razvan Caliman <[email protected]>
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/[email protected]
Commit: 70c0156f38130d4e73a5bd2dbd99aa36af0b9d2a
https://github.com/WebKit/WebKit/commit/70c0156f38130d4e73a5bd2dbd99aa36af0b9d2a
Author: Daniel Liu <[email protected]>
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/[email protected]
Commit: 763fe29d61347d304fa77c3f216a207a7b5c7bdd
https://github.com/WebKit/WebKit/commit/763fe29d61347d304fa77c3f216a207a7b5c7bdd
Author: Rob Buis <[email protected]>
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 [email protected] (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/[email protected]
Canonical link: https://commits.webkit.org/289651.427@safari-7621-branch
Canonical link: https://commits.webkit.org/[email protected]
Commit: 22191f416879d34342932f75defb1a535e35370c
https://github.com/WebKit/WebKit/commit/22191f416879d34342932f75defb1a535e35370c
Author: Daniel Liu <[email protected]>
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/[email protected]
Commit: 61619f29a03016b0e4751b850fa65e50d8446d2a
https://github.com/WebKit/WebKit/commit/61619f29a03016b0e4751b850fa65e50d8446d2a
Author: Brent Fulgham <[email protected]>
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/[email protected]
Commit: dda7f49c83ce703e36c2ea7c116d01bb21aa8428
https://github.com/WebKit/WebKit/commit/dda7f49c83ce703e36c2ea7c116d01bb21aa8428
Author: Dan Robson <[email protected]>
Date: 2025-04-17 (Thu, 17 Apr 2025)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7621.2.5.14.2
Canonical link: https://commits.webkit.org/[email protected]
Commit: de41f8e0707e0fcfcd697bf8e876e6582dbbdb60
https://github.com/WebKit/WebKit/commit/de41f8e0707e0fcfcd697bf8e876e6582dbbdb60
Author: Jean-Yves Avenard <[email protected]>
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/[email protected]
Commit: 6a092c7da15bf71ffa357b6efa1b694c8a5e84d2
https://github.com/WebKit/WebKit/commit/6a092c7da15bf71ffa357b6efa1b694c8a5e84d2
Author: Said Abou-Hallawa <[email protected]>
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/[email protected]
Commit: 56d648455f6d190cba9c1723501b7e4823662a34
https://github.com/WebKit/WebKit/commit/56d648455f6d190cba9c1723501b7e4823662a34
Author: Sihui Liu <[email protected]>
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/[email protected]
Commit: d8111046cd3eeeaf78c5a4ad95dee82d3bfd6f6e
https://github.com/WebKit/WebKit/commit/d8111046cd3eeeaf78c5a4ad95dee82d3bfd6f6e
Author: Kiet Ho <[email protected]>
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/[email protected]
Commit: 6dc900c9bc0d3979b2e57ea6b7873a4582ccb5ed
https://github.com/WebKit/WebKit/commit/6dc900c9bc0d3979b2e57ea6b7873a4582ccb5ed
Author: Matthieu Dubet <[email protected]>
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: e1e412315c97d2e0408a64f3fbd357ad752bb3de
https://github.com/WebKit/WebKit/commit/e1e412315c97d2e0408a64f3fbd357ad752bb3de
Author: Mohsin Qureshi <[email protected]>
Date: 2025-04-18 (Fri, 18 Apr 2025)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7621.2.5.14.3
Canonical link: https://commits.webkit.org/[email protected]
Commit: 39c51797e12afe31e8eba14a05376e4458984458
https://github.com/WebKit/WebKit/commit/39c51797e12afe31e8eba14a05376e4458984458
Author: Daniel Liu <[email protected]>
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: f65acbe5db5fe640db9749f3da4e45de4cef2111
https://github.com/WebKit/WebKit/commit/f65acbe5db5fe640db9749f3da4e45de4cef2111
Author: Elijah Sawyers <[email protected]>
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
Canonical link: https://commits.webkit.org/[email protected]
Commit: 0bc81bd401ff6a5490a3676df29417b1d9bea56d
https://github.com/WebKit/WebKit/commit/0bc81bd401ff6a5490a3676df29417b1d9bea56d
Author: Marcus Plutowski <[email protected]>
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/[email protected]
Commit: f2fabfea593f8ed02977c7b064e95c18cbfe95d3
https://github.com/WebKit/WebKit/commit/f2fabfea593f8ed02977c7b064e95c18cbfe95d3
Author: Dan Robson <[email protected]>
Date: 2025-04-21 (Mon, 21 Apr 2025)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7621.2.5.14.4
Canonical link: https://commits.webkit.org/[email protected]
Commit: d0417c5598954a71efcc9d4cb0a46f87ba282567
https://github.com/WebKit/WebKit/commit/d0417c5598954a71efcc9d4cb0a46f87ba282567
Author: Dan Robson <[email protected]>
Date: 2025-04-22 (Tue, 22 Apr 2025)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7621.2.5.14.5
Canonical link: https://commits.webkit.org/[email protected]
Commit: 1d6d395ec9cd38887152f7a9d6be5f7c36e2be17
https://github.com/WebKit/WebKit/commit/1d6d395ec9cd38887152f7a9d6be5f7c36e2be17
Author: Ryosuke Niwa <[email protected]>
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/[email protected]
Commit: a184c75bed0786ca7b57a035902ea0e7c92526c4
https://github.com/WebKit/WebKit/commit/a184c75bed0786ca7b57a035902ea0e7c92526c4
Author: Dan Robson <[email protected]>
Date: 2025-04-24 (Thu, 24 Apr 2025)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7621.2.5.14.6
Canonical link: https://commits.webkit.org/[email protected]
Commit: ed2588387df8a2c8291b8312b54c301147a48bf4
https://github.com/WebKit/WebKit/commit/ed2588387df8a2c8291b8312b54c301147a48bf4
Author: Dan Robson <[email protected]>
Date: 2025-04-29 (Tue, 29 Apr 2025)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7621.2.5.14.7
Canonical link: https://commits.webkit.org/[email protected]
Compare: https://github.com/WebKit/WebKit/compare/9c6eb843e4f9%5E...ed2588387df8
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
