Branch: refs/heads/safari-7621.2.5.12-branch
Home: https://github.com/WebKit/WebKit
Commit: e39cb5e3a805deb0c08f03f2f85db0092edd3aba
https://github.com/WebKit/WebKit/commit/e39cb5e3a805deb0c08f03f2f85db0092edd3aba
Author: Mohsin Qureshi <[email protected]>
Date: 2025-04-15 (Tue, 15 Apr 2025)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7621.2.5.12.1
Canonical link: https://commits.webkit.org/[email protected]
Commit: dff95e6056536b9599e90d585d4c17812a6007dc
https://github.com/WebKit/WebKit/commit/dff95e6056536b9599e90d585d4c17812a6007dc
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: 5ef5589f62f11605a0d9fc509b3d53053af34a5d
https://github.com/WebKit/WebKit/commit/5ef5589f62f11605a0d9fc509b3d53053af34a5d
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: 8ab2a94d418d1a219f7cf84cfe8d7c929bea038e
https://github.com/WebKit/WebKit/commit/8ab2a94d418d1a219f7cf84cfe8d7c929bea038e
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: ea091a4d8351bbabfad51078d66d9ec0bec97e63
https://github.com/WebKit/WebKit/commit/ea091a4d8351bbabfad51078d66d9ec0bec97e63
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: 194fa1dbf5d9d5f976dfb7c708e67b878313e53b
https://github.com/WebKit/WebKit/commit/194fa1dbf5d9d5f976dfb7c708e67b878313e53b
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: 5b754bcf6c52ed5415ae524e8629c42248ef231e
https://github.com/WebKit/WebKit/commit/5b754bcf6c52ed5415ae524e8629c42248ef231e
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.12.2
Canonical link: https://commits.webkit.org/[email protected]
Commit: 6dfdd1be16e2914b4207a0c5faab6c9eea4e354b
https://github.com/WebKit/WebKit/commit/6dfdd1be16e2914b4207a0c5faab6c9eea4e354b
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: fe13e3d49b1d1f9837391733d57381b82da14784
https://github.com/WebKit/WebKit/commit/fe13e3d49b1d1f9837391733d57381b82da14784
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: 71e3f381f9264d522ae958e14f5dd9d67d342e3c
https://github.com/WebKit/WebKit/commit/71e3f381f9264d522ae958e14f5dd9d67d342e3c
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: e11271c7fae2452fe28e8ae510f0e441e968b480
https://github.com/WebKit/WebKit/commit/e11271c7fae2452fe28e8ae510f0e441e968b480
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]
Compare: https://github.com/WebKit/WebKit/compare/e39cb5e3a805%5E...e11271c7fae2
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
