[webkit-changes] [WebKit/WebKit] 4222b8: Versioning.
Wenson Hsieh
noreply at github.com
Tue Jan 28 11:22:50 PST 2025
Branch: refs/heads/safari-7620-branch
Home: https://github.com/WebKit/WebKit
Commit: 4222b87630007e50bbfbd981afe0ddf0ffdc0652
https://github.com/WebKit/WebKit/commit/4222b87630007e50bbfbd981afe0ddf0ffdc0652
Author: Dan Robson <dtr_bugzilla at apple.com>
Date: 2024-11-05 (Tue, 05 Nov 2024)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7620.2.1
Canonical link: https://commits.webkit.org/283286.427@safari-7620-branch
Commit: 1d762a3842ad7644b3578b058f2605bc0622b49e
https://github.com/WebKit/WebKit/commit/1d762a3842ad7644b3578b058f2605bc0622b49e
Author: Dan Hecht <dan.hecht at apple.com>
Date: 2024-11-05 (Tue, 05 Nov 2024)
Changed paths:
A JSTests/wasm/stress/wasm-type-information-lifetimes.js
M Source/JavaScriptCore/wasm/WasmTypeDefinition.cpp
M Source/JavaScriptCore/wasm/WasmTypeDefinition.h
Log Message:
-----------
Cherry-pick 36445525ff26. rdar://139288382
[JSC] Fix Wasm::TypeInformation::tryCleanup() inconsistencies for Wasm GC types
https://bugs.webkit.org/show_bug.cgi?id=282538
rdar://137225000
Reviewed by Yusuke Suzuki and Mark Lam.
There are two scenarios that can lead to inconstancies concerning
the liveness of Wasm::TypeInformation objects.
1. Races between TypeDefinition::deref() and TypeInformation::tryCleanup():
Suppose after the code to remove entries from m_unrollingCache or m_rttMap, a
another thread calls TypeDefinition::deref() and the ref count becomes 1.
Then, the final statement in tryCleanup() will remove the TypeDefinition
from m_typeSet, yet its pointer (cast to a TypeIndex) can still appear as a
key in m_unrollingCache and/or m_rttMap. Later, if that memory is reallocated
to another TypeDefinition, we can use that same pointer value as the key into
those maps and then chase stale unrolled TypeDefinitions or RTTs.
2. Some TypeDefinition types maintain reference counts to their dependencies.
The signature->cleanup() call takes care of deref() those counts (this is all
done manually due to the use of TypeIndex as the way to store references).
If signature->cleanup() causes a dependency to reach refCount()==1 and that
TypeInformation happens to appear later in the m_typeSet table traversal, then
again we can end up with stale keys in m_unrollingCache and m_rttMap.
Fix both of these scenarios by ensuring that removal from the three maps
occur together. Note that since we're holding the TypeInformation lock, no new
references can be taken when the ref count is 1 during this critical section.
* JSTests/wasm/stress/wasm-type-information-lifetimes.js: Added.
* Source/JavaScriptCore/wasm/WasmTypeDefinition.cpp:
(JSC::Wasm::TypeDefinition::cleanup):
(JSC::Wasm::Subtype::cleanup):
(JSC::Wasm::Projection::cleanup):
(JSC::Wasm::RecursionGroup::cleanup):
(JSC::Wasm::TypeInformation::tryCleanup):
* Source/JavaScriptCore/wasm/WasmTypeDefinition.h:
Canonical link: https://commits.webkit.org/286124@main
Canonical link: https://commits.webkit.org/283286.428@safari-7620-branch
Commit: 65740a117ad0aa9b069a2de98a7df13eee8d9dd3
https://github.com/WebKit/WebKit/commit/65740a117ad0aa9b069a2de98a7df13eee8d9dd3
Author: Andy Estes <aestes at apple.com>
Date: 2024-11-05 (Tue, 05 Nov 2024)
Changed paths:
M Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml
Log Message:
-----------
Cherry-pick 6a592580f700. rdar://139287681
[visionOS] Stop using AVCaptureDeviceRotationCoordinator
https://bugs.webkit.org/show_bug.cgi?id=282449
rdar://139027417
Reviewed by Eric Carlson and Youenn Fablet.
Use of AVCaptureDeviceRotationCoordinator results in camera capture being unexpectedly rotated by
90 degrees on Apple Vision Pro. Stopped using AVCaptureDeviceRotationCoordinator for now on
visionOS and reverted to the previous correct behavior.
* Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml:
Canonical link: https://commits.webkit.org/286101@main
Canonical link: https://commits.webkit.org/283286.429@safari-7620-branch
Commit: 4be531f8379d742313815fe0760f0d40616caec9
https://github.com/WebKit/WebKit/commit/4be531f8379d742313815fe0760f0d40616caec9
Author: Nikolaos Mouchtaris <nmouchtaris at apple.com>
Date: 2024-11-05 (Tue, 05 Nov 2024)
Changed paths:
A LayoutTests/fast/scrolling/mac/scrollbars/scrollbar-width-paint-001-expected.html
A LayoutTests/fast/scrolling/mac/scrollbars/scrollbar-width-paint-001.html
M LayoutTests/platform/mac-wk2/TestExpectations
M Source/WebCore/page/scrolling/mac/ScrollerMac.mm
Log Message:
-----------
Cherry-pick 191811467c43. rdar://139287706
Dynamically changing scrollbar-width causes horizontal scrollbars to be painted strangely
https://bugs.webkit.org/show_bug.cgi?id=282520
rdar://139172581
Reviewed by Simon Fraser.
When changing scrollbar width dynamically between auto and thin, horizontal scrollbars would
occasionally be painted with the track and thumb in the wrong location. This appears to be the
result of an AppKit bug around calling scrollerImpWithStyle with replacingScrollerImp being non
null. What would happen is when updating the double value and presentation value, they wouldn't update
the new scroller imp's layer geometry because of checks in the AppKit code that would ensure that
the provided values are different than the current values of the scroller imp (which presumably were
carried over from the previous scroller imp). This can be worked around by simply not providing a previous
scroller imp, and ensuring we update the new scroller imp with the appropriate data.
* LayoutTests/fast/scrolling/mac/scrollbars/scrollbar-width-paint-001-expected.html: Added.
* LayoutTests/fast/scrolling/mac/scrollbars/scrollbar-width-paint-001.html: Added.
* Source/WebCore/page/scrolling/mac/ScrollerMac.mm:
(WebCore::ScrollerMac::updateScrollbarStyle):
Canonical link: https://commits.webkit.org/286112@main
Canonical link: https://commits.webkit.org/283286.430@safari-7620-branch
Commit: ddea404156a302d5c6b3b6f28ed84b3b4dfff898
https://github.com/WebKit/WebKit/commit/ddea404156a302d5c6b3b6f28ed84b3b4dfff898
Author: Eric Carlson <eric.carlson at apple.com>
Date: 2024-11-05 (Tue, 05 Nov 2024)
Changed paths:
M Source/WebCore/html/HTMLMediaElement.cpp
M Source/WebCore/html/HTMLMediaElement.h
M Source/WebCore/html/HTMLVideoElement.cpp
M Source/WebCore/html/HTMLVideoElement.h
M Source/WebCore/platform/cocoa/PlaybackSessionModelMediaElement.mm
Log Message:
-----------
Cherry-pick 89d9814e2f11. rdar://139288404
[Cocoa] REGRESSION (283033 at main) Viewer mode doesn't work for video in an iframe
https://bugs.webkit.org/show_bug.cgi?id=282351
rdar://138769971
Reviewed by Andy Estes.
283033 at main changed Viewer mode to use element fullscreen instead of video fullscreen.
Element fullscreen enforces permission policy and the old video fullscreen API does not,
so the change broke Viewer mode for video in an iframe without the "allowfullscreen"
property. Fix this by adding new, internal-only, methods to allow element fullscreen to
ignore fullscreen permission policy.
* Source/WebCore/html/HTMLMediaElement.cpp:
(WebCore::HTMLMediaElement::enterFullscreen): Pass ExemptIFrameAllowFullscreenRequirement to
FullscreenManager::requestFullscreenForElement when m_ignoreFullscreenPermissionsPolicy is true;
* Source/WebCore/html/HTMLMediaElement.h:
(WebCore::HTMLMediaElement::ignoreFullscreenPermissionPolicyOnNextCallToEnterFullscreen):
* Source/WebCore/html/HTMLVideoElement.cpp:
(WebCore::HTMLVideoElement::enterFullscreenIgnoringPermissionsPolicy): Call
ignoreFullscreenPermissionPolicyOnNextCallToEnterFullscreen() before calling webkitEnterFullscreen().
(WebCore::HTMLVideoElement::setPresentationModeIgnoringPermissionsPolicy): Call
ignoreFullscreenPermissionPolicyOnNextCallToEnterFullscreen() before calling setPresentationMode().
* Source/WebCore/html/HTMLVideoElement.h:
* Source/WebCore/platform/cocoa/PlaybackSessionModelMediaElement.mm:
(WebCore::PlaybackSessionModelMediaElement::enterInWindowFullscreen): Call setPresentationModeIgnoringPermissionsPolicy.
(WebCore::PlaybackSessionModelMediaElement::enterFullscreen): Call enterFullscreenIgnoringPermissionsPolicy.
Canonical link: https://commits.webkit.org/285943@main
Canonical link: https://commits.webkit.org/283286.431@safari-7620-branch
Commit: 4b20e20ab3de6944b82acf48df19a84ba95dc83c
https://github.com/WebKit/WebKit/commit/4b20e20ab3de6944b82acf48df19a84ba95dc83c
Author: Keith Miller <keith_miller at apple.com>
Date: 2024-11-05 (Tue, 05 Nov 2024)
Changed paths:
M Source/JavaScriptCore/API/JSManagedValue.mm
M Source/JavaScriptCore/API/glib/JSCClass.cpp
M Source/JavaScriptCore/API/glib/JSCWeakValue.cpp
M Source/JavaScriptCore/heap/WeakSetInlines.h
M Source/JavaScriptCore/inspector/agents/InspectorDebuggerAgent.cpp
M Source/JavaScriptCore/runtime/JSLock.h
M Source/WebCore/bindings/js/JSLazyEventListener.cpp
Log Message:
-----------
Cherry-pick 596c3527f5dd. rdar://139287689
Make [JSManagedValue initWithValue:] more robust against clients using it from non-main threads
https://bugs.webkit.org/show_bug.cgi?id=281648
rdar://138037948
Reviewed by Mark Lam.
[JSManagedValue initWithValue:] does not currently acquire the JS API lock because it expects to
only be called on the JS main thread. However, it's easy for clients to make mistakes can call
it from different threads. We should make [JSManagedValue initWithValue:] more robust by simply
making it acquire the JS API lock for its VM.
Also change [JSManagedValue value:] to not acquire the JS API lock twice. It was first acquiring
the lock with a WTF::Locker, and subsequently with a JSC::JSLockHolder. The only added value of
the JSC::JSLockHolder is that it refs the VM using a RefPtr. So, instead of using the
JSC::JSLockHolder, we can just use a RefPtr to store the VM instead of the raw VM* it was using
before. With that, the use of the JSC::JSLockHolder becomes completely redundant.
This issue is caught by existing tests now that WeakSet::allocate asserts currentThreadIsHoldingAPILock.
* Source/JavaScriptCore/API/JSManagedValue.mm:
(-[JSManagedValue initWithValue:]):
(-[JSManagedValue value]):
* Source/JavaScriptCore/heap/WeakSetInlines.h:
(JSC::WeakSet::allocate):
* Source/JavaScriptCore/runtime/JSLock.h:
Canonical link: https://commits.webkit.org/285771@main
Canonical link: https://commits.webkit.org/283286.432@safari-7620-branch
Commit: d325cbb3e1d2b4531f5fe55eb363ee43722674f2
https://github.com/WebKit/WebKit/commit/d325cbb3e1d2b4531f5fe55eb363ee43722674f2
Author: Andy Estes <aestes at apple.com>
Date: 2024-11-05 (Tue, 05 Nov 2024)
Changed paths:
M Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml
M Source/WebCore/Modules/mediastream/RTCPeerConnection.cpp
M Source/WebCore/Modules/mediastream/VideoTrackGenerator.cpp
M Source/WebCore/dom/Document.cpp
M Source/WebCore/dom/ScriptExecutionContext.cpp
M Source/WebCore/dom/ScriptExecutionContext.h
M Source/WebCore/page/Page.cpp
M Source/WebCore/page/Page.h
M Source/WebKit/GPUProcess/GPUConnectionToWebProcess.cpp
M Source/WebKit/GPUProcess/GPUConnectionToWebProcess.h
M Source/WebKit/GPUProcess/mac/LocalAudioSessionRoutingArbitrator.cpp
M Source/WebKit/GPUProcess/media/RemoteCDMFactoryProxy.cpp
M Source/WebKit/GPUProcess/media/RemoteLegacyCDMFactoryProxy.cpp
M Source/WebKit/GPUProcess/media/RemoteMediaPlayerManagerProxy.cpp
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.h
M Source/WebKit/NetworkProcess/NetworkResourceLoader.cpp
M Source/WebKit/UIProcess/API/Cocoa/WKWebViewPrivateForTesting.h
M Source/WebKit/UIProcess/API/Cocoa/WKWebViewTesting.mm
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.h
M Source/WebKit/UIProcess/WebPageProxyInternals.h
M Source/WebKit/UIProcess/WebProcessProxy.cpp
M Source/WebKit/UIProcess/WebProcessProxy.h
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
A Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebViewLogging.mm
Log Message:
-----------
Cherry-pick 84d9882e1577. rdar://139285740
Enable always-on logging in ephemeral sessions when allowed by preference
https://bugs.webkit.org/show_bug.cgi?id=282251
rdar://138850759
Reviewed by Eric Carlson.
Teach WebKit to enable always-on logging in web views that enable the
AllowPrivacySensitiveOperationsInNonPersistentDataStores preference,
even if that web view is in an ephemeral session.
Added API tests.
* Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml:
* Source/WebCore/Modules/mediastream/RTCPeerConnection.cpp:
(WebCore::RTCPeerConnection::create):
* Source/WebCore/Modules/mediastream/VideoTrackGenerator.cpp:
(WebCore::VideoTrackGenerator::create):
* Source/WebCore/dom/Document.cpp:
(WebCore::Document::configureSharedLogger):
(WebCore::Document::privateBrowsingStateDidChange):
(WebCore::Document::logger):
(WebCore::Document::didLogMessage):
* Source/WebCore/dom/ScriptExecutionContext.cpp:
(WebCore::ScriptExecutionContext::isAlwaysOnLoggingAllowed const):
* Source/WebCore/dom/ScriptExecutionContext.h:
* Source/WebCore/page/Page.cpp:
(WebCore::Page::configureLoggingChannel):
(WebCore::Page::isAlwaysOnLoggingAllowed const):
* Source/WebCore/page/Page.h:
* Source/WebKit/GPUProcess/GPUConnectionToWebProcess.cpp:
(WebKit::GPUConnectionToWebProcess::logger):
(WebKit::GPUConnectionToWebProcess::isAlwaysOnLoggingAllowed const):
* Source/WebKit/GPUProcess/GPUConnectionToWebProcess.h:
* Source/WebKit/GPUProcess/mac/LocalAudioSessionRoutingArbitrator.cpp:
(WebKit::LocalAudioSessionRoutingArbitrator::canLog const):
* Source/WebKit/GPUProcess/media/RemoteCDMFactoryProxy.cpp:
(WebKit::RemoteCDMFactoryProxy::logger const):
* Source/WebKit/GPUProcess/media/RemoteLegacyCDMFactoryProxy.cpp:
(WebKit::RemoteLegacyCDMFactoryProxy::logger const):
* Source/WebKit/GPUProcess/media/RemoteMediaPlayerManagerProxy.cpp:
(WebKit::RemoteMediaPlayerManagerProxy::logger):
* Source/WebKit/ModelProcess/ModelConnectionToWebProcess.cpp:
(WebKit::ModelConnectionToWebProcess::logger):
(WebKit::ModelConnectionToWebProcess::isAlwaysOnLoggingAllowed const):
* Source/WebKit/ModelProcess/ModelConnectionToWebProcess.h:
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:
(WebKit::NetworkConnectionToWebProcess::isAlwaysOnLoggingAllowed const):
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.h:
* Source/WebKit/NetworkProcess/NetworkResourceLoader.cpp:
(WebKit::logBlockedCookieInformation):
(WebKit::logCookieInformationInternal):
* Source/WebKit/UIProcess/API/Cocoa/WKWebViewPrivateForTesting.h:
* Source/WebKit/UIProcess/API/Cocoa/WKWebViewTesting.mm:
(-[WKWebView _isLoggerEnabledForTesting]):
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::swapToProvisionalPage):
(WebKit::WebPageProxy::decidePolicyForNavigationAction):
(WebKit::WebPageProxy::effectiveDiagnosticLoggingClient):
(WebKit::WebPageProxy::logger):
(WebKit::WebPageProxy::isAlwaysOnLoggingAllowed const):
* Source/WebKit/UIProcess/WebPageProxy.h:
* Source/WebKit/UIProcess/WebPageProxyInternals.h:
* Source/WebKit/UIProcess/WebProcessProxy.cpp:
(WebKit::WebProcessProxy::setWebsiteDataStore):
(WebKit::WebProcessProxy::addExistingWebPage):
(WebKit::WebProcessProxy::removeWebPage):
(WebKit::WebProcessProxy::logger):
(WebKit::WebProcessProxy::isAlwaysOnLoggingAllowed const):
* Source/WebKit/UIProcess/WebProcessProxy.h:
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::logger const):
(WebKit::WebPage::isAlwaysOnLoggingAllowed const):
* Source/WebKit/WebProcess/WebPage/WebPage.h:
* Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebViewLogging.mm: Added.
(TEST(WKWebView, LoggingEnabledByDefault)):
(TEST(WKWebView, LoggingDisabledInNonPersistentDataStore)):
(TEST(WKWebView, LoggingEnabledInNonPersistentDataStoreWhenAllowed)):
Canonical link: https://commits.webkit.org/285941@main
Canonical link: https://commits.webkit.org/283286.433@safari-7620-branch
Commit: 632f9326c9cb7225315f6d6d52d77f6b0db8829b
https://github.com/WebKit/WebKit/commit/632f9326c9cb7225315f6d6d52d77f6b0db8829b
Author: Richard Robinson <richard_robinson2 at apple.com>
Date: 2024-11-05 (Tue, 05 Nov 2024)
Changed paths:
M Source/WebCore/page/IntelligenceTextEffectsSupport.cpp
M Source/WebCore/page/IntelligenceTextEffectsSupport.h
M Source/WebCore/page/Page.cpp
M Source/WebCore/page/Page.h
M Source/WebCore/page/writing-tools/WritingToolsController.h
M Source/WebCore/page/writing-tools/WritingToolsController.mm
M Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm
M Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h
M Source/WebKit/UIProcess/Cocoa/WebPageProxyCocoa.mm
M Source/WebKit/UIProcess/WebPageProxy.h
M Source/WebKit/WebKitSwift/WritingTools/PlatformIntelligenceTextEffectView.swift
M Source/WebKit/WebKitSwift/WritingTools/WKIntelligenceTextEffectCoordinator.h
M Source/WebKit/WebKitSwift/WritingTools/WKIntelligenceTextEffectCoordinator.swift
M Source/WebKit/WebProcess/WebPage/Cocoa/WebPageCocoa.mm
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKit/WebProcess/WebPage/WebPage.messages.in
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WritingTools.mm
Log Message:
-----------
Cherry-pick fc0f18354ef6. rdar://139310090
[Intelligence Effects] Support adding intelligence effects to Writing Tools Proofreading operations
https://bugs.webkit.org/show_bug.cgi?id=282161
rdar://138751347
Reviewed by Aditya Keerthi.
When performing Proofreading, the text will now animate using the intelligence text effects.
The implementation details are described throughout the change in comments.
* Source/WebCore/page/IntelligenceTextEffectsSupport.cpp:
(WebCore::IntelligenceTextEffectsSupport::updateTextVisibility):
(WebCore::IntelligenceTextEffectsSupport::decorateWritingToolsTextReplacements):
* Source/WebCore/page/IntelligenceTextEffectsSupport.h:
* Source/WebCore/page/Page.cpp:
(WebCore::Page::proofreadingSessionDidReceiveSuggestions):
(WebCore::Page::updateTextVisibilityForActiveWritingToolsSession):
(WebCore::Page::decorateTextReplacementsForActiveWritingToolsSession):
(WebCore::Page::proofreadingSessionDidCompletePartialReplacement): Deleted.
* Source/WebCore/page/Page.h:
* Source/WebCore/page/writing-tools/WritingToolsController.h:
* Source/WebCore/page/writing-tools/WritingToolsController.mm:
(WebCore::WritingToolsController::didBeginWritingToolsSession):
(WebCore::WritingToolsController::proofreadingSessionDidReceiveSuggestions):
(WebCore::WritingToolsController::proofreadingSessionDidCompletePartialReplacement): Deleted.
* Source/WebKit/UIProcess/API/Cocoa/ObjectiveCBlockConversions.swift:
* Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm:
(-[WKWebView didBeginWritingToolsSession:contexts:]):
(-[WKWebView proofreadingSession:didReceiveSuggestions:processedRange:inContext:finished:]):
(-[WKWebView didEndWritingToolsSession:accepted:]):
(-[WKWebView intelligenceTextEffectCoordinator:updateTextVisibilityForRange:visible:identifier:completion:]):
(-[WKWebView intelligenceTextEffectCoordinator:decorateReplacementsForRange:completion:]):
(-[WKWebView intelligenceTextEffectCoordinator:updateTextVisibilityForRange:visible:completion:]): Deleted.
* Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h:
* Source/WebKit/UIProcess/Cocoa/WebPageProxyCocoa.mm:
(WebKit::WebPageProxy::proofreadingSessionDidReceiveSuggestions):
(WebKit::WebPageProxy::updateTextVisibilityForActiveWritingToolsSession):
(WebKit::WebPageProxy::decorateTextReplacementsForActiveWritingToolsSession):
(WebKit::WebPageProxy::proofreadingSessionDidCompletePartialReplacement): Deleted.
* Source/WebKit/UIProcess/WebPageProxy.h:
* Source/WebKit/WebKitSwift/WritingTools/PlatformIntelligenceTextEffectView.swift:
(PlatformIntelligenceTextEffectViewSource.replacementEffectDidComplete(_:)):
(UITextEffectViewSourceAdapter.targetedPreview(for:)):
(UITextEffectViewSourceAdapter.updateTextChunkVisibilityForAnimation(_:visible:)):
(UIReplacementTextEffectDelegateAdapter.replacementEffectDidComplete(_:)):
(UIReplacementTextEffectDelegateAdapter.performReplacementAndGeneratePreview(for:effect:animation:)):
(WTTextPreviewAsyncSourceAdapter.textPreviews(for:)):
(WTTextPreviewAsyncSourceAdapter.updateIsTextVisible(_:for:)):
(PlatformIntelligenceTextEffectView.wrappedEffectIDToPlatformEffects):
(PlatformIntelligenceTextEffectView.frame):
(PlatformIntelligenceTextEffectView.removeEffect(_:)):
(PlatformIntelligenceTextEffectView.removeAllEffects):
* Source/WebKit/WebKitSwift/WritingTools/WKIntelligenceTextEffectCoordinator.h:
* Source/WebKit/WebKitSwift/WritingTools/WKIntelligenceTextEffectCoordinator.swift:
(effectView):
(contextRange):
(activePonderingEffect):
(activeReplacementEffect):
(textVisibilityRegionIdentifiers):
(replacementQueue):
(onFlushCompletion):
(characterDelta(forReceivedSuggestions:)):
(startAnimation(for:)):
(requestReplacement(withProcessedRange:characterDelta:operation:)):
(flushReplacements):
(startReplacementAnimation(using:)):
(setupViewIfNeeded):
(destroyViewIfNeeded):
(setActivePonderingEffect(_:)):
(setActiveReplacementEffect(_:)):
(reset):
(WKIntelligenceTextEffectCoordinator.textPreview(for:)):
(WKIntelligenceTextEffectCoordinator.updateTextChunkVisibility(_:visible:force:)):
(WKIntelligenceTextEffectCoordinator.updateTextChunkVisibility(_:visible:)):
(WKIntelligenceTextEffectCoordinator.performReplacementAndGeneratePreview(for:effect:animation:)):
(WKIntelligenceTextEffectCoordinator.replacementEffectWillBegin(_:)):
(WKIntelligenceTextEffectCoordinator.flushRemainingReplacementsIfNeeded):
(WKIntelligenceTextEffectCoordinator.replacementEffectDidComplete(_:)):
(range):
(WKIntelligenceTextEffectCoordinator.hash(into:)):
* Source/WebKit/WebProcess/WebPage/Cocoa/WebPageCocoa.mm:
(WebKit::WebPage::proofreadingSessionDidReceiveSuggestions):
(WebKit::WebPage::updateTextVisibilityForActiveWritingToolsSession):
(WebKit::WebPage::decorateTextReplacementsForActiveWritingToolsSession):
(WebKit::WebPage::proofreadingSessionDidCompletePartialReplacement): Deleted.
* Source/WebKit/WebProcess/WebPage/WebPage.h:
* Source/WebKit/WebProcess/WebPage/WebPage.messages.in:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WritingTools.mm:
(TEST(WritingTools, IntelligenceTextEffectCoordinatorDelegate_UpdateTextVisibilityForRange)):
Canonical link: https://commits.webkit.org/286126@main
Canonical link: https://commits.webkit.org/283286.434@safari-7620-branch
Commit: aa712b5f6334e04a4b9fc88fede7ffa4cf49c313
https://github.com/WebKit/WebKit/commit/aa712b5f6334e04a4b9fc88fede7ffa4cf49c313
Author: Wenson Hsieh <wenson_hsieh at apple.com>
Date: 2024-11-05 (Tue, 05 Nov 2024)
Changed paths:
M Source/WebKit/WebKitSwift/WritingTools/WKIntelligenceTextEffectCoordinator.h
Log Message:
-----------
Cherry-pick edf44684ba38. rdar://139310090
Unreviewed, fix the internal macOS build after 286126 at main
Remove this unnecessary header import.
* Source/WebKit/WebKitSwift/WritingTools/WKIntelligenceTextEffectCoordinator.h:
Canonical link: https://commits.webkit.org/286133@main
Canonical link: https://commits.webkit.org/283286.435@safari-7620-branch
Commit: 86fb7e52ef269450c90ee3985aeb2bb15eb36871
https://github.com/WebKit/WebKit/commit/86fb7e52ef269450c90ee3985aeb2bb15eb36871
Author: Dan Robson <dtr_bugzilla at apple.com>
Date: 2024-11-06 (Wed, 06 Nov 2024)
Changed paths:
M Source/WebKit/WebKitSwift/WritingTools/WKIntelligenceTextEffectCoordinator.h
Log Message:
-----------
Revert edf44684ba38. rdar://139310090
This reverts commit aa712b5f6334e04a4b9fc88fede7ffa4cf49c313.
Canonical link: https://commits.webkit.org/283286.436@safari-7620-branch
Commit: 4d1ef80dcabb31d3aadb78c43f6345a13c9de4db
https://github.com/WebKit/WebKit/commit/4d1ef80dcabb31d3aadb78c43f6345a13c9de4db
Author: Dan Robson <dtr_bugzilla at apple.com>
Date: 2024-11-06 (Wed, 06 Nov 2024)
Changed paths:
M Source/WebCore/page/IntelligenceTextEffectsSupport.cpp
M Source/WebCore/page/IntelligenceTextEffectsSupport.h
M Source/WebCore/page/Page.cpp
M Source/WebCore/page/Page.h
M Source/WebCore/page/writing-tools/WritingToolsController.h
M Source/WebCore/page/writing-tools/WritingToolsController.mm
M Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm
M Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h
M Source/WebKit/UIProcess/Cocoa/WebPageProxyCocoa.mm
M Source/WebKit/UIProcess/WebPageProxy.h
M Source/WebKit/WebKitSwift/WritingTools/PlatformIntelligenceTextEffectView.swift
M Source/WebKit/WebKitSwift/WritingTools/WKIntelligenceTextEffectCoordinator.h
M Source/WebKit/WebKitSwift/WritingTools/WKIntelligenceTextEffectCoordinator.swift
M Source/WebKit/WebProcess/WebPage/Cocoa/WebPageCocoa.mm
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKit/WebProcess/WebPage/WebPage.messages.in
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WritingTools.mm
Log Message:
-----------
Revert fc0f18354ef6. rdar://139310090
This reverts commit 632f9326c9cb7225315f6d6d52d77f6b0db8829b.
Canonical link: https://commits.webkit.org/283286.437@safari-7620-branch
Commit: 299278ffc3f1b906dda7a431dc67ca52f0162f2c
https://github.com/WebKit/WebKit/commit/299278ffc3f1b906dda7a431dc67ca52f0162f2c
Author: Daniel Liu <danlliu at umich.edu>
Date: 2024-11-06 (Wed, 06 Nov 2024)
Changed paths:
A JSTests/stress/string-add-conversion-unused.js
M Source/JavaScriptCore/dfg/DFGBackwardsPropagationPhase.cpp
Log Message:
-----------
DFG ToString should only care about Other uses when it can be Other
https://bugs.webkit.org/show_bug.cgi?id=282661
rdar://138325184
Reviewed by Yusuke Suzuki.
DFG's ToString should only backpropagate a UseAsOther when the use
has the potential to be Other. Otherwise, we end up with a mismatch
in expected value formats.
* Source/JavaScriptCore/dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::propagate):
Canonical link: https://commits.webkit.org/283286.438@safari-7620-branch
Commit: 50266e7fcb9acefd44173622588f0422db82d4d6
https://github.com/WebKit/WebKit/commit/50266e7fcb9acefd44173622588f0422db82d4d6
Author: Jer Noble <jer.noble at apple.com>
Date: 2024-11-06 (Wed, 06 Nov 2024)
Changed paths:
A LayoutTests/http/tests/media/fairplay/legacy-fairplay-mse-muxed-nowait-expected.txt
A LayoutTests/http/tests/media/fairplay/legacy-fairplay-mse-muxed-nowait.html
M LayoutTests/platform/mac/TestExpectations
M Source/WebCore/Modules/encryptedmedia/legacy/WebKitMediaKeySession.cpp
M Source/WebCore/platform/graphics/LegacyCDMSession.h
M Source/WebCore/platform/graphics/avfoundation/objc/CDMSessionAVContentKeySession.h
M Source/WebCore/platform/graphics/avfoundation/objc/CDMSessionMediaSourceAVFObjC.mm
M Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.h
M Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm
M Source/WebCore/platform/graphics/avfoundation/objc/MediaSourcePrivateAVFObjC.h
M Source/WebCore/platform/graphics/avfoundation/objc/MediaSourcePrivateAVFObjC.mm
M Source/WebCore/platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.h
M Source/WebCore/platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.mm
M Source/WebKit/GPUProcess/media/RemoteLegacyCDMFactoryProxy.cpp
M Source/WebKit/GPUProcess/media/RemoteLegacyCDMFactoryProxy.h
M Source/WebKit/GPUProcess/media/RemoteLegacyCDMFactoryProxy.messages.in
M Source/WebKit/GPUProcess/media/RemoteLegacyCDMSessionProxy.cpp
M Source/WebKit/GPUProcess/media/RemoteLegacyCDMSessionProxy.h
M Source/WebKit/WebProcess/GPU/media/RemoteLegacyCDMFactory.cpp
M Source/WebKit/WebProcess/GPU/media/RemoteLegacyCDMSession.cpp
M Source/WebKit/WebProcess/GPU/media/RemoteLegacyCDMSession.h
Log Message:
-----------
Cherry-pick 710c98ac50e2. rdar://139287698
REGRESSION(282990 at main) LegacyEME fails when appending media segment before completing key exchange
https://bugs.webkit.org/show_bug.cgi?id=282252
rdar://138002160
Reviewed by Andy Estes.
When enabling the "modern AVContentKey support" path, we updated the modern EME implementation
but neglected to update the LegacyEME implementation with similar changes. To support the new
AVContentKeySession path, we must _not_ add the AVStreamDataParser to the AVContentKeySession.
Additionally, when keys are added through the LegacyEME path, we must explicitly signal the
SourceBufferPrivate to attempt to enqueue the protected samples for decode and display.
* LayoutTests/http/tests/media/fairplay/legacy-fairplay-mse-muxed-nowait-expected.txt: Added.
* LayoutTests/http/tests/media/fairplay/legacy-fairplay-mse-muxed-nowait.html: Added.
* Source/WebCore/platform/graphics/avfoundation/objc/CDMSessionMediaSourceAVFObjC.h:
* Source/WebCore/platform/graphics/avfoundation/objc/CDMSessionMediaSourceAVFObjC.mm:
(WebCore::CDMSessionMediaSourceAVFObjC::addSourceBuffer):
(WebCore::CDMSessionMediaSourceAVFObjC::removeSourceBuffer):
* Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.h:
* Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm:
(WebCore::MediaPlayerPrivateMediaSourceAVFObjC::keyAdded):
* Source/WebCore/platform/graphics/avfoundation/objc/MediaSourcePrivateAVFObjC.h:
* Source/WebCore/platform/graphics/avfoundation/objc/MediaSourcePrivateAVFObjC.mm:
(WebCore::MediaSourcePrivateAVFObjC::keyAdded):
* Source/WebCore/platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.mm:
(WebCore::SourceBufferPrivateAVFObjC::setCDMSession):
(WebCore::SourceBufferPrivateAVFObjC::attemptToDecrypt):
Canonical link: https://commits.webkit.org/286068@main
Canonical link: https://commits.webkit.org/283286.439@safari-7620-branch
Commit: f636abd1ea0ef49bafbe258b6e978373bee3124a
https://github.com/WebKit/WebKit/commit/f636abd1ea0ef49bafbe258b6e978373bee3124a
Author: Richard Robinson <richard_robinson2 at apple.com>
Date: 2024-11-06 (Wed, 06 Nov 2024)
Changed paths:
M Source/WebCore/page/IntelligenceTextEffectsSupport.cpp
M Source/WebCore/page/IntelligenceTextEffectsSupport.h
M Source/WebCore/page/Page.cpp
M Source/WebCore/page/Page.h
M Source/WebCore/page/writing-tools/WritingToolsController.h
M Source/WebCore/page/writing-tools/WritingToolsController.mm
M Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm
M Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h
M Source/WebKit/UIProcess/Cocoa/WebPageProxyCocoa.mm
M Source/WebKit/UIProcess/WebPageProxy.h
M Source/WebKit/WebKitSwift/WritingTools/PlatformIntelligenceTextEffectView.swift
M Source/WebKit/WebKitSwift/WritingTools/WKIntelligenceTextEffectCoordinator.h
M Source/WebKit/WebKitSwift/WritingTools/WKIntelligenceTextEffectCoordinator.swift
M Source/WebKit/WebProcess/WebPage/Cocoa/WebPageCocoa.mm
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKit/WebProcess/WebPage/WebPage.messages.in
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WritingTools.mm
Log Message:
-----------
Cherry-pick b25f2922fd33. rdar://139310090
Re-land [Intelligence Effects] Support adding intelligence effects to Writing Tools Proofreading operations
https://bugs.webkit.org/show_bug.cgi?id=282620
rdar://139292774
Reviewed by Aditya Keerthi.
Re-land 286126 at main with build fixes to avoid importing WTUI on iOS, and remove an unneeded WKWebView import.
* Source/WebCore/page/IntelligenceTextEffectsSupport.cpp:
(WebCore::IntelligenceTextEffectsSupport::updateTextVisibility):
(WebCore::IntelligenceTextEffectsSupport::textPreviewDataForRange):
(WebCore::IntelligenceTextEffectsSupport::decorateWritingToolsTextReplacements):
* Source/WebCore/page/IntelligenceTextEffectsSupport.h:
* Source/WebCore/page/Page.cpp:
(WebCore::Page::proofreadingSessionDidReceiveSuggestions):
(WebCore::Page::proofreadingSessionDidUpdateStateForSuggestion):
(WebCore::Page::willEndWritingToolsSession):
(WebCore::Page::updateTextVisibilityForActiveWritingToolsSession):
(WebCore::Page::decorateTextReplacementsForActiveWritingToolsSession):
(WebCore::Page::setSelectionForActiveWritingToolsSession):
(WebCore::Page::proofreadingSessionDidCompletePartialReplacement): Deleted.
* Source/WebCore/page/Page.h:
* Source/WebCore/page/writing-tools/WritingToolsController.h:
* Source/WebCore/page/writing-tools/WritingToolsController.mm:
(WebCore::WritingToolsController::didBeginWritingToolsSession):
(WebCore::WritingToolsController::proofreadingSessionDidReceiveSuggestions):
(WebCore::WritingToolsController::willEndWritingToolsSession<WritingTools::Session::Type::Proofreading>):
(WebCore::WritingToolsController::willEndWritingToolsSession<WritingTools::Session::Type::Composition>):
(WebCore::WritingToolsController::willEndWritingToolsSession):
(WebCore::WritingToolsController::didEndWritingToolsSession<WritingTools::Session::Type::Proofreading>):
(WebCore::WritingToolsController::proofreadingSessionDidCompletePartialReplacement): Deleted.
* Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm:
(-[WKWebView didBeginWritingToolsSession:contexts:]):
(-[WKWebView proofreadingSession:didReceiveSuggestions:processedRange:inContext:finished:]):
(-[WKWebView didEndWritingToolsSession:accepted:]):
(-[WKWebView viewForIntelligenceTextEffectCoordinator:]):
(-[WKWebView intelligenceTextEffectCoordinator:updateTextVisibilityForRange:visible:identifier:completion:]):
(-[WKWebView intelligenceTextEffectCoordinator:decorateReplacementsForRange:completion:]):
(-[WKWebView intelligenceTextEffectCoordinator:setSelectionForRange:completion:]):
(-[WKWebView _targetedPreviewForElementWithID:completionHandler:]):
(-[WKWebView intelligenceTextEffectCoordinator:updateTextVisibilityForRange:visible:completion:]): Deleted.
* Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h:
* Source/WebKit/UIProcess/Cocoa/WebPageProxyCocoa.mm:
(WebKit::WebPageProxy::proofreadingSessionDidReceiveSuggestions):
(WebKit::WebPageProxy::proofreadingSessionDidUpdateStateForSuggestion):
(WebKit::WebPageProxy::willEndWritingToolsSession):
(WebKit::WebPageProxy::updateTextVisibilityForActiveWritingToolsSession):
(WebKit::WebPageProxy::decorateTextReplacementsForActiveWritingToolsSession):
(WebKit::WebPageProxy::setSelectionForActiveWritingToolsSession):
(WebKit::WebPageProxy::proofreadingSessionDidCompletePartialReplacement): Deleted.
* Source/WebKit/UIProcess/WebPageProxy.h:
* Source/WebKit/WebKitSwift/WritingTools/PlatformIntelligenceTextEffectView.swift:
(PlatformIntelligenceTextEffectViewSource.replacementEffectDidComplete(_:)):
(UITextEffectViewSourceAdapter.targetedPreview(for:)):
(UITextEffectViewSourceAdapter.updateTextChunkVisibilityForAnimation(_:visible:)):
(UIReplacementTextEffectDelegateAdapter.replacementEffectDidComplete(_:)):
(UIReplacementTextEffectDelegateAdapter.performReplacementAndGeneratePreview(for:effect:animation:)):
(WTTextPreviewAsyncSourceAdapter.textPreviews(for:)):
(WTTextPreviewAsyncSourceAdapter.updateIsTextVisible(_:for:)):
(PlatformIntelligenceTextEffectView.wrappedEffectIDToPlatformEffects):
(PlatformIntelligenceTextEffectView.initializeSubviews):
(PlatformIntelligenceTextEffectView.removeEffect(_:)):
(PlatformIntelligenceTextEffectView.removeAllEffects):
(PlatformIntelligenceTextEffectView.bounds): Deleted.
* Source/WebKit/WebKitSwift/WritingTools/WKIntelligenceTextEffectCoordinator.h:
* Source/WebKit/WebKitSwift/WritingTools/WKIntelligenceTextEffectCoordinator.swift:
(effectView):
(contextRange):
(activePonderingEffect):
(activeReplacementEffect):
(textVisibilityRegionIdentifiers):
(replacementQueue):
(onFlushCompletion):
(characterDelta(forReceivedSuggestions:)):
(startAnimation(for:)):
(requestReplacement(withProcessedRange:finished:characterDelta:operation:)):
(flushReplacements):
(restoreSelection(_:)):
(removeActiveEffects):
(startReplacementAnimation(using:)):
(setupViewIfNeeded):
(destroyViewIfNeeded):
(setActivePonderingEffect(_:)):
(setActiveReplacementEffect(_:)):
(reset):
(WKIntelligenceTextEffectCoordinator.textPreview(for:)):
(WKIntelligenceTextEffectCoordinator.updateTextChunkVisibility(_:visible:force:)):
(WKIntelligenceTextEffectCoordinator.updateTextChunkVisibility(_:visible:)):
(WKIntelligenceTextEffectCoordinator.performReplacementAndGeneratePreview(for:effect:animation:)):
(WKIntelligenceTextEffectCoordinator.replacementEffectWillBegin(_:)):
(WKIntelligenceTextEffectCoordinator.flushRemainingReplacementsIfNeeded):
(WKIntelligenceTextEffectCoordinator.replacementEffectDidComplete(_:)):
(range):
(WKIntelligenceTextEffectCoordinator.hash(into:)):
(async(_:)):
* Source/WebKit/WebProcess/WebPage/Cocoa/WebPageCocoa.mm:
(WebKit::WebPage::proofreadingSessionDidReceiveSuggestions):
(WebKit::WebPage::proofreadingSessionDidUpdateStateForSuggestion):
(WebKit::WebPage::willEndWritingToolsSession):
(WebKit::WebPage::updateTextVisibilityForActiveWritingToolsSession):
(WebKit::WebPage::decorateTextReplacementsForActiveWritingToolsSession):
(WebKit::WebPage::setSelectionForActiveWritingToolsSession):
(WebKit::WebPage::proofreadingSessionDidCompletePartialReplacement): Deleted.
* Source/WebKit/WebProcess/WebPage/WebPage.h:
* Source/WebKit/WebProcess/WebPage/WebPage.messages.in:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WritingTools.mm:
(-[WritingToolsWKWebView waitForProofreadingSuggestionsToBeReplaced]):
(TEST(WritingTools, ProofreadingAcceptReject)):
(TEST(WritingTools, ProofreadingWithStreamingSuggestions)):
(TEST(WritingTools, ProofreadingWithLongReplacement)):
(TEST(WritingTools, ProofreadingShowOriginal)):
(TEST(WritingTools, ProofreadingShowOriginalWithMultiwordSuggestions)):
(TEST(WritingTools, ProofreadingRevert)):
(TEST(WritingTools, ProofreadingRevertWithSuggestionAtEndOfText)):
(TEST(WritingTools, ProofreadingRevertWithMultiwordSuggestions)):
(TEST(WritingTools, ProofreadingWithImage)):
(TEST(WritingTools, ProofreadingWithAttemptedEditing)):
(TEST(WritingTools, RevealOffScreenSuggestionWhenActive)):
(TEST(WritingTools, ShowDetailsForSuggestions)):
(TEST(WritingTools, IntelligenceTextEffectCoordinatorDelegate_RectsForProofreadingSuggestionsInRange)):
(TEST(WritingTools, IntelligenceTextEffectCoordinatorDelegate_UpdateTextVisibilityForRange)):
Canonical link: https://commits.webkit.org/286183@main
Canonical link: https://commits.webkit.org/283286.440@safari-7620-branch
Commit: 0d5c7a047d702ff8deb0fd49957dd6f9f69c85b9
https://github.com/WebKit/WebKit/commit/0d5c7a047d702ff8deb0fd49957dd6f9f69c85b9
Author: Tim Nguyen <ntim at apple.com>
Date: 2024-11-06 (Wed, 06 Nov 2024)
Changed paths:
M LayoutTests/imported/w3c/web-platform-tests/pointerevents/pointerevent_mouse_pointercapture_inactivate_pointer-expected.txt
M LayoutTests/platform/mac/TestExpectations
M Source/WebCore/page/PointerCaptureController.cpp
M Source/WebCore/page/PointerCaptureController.h
Log Message:
-----------
Cherry-pick 3ea46f4e0b98. rdar://139287625
pointerevents/pointerevent_mouse_pointercapture_inactivate_pointer.html WPT is failing
https://bugs.webkit.org/show_bug.cgi?id=274640
rdar://128669314
Reviewed by Antoine Quint.
Implement a missing bit of the pointer events spec where we weren't checking against the "active document" of the pointer when setting the pointer capture.
https://w3c.github.io/pointerevents/#dfn-set-pointer-capture
* LayoutTests/imported/w3c/web-platform-tests/pointerevents/pointerevent_mouse_pointercapture_inactivate_pointer-expected.txt:
* LayoutTests/platform/mac/TestExpectations:
Rebaseline and unskip test.
* Source/WebCore/page/PointerCaptureController.cpp:
(WebCore::PointerCaptureController::setPointerCapture):
Implement https://w3c.github.io/pointerevents/#ref-for-dfn-active-document-2
(WebCore::PointerCaptureController::pointerEventWillBeDispatched):
Implement https://w3c.github.io/pointerevents/#ref-for-dfn-active-document-1
* Source/WebCore/page/PointerCaptureController.h:
Store active document in CapturingData: https://w3c.github.io/pointerevents/#dfn-active-document
Canonical link: https://commits.webkit.org/286098@main
Canonical link: https://commits.webkit.org/283286.441@safari-7620-branch
Commit: 60fee43e76524b729d49916722e2a8b1d8dbbaa3
https://github.com/WebKit/WebKit/commit/60fee43e76524b729d49916722e2a8b1d8dbbaa3
Author: Jer Noble <jer.noble at apple.com>
Date: 2024-11-06 (Wed, 06 Nov 2024)
Changed paths:
M Source/WebCore/platform/graphics/avfoundation/objc/MediaSampleAVFObjC.h
M Source/WebCore/platform/graphics/avfoundation/objc/MediaSampleAVFObjC.mm
M Source/WebCore/platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.mm
M Source/WebCore/platform/graphics/cocoa/MediaPlayerPrivateWebM.mm
M Source/WebCore/platform/graphics/cocoa/VideoMediaSampleRenderer.h
M Source/WebCore/platform/graphics/cocoa/VideoMediaSampleRenderer.mm
M Source/WebCore/platform/graphics/cocoa/WebCoreDecompressionSession.h
M Source/WebCore/platform/graphics/cocoa/WebCoreDecompressionSession.mm
M Source/WebCore/platform/libwebrtc/LibWebRTCVPXVideoDecoder.cpp
M Source/WebCore/platform/mediastream/libwebrtc/VideoFrameLibWebRTC.cpp
M Source/WebCore/platform/mediastream/libwebrtc/VideoFrameLibWebRTC.h
Log Message:
-----------
Cherry-pick 7611df14b62f. rdar://139288365
Refactor VideoMediaSampleRenderer to support enqueuing decoded samples
https://bugs.webkit.org/show_bug.cgi?id=281497
rdar://137964106
Reviewed by Jean-Yves Avenard.
Currently, WebCoreDecompressionSession maintains a queue of decoded images. However,
when WebCoreDecompressionSession is used in a mode where those decoded images are
delivered to its clients, the queue is bypassed. VideoMediaSampleRenderer is a more
natural place for such a cue to belong, and eventually, all queueing behavior should
be migrated from WebCoreDecompressionSession to VideoMediaSampleRenderer. As a first
step, expose the promise-based WebCoreDecompressionSession::enqueueSample() function,
and expose a static method to create a CoreMedia buffer queue. Use these primitives
inside VideoMediaSampleRenderer to enqueue decoded images for retrieval by clients
later.
In this mode of operation, a VideoMediaSampleRenderer will feed decoded images to
its associated AVSampleBufferDisplayLayer or AVSampleBufferVideoRenderer, and store
those images in a queue for retrieval via copyDisplayedPixelBuffer(). This requires
a CMTimebaseRef, and to ensure the main thread doesn't excessively block these
operations, move most operations to a WorkQueue.
In the future, VideoMediaSampleRenderer can be extended to support having multiple
AVSBDLs or AVSBVRs simultaneously, allowing reconfigurations of layers or renderers
without having to tear down and re-build decoder pipelines.
Drive-by fix: One .webm file in web-platform-tests generates decoded frames of type
I444. This causes a debug assertion to be hit, as VideoFrameLibWebRTC only expects
buffers to be of type I420 or I010. This assertion is now invalid so convert the
VideoFrameLibWebRTC::create() method to return a RefPtr rather than a Ref and
check the input buffer's type in that method.
* Source/WebCore/platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.mm:
(WebCore::SourceBufferPrivateAVFObjC::enqueueSampleBuffer):
* Source/WebCore/platform/graphics/cocoa/MediaPlayerPrivateWebM.mm:
(WebCore::MediaPlayerPrivateWebM::enqueueSample):
(WebCore::MediaPlayerPrivateWebM::setVideoRenderer):
* Source/WebCore/platform/graphics/cocoa/VideoMediaSampleRenderer.h:
(WebCore::VideoMediaSampleRenderer::prefersDecompressionSession):
(WebCore::VideoMediaSampleRenderer::timebase const):
(WebCore::VideoMediaSampleRenderer::setResourceOwner): Deleted.
* Source/WebCore/platform/graphics/cocoa/VideoMediaSampleRenderer.mm:
(WebCore::VideoMediaSampleRenderer::VideoMediaSampleRenderer):
(WebCore::VideoMediaSampleRenderer::~VideoMediaSampleRenderer):
(WebCore::VideoMediaSampleRenderer::isReadyForMoreMediaData const):
(WebCore::VideoMediaSampleRenderer::stopRequestingMediaData):
(WebCore::VideoMediaSampleRenderer::setPrefersDecompressionSession):
(WebCore::VideoMediaSampleRenderer::setPrefersDecompressionSessionInternal):
(WebCore::VideoMediaSampleRenderer::setTimebase):
(WebCore::VideoMediaSampleRenderer::setTimebaseInternal):
(WebCore::VideoMediaSampleRenderer::enqueueSample):
(WebCore::VideoMediaSampleRenderer::initializeDecompressionSession):
(WebCore::VideoMediaSampleRenderer::decodedFrameAvailable):
(WebCore::VideoMediaSampleRenderer::purgeDecodedSampleQueue):
(WebCore::VideoMediaSampleRenderer::ensureDecodedSampleQueue):
(WebCore::VideoMediaSampleRenderer::flush):
(WebCore::VideoMediaSampleRenderer::resetReadyForMoreSample):
(WebCore::VideoMediaSampleRenderer::expectMinimumUpcomingSampleBufferPresentationTime):
(WebCore::VideoMediaSampleRenderer::copyDisplayedPixelBuffer):
(WebCore::VideoMediaSampleRenderer::totalVideoFrames const):
(WebCore::VideoMediaSampleRenderer::droppedVideoFrames const):
(WebCore::VideoMediaSampleRenderer::corruptedVideoFrames const):
(WebCore::VideoMediaSampleRenderer::totalFrameDelay const):
(WebCore::VideoMediaSampleRenderer::setResourceOwner):
(WebCore::VideoMediaSampleRenderer::copyDisplayedPixelBuffer const): Deleted.
* Source/WebCore/platform/graphics/cocoa/WebCoreDecompressionSession.h:
* Source/WebCore/platform/graphics/cocoa/WebCoreDecompressionSession.mm:
(WebCore::WebCoreDecompressionSession::createBufferQueue):
(WebCore::WebCoreDecompressionSession::enqueueSample):
Canonical link: https://commits.webkit.org/286106@main
Canonical link: https://commits.webkit.org/283286.442@safari-7620-branch
Commit: 17b65d135ed3812f2514752597fde8b0c7bd9264
https://github.com/WebKit/WebKit/commit/17b65d135ed3812f2514752597fde8b0c7bd9264
Author: Jer Noble <jer.noble at apple.com>
Date: 2024-11-06 (Wed, 06 Nov 2024)
Changed paths:
M Source/WebKit/UIProcess/API/Cocoa/WKPreferences.mm
M Source/WebKit/UIProcess/API/Cocoa/WKPreferencesPrivate.h
Log Message:
-----------
Cherry-pick af8397ad9f69. rdar://139288439
[visionOS] Add internal preference for spatial video playback
https://bugs.webkit.org/show_bug.cgi?id=282550
rdar://139218406
Reviewed by Eric Carlson.
* Source/WebKit/UIProcess/API/Cocoa/WKPreferences.mm:
(-[WKPreferences _setSpatialVideoEnabled:]):
(-[WKPreferences _spatialVideoEnabled]):
* Source/WebKit/UIProcess/API/Cocoa/WKPreferencesPrivate.h:
Canonical link: https://commits.webkit.org/286119@main
Canonical link: https://commits.webkit.org/283286.443@safari-7620-branch
Commit: 430e2dd31ad17cd5c06c89cb6bfef20ea44dbaa5
https://github.com/WebKit/WebKit/commit/430e2dd31ad17cd5c06c89cb6bfef20ea44dbaa5
Author: Kiet Ho <kiet.ho at apple.com>
Date: 2024-11-06 (Wed, 06 Nov 2024)
Changed paths:
A LayoutTests/fast/dom/view-transition-lifetime-crash-expected.txt
A LayoutTests/fast/dom/view-transition-lifetime-crash.html
M Source/WebCore/Modules/screen-wake-lock/WakeLockManager.cpp
M Source/WebCore/Modules/screen-wake-lock/WakeLockManager.h
M Source/WebCore/Modules/screen-wake-lock/WakeLockSentinel.cpp
M Source/WebCore/dom/Document.cpp
M Source/WebCore/dom/ViewTransition.cpp
M Source/WebCore/dom/ViewTransition.h
M Source/WebCore/dom/VisibilityChangeClient.h
Log Message:
-----------
Cherry-pick c8d323b1851e. rdar://139301982
REGRESSION (283084 at main): Document::visibilityStateChanged does not hold reference to callback clients
rdar://138799302
https://bugs.webkit.org/show_bug.cgi?id=282360
Reviewed by Tim Nguyen, Ryosuke Niwa, and Chris Dumez.
Document::visibilityStateChanged() invokes visibility state callback clients, but does not
hold a reference to them before invoking. The client could then accidentally free itself
and cause an UAF. One possible route that leads to an UAF is through ViewTransition,
which the test case demonstrates:
* The ViewTransition C++ objects are allocated by document.startViewTransition().
After the call, each object has a ref count of at least 2 (one in the JS wrapper
that wraps the C++ object, one in Document::m_activeViewTransition)
* The GC is invoked, which releases the JS wrappers and decreases the ref count to 1
* The document visibility state is changed. This invokes ViewTransition::visibilityStateChanged
on each object, which calls ::skipViewTransition, which calls ::clearViewTransition.
::clearViewTransition sets Document::m_activeViewTransition to null, so the object ref
count is 0 and it's deallocated. ::clearViewTransition then continues to modify the
(already deallocated) object, leading to an UAF.
Fix this by holding a reference to the callback clients before invoking it. This involves
making VisibilityChangeClient ref counted. Then Document::visibilityStateChanged()
would hold a reference to the client before invoking it. As WakeLockManager
(which inherits VisibilityChangeClient) wasn't ref counted, this patch also makes it
ref counted.
It's also observed that the JS wrapper should not be deallocated by the GC before the
view transition has completed. This commit fixes this by implementing
ViewTransition::virtualHasPendingActivity(), which the GC consults to determine whether
to deallocate the wrapper or not.
* LayoutTests/fast/dom/view-transition-lifetime-crash-expected.txt: Added.
* LayoutTests/fast/dom/view-transition-lifetime-crash.html: Added.
* Source/WebCore/Modules/screen-wake-lock/WakeLockManager.cpp:
(WebCore::WakeLockManager::ref const): Delegated ref() to the document.
(WebCore::WakeLockManager::deref const): Delegated deref() to the document.
* Source/WebCore/Modules/screen-wake-lock/WakeLockManager.h: Made WakeLockManager ref counted by declaring ref() and deref().
* Source/WebCore/Modules/screen-wake-lock/WakeLockSentinel.cpp:
(WebCore::WakeLockSentinel::release): Hold a reference to the document's WakeLockManager before using it.
* Source/WebCore/dom/Document.cpp:
(WebCore::Document::visibilityStateChanged): Hold a reference to the visibility state callback client before calling it.
(WebCore::Document::wakeLockManager): Used makeUniqueWithoutRefCountedCheck to create new WakeLockManager.
* Source/WebCore/dom/ViewTransition.cpp:
(WebCore::ViewTransition::virtualHasPendingActivity const): Added implementation.
* Source/WebCore/dom/ViewTransition.h:
* Source/WebCore/dom/VisibilityChangeClient.h: Made VisibilityChangeClient ref counted.
Canonical link: https://commits.webkit.org/286136@main
Canonical link: https://commits.webkit.org/283286.444@safari-7620-branch
Commit: bd990e20e91e8c1dcf4419a7023847538e9f195c
https://github.com/WebKit/WebKit/commit/bd990e20e91e8c1dcf4419a7023847538e9f195c
Author: Youenn Fablet <youenn at apple.com>
Date: 2024-11-06 (Wed, 06 Nov 2024)
Changed paths:
M Source/WebCore/Modules/mediastream/UserMediaRequest.cpp
Log Message:
-----------
Remote Activation of Persistent Webcam Access without User Consent
rdar://138483518
Reviewed by Eric Carlson.
A getUserMedia call may happen before the document is stopped.
The document may be stopped between a source is created and the source is attached to the document via MediaStreamTrack::create.
In that case, the source in the GPUProcess will be created but will never be removed.
If the source is a clone of an active source in GPUProcess, this will prevent the capture to stop when document is tear down.
To prevent this, if the context is stopped, we end the capture source in UserMediaRequest::allow.
* Source/WebCore/Modules/mediastream/UserMediaRequest.cpp:
(WebCore::UserMediaRequest::allow):
Canonical link: https://commits.webkit.org/283286.445@safari-7620-branch
Commit: aa8f49023a76306d5a30226e4ac1b5ed8344b05d
https://github.com/WebKit/WebKit/commit/aa8f49023a76306d5a30226e4ac1b5ed8344b05d
Author: Youenn Fablet <youenn at apple.com>
Date: 2024-11-07 (Thu, 07 Nov 2024)
Changed paths:
M Source/WebKit/NetworkProcess/webrtc/NetworkRTCUDPSocketCocoa.mm
Log Message:
-----------
Cherry-pick 8fa358f99629. rdar://138190780
Reduce missing ECN logging as it can be very verbose on some platforms
rdar://135530047
https://bugs.webkit.org/show_bug.cgi?id=279343
Reviewed by Alex Christensen.
On some platforms, this logging can be very verbose.
We are now only looging it once the UDP connection.
* Source/WebKit/NetworkProcess/webrtc/NetworkRTCUDPSocketCocoa.mm:
(WebKit::NetworkRTCUDPSocketCocoaConnections::ConnectionStateTracker::shouldLogMissingECN const):
(WebKit::NetworkRTCUDPSocketCocoaConnections::ConnectionStateTracker::didLogMissingECN):
(WebKit::getECN):
(WebKit::processUDPData):
Canonical link: https://commits.webkit.org/283465@main
Canonical link: https://commits.webkit.org/283286.446@safari-7620-branch
Commit: b9cead02867b497a822c20911e8038cfc74fdac2
https://github.com/WebKit/WebKit/commit/b9cead02867b497a822c20911e8038cfc74fdac2
Author: Tim Nguyen <ntim at apple.com>
Date: 2024-11-07 (Thu, 07 Nov 2024)
Changed paths:
A LayoutTests/imported/w3c/web-platform-tests/css/css-view-transitions/capture-old-state-error-flag-cleanup-expected.xht
A LayoutTests/imported/w3c/web-platform-tests/css/css-view-transitions/capture-old-state-error-flag-cleanup.html
M Source/WebCore/dom/ViewTransition.cpp
Log Message:
-----------
Cherry-pick 45e2f437b91c. rdar://138353363
[view-transitions] "Capture old state" should clean up captured flag on error
https://bugs.webkit.org/show_bug.cgi?id=281867
rdar://138338884
Reviewed by Matt Woodrow.
This was a spec bug, see:
https://github.com/w3c/csswg-drafts/issues/11058
https://github.com/w3c/csswg-drafts/commit/f894d41d3ce3f75b82339aa454af4e1b7ac2a325
We were not cleaning up properly the "captured in view transition" flag properly on error,
which lead to renderers not being painted despite the view transition having been skipped.
* LayoutTests/imported/w3c/web-platform-tests/css/css-view-transitions/capture-old-state-error-flag-cleanup-expected.xht: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-view-transitions/capture-old-state-error-flag-cleanup.html: Added.
* Source/WebCore/dom/ViewTransition.cpp:
(WebCore::ViewTransition::captureOldState):
Canonical link: https://commits.webkit.org/285535@main
Canonical link: https://commits.webkit.org/283286.447@safari-7620-branch
Commit: 555db26d34dfa503c2580b50702d47fcd6e2b488
https://github.com/WebKit/WebKit/commit/555db26d34dfa503c2580b50702d47fcd6e2b488
Author: Chris Dumez <cdumez at apple.com>
Date: 2024-11-07 (Thu, 07 Nov 2024)
Changed paths:
M Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml
M Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.cpp
M Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.h
M Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.serialization.in
M Source/WebKit/NetworkProcess/NetworkResourceLoader.cpp
M Source/WebKit/WebProcess/Network/WebLoaderStrategy.cpp
Log Message:
-----------
Cherry-pick bd98a6494eff. rdar://138673776
Unship support for `Clear-Site-Data: "executionContext"` HTTP header value
https://bugs.webkit.org/show_bug.cgi?id=271700
rdar://125490226
Reviewed by Per Arne Vollan.
Unship support for `Clear-Site-Data: "executionContext"` HTTP header value. We've recently
added support but we're the only browser engine that supports this value. This header value
causes frames from the origin to get reloaded so it can lead to bad consequences if not used
properly. Now that we have evidence of such unexpected reloads on MDN, I think we should
unship for now.
* Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml:
* Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.cpp:
(WebKit::NetworkResourceLoadParameters::NetworkResourceLoadParameters):
* Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.h:
* Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.serialization.in:
* Source/WebKit/NetworkProcess/NetworkResourceLoader.cpp:
(WebKit::NetworkResourceLoader::processClearSiteDataHeader):
* Source/WebKit/WebProcess/Network/WebLoaderStrategy.cpp:
(WebKit::addParametersShared):
Canonical link: https://commits.webkit.org/285712@main
Canonical link: https://commits.webkit.org/283286.448@safari-7620-branch
Commit: 1b35def6ef776157ab1f69ee471ee3b68ecf6e56
https://github.com/WebKit/WebKit/commit/1b35def6ef776157ab1f69ee471ee3b68ecf6e56
Author: Chris Dumez <cdumez at apple.com>
Date: 2024-11-07 (Thu, 07 Nov 2024)
Changed paths:
M Source/WebKit/WebProcess/WebCoreSupport/WebLocalFrameLoaderClient.cpp
M Source/WebKit/WebProcess/WebCoreSupport/WebLocalFrameLoaderClient.h
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Tools/TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm
Log Message:
-----------
Cherry-pick 2b008f6776a2. rdar://138704981
Using Cross-Origin-Opener-Policy HTTP header may corrupt the back/forward list
https://bugs.webkit.org/show_bug.cgi?id=281175
rdar://137635838
Reviewed by Sihui Liu.
The reason the back/forward list was getting "corrupted" is that we would process-swap
on link navigation but use an API::Navigation object from an earlier back/forward
navigation, instead of create a new API::Navigation object for this new navigation.
This would cause us to think this is a back/forward navigation and we would incorrectly
overwrite the current back/forward item.
The reason we were using the wrong API::Navigation object is that this is a navigation
triggered by the page (not the client app). As a result, the navigation request comes
from the WebProcess to the UIProcess and this request contained a navigationID which
was the navigationID of the previous same-document back navigation. (If the navigation
was trigger by the client app, we would create a new navigation object right away and
pass this navigationID to the WebProcess).
Now the reason why the WebProcess was sending us an old navigationID is because when
the WebProcess did the last same-document back navigation, it stored the navigationID
in WebPage::m_pendingNavigationID. Normally, this navigationID would get set on the
DocumentLoader later on when it gets created and m_pendingNavigationID would get cleared.
Here, because it was a same document navigation, no DocumentLoader gets created. Our
code was dealing with that by overriding `dispatchDidChangeLocationWithinPage()` and
clearing m_pendingNavigationID then. However, `dispatchDidChangeLocationWithinPage()`
only gets called on fragment navigations. The reproduction site here was using a same
document navigation using `history.pushState()` but the new URL would append `/foo` to
the URL instead of `#foo`, which is allowed. It's still a same-document navigation but
not a fragment navigation. As a result, it wouldn't call `dispatchDidChangeLocationWithinPage()`
and it wouldn't clear m_pendingNavigationID. Then when the next link navigation would
occur, it would end up mistakenly reusing the leftover m_pendingNavigationID.
To address the issue, I now override `dispatchDidNavigateWithinPage()` too and clear
`WebPage::m_pendingNavigationID` when it gets called. `dispatchDidNavigateWithinPage()`
gets called on all same-document navigations.
This is covered by a new API test.
* Source/WebKit/WebProcess/WebCoreSupport/WebLocalFrameLoaderClient.cpp:
(WebKit::WebLocalFrameLoaderClient::dispatchDidNavigateWithinPage):
* Source/WebKit/WebProcess/WebCoreSupport/WebLocalFrameLoaderClient.h:
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::didNavigateWithinPageForFrame):
* Source/WebKit/WebProcess/WebPage/WebPage.h:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm:
((ProcessSwap, NavigateBackAfterNavigatingAwayFromCrossOriginOpenerPolicyUsingBackForwardCache2)):
Canonical link: https://commits.webkit.org/285729@main
Canonical link: https://commits.webkit.org/283286.449@safari-7620-branch
Commit: 0b400627a24270865c2635187ddae1e37d638bc1
https://github.com/WebKit/WebKit/commit/0b400627a24270865c2635187ddae1e37d638bc1
Author: Dan Hecht <dan.hecht at apple.com>
Date: 2024-11-07 (Thu, 07 Nov 2024)
Changed paths:
M Source/JavaScriptCore/wasm/WasmModuleInformation.h
M Source/JavaScriptCore/wasm/WasmParser.h
M Source/JavaScriptCore/wasm/WasmSectionParser.cpp
M Source/JavaScriptCore/wasm/WasmTypeDefinition.cpp
M Source/JavaScriptCore/wasm/WasmTypeDefinition.h
M Source/JavaScriptCore/wasm/WasmTypeDefinitionInlines.h
Log Message:
-----------
Cherry-pick 3ec2959867b0. rdar://139391912
[JSC] Fix ref-counting issues with Wasm GC types
https://bugs.webkit.org/show_bug.cgi?id=282576
rdar://139244985
Reviewed by Yusuke Suzuki.
While parsing the wasm type section there are windows where
reference counts to a Wasm GC TypeDefinitions are not held
by the parser. During these windows, a
TypeInformation::tryCleanup() could free these
types out from under the parser. Close these windows.
Also add asserts to help verify and document.
The windows were:
1. parseRecursionGroup() needs to hold ref counts to each
element until it constructs the recursion group, which
takes ownership.
2. parseRecursionGroup() needs to create its projections
and hold references while they are being linked together.
3. While replacing placeholders, we need to be careful to
continue holding a ref count until the unrolling cache
takes ownership.
Also, RTT::tryCreateRTT() was missing an adoptRef which
I think would cause these to leak.
After parsing, everythng is owned by the parser's
WasmModuleInformation either directly, indirectly through
the TypeDefinition tree of (manual kept) ref counts, or
indirectly via the TypeInformation caches (which tie the
lifetime of the value to the key).
In addition to the added asserts, I also ran the
javascriptcore test with more instrumentation added
to TypeDefinition::deref() to help ensure references are no
longer dropped at the wrong times.
* Source/JavaScriptCore/wasm/WasmModuleInformation.h:
* Source/JavaScriptCore/wasm/WasmParser.h:
(JSC::Wasm::ParserBase::parseValueType):
* Source/JavaScriptCore/wasm/WasmSectionParser.cpp:
(JSC::Wasm::SectionParser::parseType):
(JSC::Wasm::SectionParser::parseRecursionGroup):
(JSC::Wasm::SectionParser::parseSubtype):
* Source/JavaScriptCore/wasm/WasmTypeDefinition.cpp:
(JSC::Wasm::TypeDefinition::substitute):
(JSC::Wasm::substituteParent):
(JSC::Wasm::TypeDefinition::replacePlaceholders const):
(JSC::Wasm::TypeDefinition::unroll const):
(JSC::Wasm::RTT::tryCreateRTT):
(JSC::Wasm::TypeInformation::addCachedUnrolling):
(JSC::Wasm::TypeInformation::tryCleanup):
* Source/JavaScriptCore/wasm/WasmTypeDefinition.h:
(JSC::Wasm::TypeDefinition::unownedIndex const):
(JSC::Wasm::TypeDefinition::index const): Deleted.
* Source/JavaScriptCore/wasm/WasmTypeDefinitionInlines.h:
(JSC::Wasm::TypeDefinition::index const):
(JSC::Wasm::TypeInformation::get):
Canonical link: https://commits.webkit.org/286140@main
Canonical link: https://commits.webkit.org/283286.450@safari-7620-branch
Commit: a873b0a802e60d4a32a6cdfc045b2b04dae7138f
https://github.com/WebKit/WebKit/commit/a873b0a802e60d4a32a6cdfc045b2b04dae7138f
Author: Timothy Hatcher <timothy at apple.com>
Date: 2024-11-07 (Thu, 07 Nov 2024)
Changed paths:
M Source/WebKit/WebProcess/Extensions/API/Cocoa/WebExtensionAPIEventCocoa.mm
M Source/WebKit/WebProcess/Extensions/API/Cocoa/WebExtensionAPIWebNavigationEventCocoa.mm
M Source/WebKit/WebProcess/Extensions/API/Cocoa/WebExtensionAPIWebRequestEventCocoa.mm
M Source/WebKit/WebProcess/Extensions/API/Cocoa/WebExtensionAPIWindowsEventCocoa.mm
M Source/WebKit/WebProcess/Extensions/Cocoa/_WKWebExtensionWebRequestFilter.h
M Source/WebKit/WebProcess/Extensions/Cocoa/_WKWebExtensionWebRequestFilter.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebExtensionAPIAlarms.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebExtensionAPIWebNavigation.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebExtensionAPIWebRequest.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebExtensionAPIWindows.mm
Log Message:
-----------
Cherry-pick 0628c831bdfb. rdar://139439066
Crash under WebExtensionCallbackHandler::call() when removing event listener.
https://webkit.org/b/282723
rdar://139326901
Reviewed by Brian Weinstein.
Make a copy of the listeners vector before iterating over it.
* Source/WebKit/WebProcess/Extensions/API/Cocoa/WebExtensionAPIEventCocoa.mm:
(WebKit::WebExtensionAPIEvent::invokeListeners):
(WebKit::WebExtensionAPIEvent::invokeListenersWithArgument):
* Source/WebKit/WebProcess/Extensions/API/Cocoa/WebExtensionAPIWebNavigationEventCocoa.mm:
(WebKit::WebExtensionAPIWebNavigationEvent::invokeListenersWithArgument):
* Source/WebKit/WebProcess/Extensions/API/Cocoa/WebExtensionAPIWebRequestEventCocoa.mm:
(WebKit::WebExtensionAPIWebRequestEvent::invokeListenersWithArgument):
* Source/WebKit/WebProcess/Extensions/API/Cocoa/WebExtensionAPIWindowsEventCocoa.mm:
(WebKit::WebExtensionAPIWindowsEvent::invokeListenersWithArgument):
* Source/WebKit/WebProcess/Extensions/Cocoa/_WKWebExtensionWebRequestFilter.h:
* Source/WebKit/WebProcess/Extensions/Cocoa/_WKWebExtensionWebRequestFilter.mm:
(toWebExtensionWebRequestResourceType): Drive-by rename.
(_WKWebExtensionWebRequestResourceTypeFromResourceLoadInfo): Deleted.
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebExtensionAPIAlarms.mm:
(TestWebKitAPI::TEST(WKWebExtensionAPIAlarms, RemoveListenerDuringEvent)): Added.
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebExtensionAPIWebNavigation.mm:
(TestWebKitAPI::TEST(WKWebExtensionAPIWebNavigation, RemoveListenerDuringEvent)): Added.
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebExtensionAPIWebRequest.mm:
(TestWebKitAPI::TEST(WKWebExtensionAPIWebRequest, RemoveListenerDuringEvent)): Added.
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebExtensionAPIWindows.mm:
(TestWebKitAPI::TEST(WKWebExtensionAPIWindows, RemoveListenerDuringEvent)): Added.
Canonical link: https://commits.webkit.org/286260@main
Canonical link: https://commits.webkit.org/283286.451@safari-7620-branch
Commit: ed36e75d4b2d5e85915e5cb19ab1960d8e2a21a5
https://github.com/WebKit/WebKit/commit/ed36e75d4b2d5e85915e5cb19ab1960d8e2a21a5
Author: Richard Robinson <richard_robinson2 at apple.com>
Date: 2024-11-07 (Thu, 07 Nov 2024)
Changed paths:
M Source/WebKit/UIProcess/API/mac/WKWebViewMac.mm
M Source/WebKit/UIProcess/mac/WebViewImpl.h
M Source/WebKit/UIProcess/mac/WebViewImpl.mm
M Source/WebKit/WebKitSwift/WritingTools/WKIntelligenceTextEffectCoordinator.h
M Source/WebKit/WebKitSwift/WritingTools/WKIntelligenceTextEffectCoordinator.swift
Log Message:
-----------
Cherry-pick cd0b50ca7cce. rdar://139445172
[Intelligence Effects] Scrolling during a proofreading animation causes overlapping text on macOS
https://bugs.webkit.org/show_bug.cgi?id=282712
rdar://139246952
Reviewed by Abrar Rahman Protyasha.
Stop any ongoing intelligence effects if a scroll/resize/zoom happens.
* Source/WebKit/UIProcess/API/mac/WKWebViewMac.mm:
(-[WKWebView _web_hasActiveIntelligenceTextEffects]):
(-[WKWebView _web_suppressContentRelativeChildViews]):
(-[WKWebView _web_restoreContentRelativeChildViews]):
* Source/WebKit/UIProcess/mac/WebViewImpl.h:
* Source/WebKit/UIProcess/mac/WebViewImpl.mm:
(WebKit::WebViewImpl::hasContentRelativeChildViews const):
(WebKit::WebViewImpl::suppressContentRelativeChildViews):
(WebKit::WebViewImpl::restoreContentRelativeChildViews):
* Source/WebKit/WebKitSwift/WritingTools/WKIntelligenceTextEffectCoordinator.h:
* Source/WebKit/WebKitSwift/WritingTools/WKIntelligenceTextEffectCoordinator.swift:
(hasActiveEffects):
(hideEffects):
(showEffects):
(setupViewIfNeeded):
(reset):
(WKIntelligenceTextEffectCoordinator.updateTextChunkVisibility(_:visible:force:)):
(textVisibilityRegionIdentifiers): Deleted.
Canonical link: https://commits.webkit.org/286254@main
Canonical link: https://commits.webkit.org/283286.452@safari-7620-branch
Commit: 283af4be02db7cacdf380504cc46e4b425943409
https://github.com/WebKit/WebKit/commit/283af4be02db7cacdf380504cc46e4b425943409
Author: Dan Robson <dtr_bugzilla at apple.com>
Date: 2024-11-07 (Thu, 07 Nov 2024)
Changed paths:
A JSTests/stress/oom-test-for-replace-all.js
A JSTests/wasm/stress/omg-tail-call-clobber-pinned-registers.js
M Source/JavaScriptCore/wasm/WasmFunctionParser.h
M Source/JavaScriptCore/wasm/WasmOMGIRGenerator.cpp
M Source/JavaScriptCore/wasm/WasmOMGIRGenerator32_64.cpp
M Source/JavaScriptCore/wasm/WasmOMGPlan.cpp
M Source/JavaScriptCore/wasm/WasmOSREntryPlan.cpp
Log Message:
-----------
Cherry-pick 91c5b2e06b9c. rdar://139372087
Cherry-pick f35184a412c9. rdar://139362369
[JSC] Wasm TailCall should say "pinned registers can be clobbered" in OMG https://bugs.webkit.org/show_bug.cgi?id=282635 rdar://138178964
Reviewed by Keith Miller and David Degazio.
We need to say that pinned registers are clobbered for transitive tail-calls
in OMG to correctly restore wasm instance.
* JSTests/wasm/stress/omg-tail-call-clobber-pinned-registers.js: Added.
* Source/JavaScriptCore/wasm/WasmFunctionParser.h:
* Source/JavaScriptCore/wasm/WasmOMGIRGenerator.cpp:
(JSC::Wasm::OMGIRGenerator::addCall):
(JSC::Wasm::OMGIRGenerator::addCallRef):
* Source/JavaScriptCore/wasm/WasmOMGIRGenerator32_64.cpp:
(JSC::Wasm::OMGIRGenerator::addCall):
* Source/JavaScriptCore/wasm/WasmOMGPlan.cpp:
(JSC::Wasm::OMGPlan::dumpDisassembly):
* Source/JavaScriptCore/wasm/WasmOSREntryPlan.cpp:
(JSC::Wasm::OSREntryPlan::dumpDisassembly):
Canonical link: https://commits.webkit.org/286193@main
Canonical link: https://commits.webkit.org/283286.450@safari-7620.1.16.10-branch
Canonical link: https://commits.webkit.org/283286.453@safari-7620-branch
Commit: a58946bf6e5e6cab170c644c3a71c4ace08334d9
https://github.com/WebKit/WebKit/commit/a58946bf6e5e6cab170c644c3a71c4ace08334d9
Author: Abrar Rahman Protyasha <a_protyasha at apple.com>
Date: 2024-11-07 (Thu, 07 Nov 2024)
Changed paths:
M Source/WebKit/Platform/spi/Cocoa/NearFieldSPI.h
M Source/WebKit/UIProcess/WebAuthentication/Mock/MockNfcService.mm
Log Message:
-----------
Cherry-pick 62a6f504bf7e. rdar://139473642
Fix the open source macOS 15.1-and-above build after 284018 at main
https://bugs.webkit.org/show_bug.cgi?id=282414
rdar://139032978
Reviewed by Wenson Hsieh.
284018 at main fixed internal builds by not calling into
`-[NFReaderSession init]` on certain platform versions, but the fallback
SPI `-initWithUIType:` was not forward declared, so open source builds
calling into said SPI failed. Namely, the build error looks as such:
```
Source/WebKit/UIProcess/WebAuthentication/Mock/MockNfcService.mm:251:70: error: instance method
'-initWithUIType:' not found (return type defaults to 'id') [-Werror,-Wobjc-method-access]
251 | auto readerSession = adoptNS([allocNFReaderSessionInstance() initWithUIType:NFReaderSessionUINone]);
| ^~~~~~~~~~~~~~
Source/WebKit/UIProcess/WebAuthentication/Mock/MockNfcService.mm:251:85: error: use of undeclared identifier
'NFReaderSessionUINone'
251 | auto readerSession = adoptNS([allocNFReaderSessionInstance() initWithUIType:NFReaderSessionUINone]);
|
```
This patch addresses said build failure by providing appropriate forward
declarations in NearFieldSPI.h, but also opportunistically moves away
unconditionally from `[NFReaderSession init]`, which is marked unavailable
in certain SDK versions, to `[NFReaderSession initWithUIType:]`. This is
safe to do so because the latter is part of the internal SDK on all
supported platform configurations.
* Source/WebKit/Platform/spi/Cocoa/NearFieldSPI.h:
* Source/WebKit/UIProcess/WebAuthentication/Mock/MockNfcService.mm:
(WebKit::MockNfcService::platformStartDiscovery):
(WebKit::MockNfcService::detectTags const):
Canonical link: https://commits.webkit.org/285991@main
Canonical link: https://commits.webkit.org/283286.454@safari-7620-branch
Commit: 6646c8bb8abcfb3eb7a9e526d8e9b55f64345e26
https://github.com/WebKit/WebKit/commit/6646c8bb8abcfb3eb7a9e526d8e9b55f64345e26
Author: Jessica Cheung <jcheung23 at apple.com>
Date: 2024-11-07 (Thu, 07 Nov 2024)
Changed paths:
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
M Source/WebKit/UIProcess/ios/forms/WKFileUploadPanel.h
M Source/WebKit/UIProcess/ios/forms/WKFileUploadPanel.mm
Log Message:
-----------
Cherry-pick 283687c657f3. rdar://139100605
gmail.com: [iPad] Tapping the file icon when composing an email brings up the keyboard
https://bugs.webkit.org/show_bug.cgi?id=281194
rdar://89692326
Reviewed by Wenson Hsieh.
Changed `WKContentViewInteraction.mm` to check for repositioning context menu
when keyboard is dismissed. If keyboard is dismissed, we should reposition back
to the bottom where it would be without a keyboard shown.
Fixed positioning of context menu when file icon is clicked in gmail.com [iPad]
so when keyboard is up, we don't cover the context menu.
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _keyboardDidShow]):
(-[WKContentView _keyboardDidRequestDismissal:]):
* Source/WebKit/UIProcess/ios/forms/WKFileUploadPanel.h:
* Source/WebKit/UIProcess/ios/forms/WKFileUploadPanel.mm:
(-[WKFileUploadPanel presentWithParameters:resultListener:]):
Canonical link: https://commits.webkit.org/285153@main
Canonical link: https://commits.webkit.org/283286.455@safari-7620-branch
Commit: c8d6b4726b32d225a2d5fc87c6434146ba0d48f8
https://github.com/WebKit/WebKit/commit/c8d6b4726b32d225a2d5fc87c6434146ba0d48f8
Author: Jessica Cheung <jcheung23 at apple.com>
Date: 2024-11-07 (Thu, 07 Nov 2024)
Changed paths:
M Source/WebCore/page/Quirks.cpp
M Source/WebCore/page/Quirks.h
M Source/WebCore/style/StyleAdjuster.cpp
Log Message:
-----------
Cherry-pick 1f2c8fc06d64. rdar://139100687
[Quirk] prime.amazon.com: macOS double click on screen below pause button shows a blue box
https://bugs.webkit.org/show_bug.cgi?id=281242
rdar://128962002
Reviewed by Abrar Rahman Protyasha.
Added an amazon.com quirk to have `-webkit-user-select: none;` on `webPlayerSDKUiContainer`.
This way, the divs inside `webPlayerSDKUiContainer` cannot be selected.
This div only shows when prime video is playing.
* Source/WebCore/page/Quirks.cpp:
(WebCore::Quirks::needsPrimeVideoUserSelectNoneQuirk const):
* Source/WebCore/page/Quirks.h:
* Source/WebCore/style/StyleAdjuster.cpp:
(WebCore::Style::Adjuster::adjustForSiteSpecificQuirks const):
Canonical link: https://commits.webkit.org/285267@main
Canonical link: https://commits.webkit.org/283286.456@safari-7620-branch
Commit: 0d54f9deb9a2d6f53f12fee65c8b9bcd5f7f0af1
https://github.com/WebKit/WebKit/commit/0d54f9deb9a2d6f53f12fee65c8b9bcd5f7f0af1
Author: Youenn Fablet <youenn at apple.com>
Date: 2024-11-07 (Thu, 07 Nov 2024)
Changed paths:
M LayoutTests/fast/mediastream/mediastreamtrack-video-clone-expected.txt
M LayoutTests/fast/mediastream/mediastreamtrack-video-clone.html
M Source/WebCore/Modules/mediastream/MediaStreamTrack.cpp
M Source/WebCore/platform/mediastream/MediaStreamTrackPrivate.cpp
Log Message:
-----------
Cherry-pick c29f5f0e0f7e. rdar://138930454
REGRESSION (Safari 18): Audio from disabled MediaStreamTrack is published
rdar://138321310
https://bugs.webkit.org/show_bug.cgi?id=281758
Reviewed by Eric Carlson.
When cloning or transferring a track, we need to preserve track.enabled.
We make sure to copy this value in MediaStreamTrackPrivate constructor.
When transferring an ended track or a track that is getting ended, the transferring track should be in ended state.
We copy ended in MediaStreamTrackPrivate constructor and we make sure to set the track ready state to ended in MediaStreamTrack::create.
We do not do this in MediaStreamTrack constructor as this path is used for cloning a track.
When cloning a being ended track, we might also want to fire an ended event.
Setting ready state in MediaStreamTrack constructor would prevent this.
* LayoutTests/fast/mediastream/mediastreamtrack-video-clone-expected.txt:
* LayoutTests/fast/mediastream/mediastreamtrack-video-clone.html:
* Source/WebCore/Modules/mediastream/MediaStreamTrack.cpp:
(WebCore::MediaStreamTrack::create):
* Source/WebCore/platform/mediastream/MediaStreamTrackPrivate.cpp:
(WebCore::MediaStreamTrackPrivate::MediaStreamTrackPrivate):
Canonical link: https://commits.webkit.org/285916@main
Canonical link: https://commits.webkit.org/283286.457@safari-7620-branch
Commit: 1d0ee529a7ea814043dc483620dbf4599903541c
https://github.com/WebKit/WebKit/commit/1d0ee529a7ea814043dc483620dbf4599903541c
Author: Sammy Gill <sammy.gill at apple.com>
Date: 2024-11-07 (Thu, 07 Nov 2024)
Changed paths:
A LayoutTests/imported/w3c/web-platform-tests/css/css-grid/grid-items/overflow-hidden-min-content-contribution-in-abs-pos-grid-in-flexbox-expected.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-grid/grid-items/overflow-hidden-min-content-contribution-in-abs-pos-grid-in-flexbox.html
M Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp
Log Message:
-----------
Cherry-pick a3f64e9fd109. rdar://139241994
[Grid] REGRESSION (276633 at main): Automatic minimum size of scrollable grid item is 0.
https://bugs.webkit.org/show_bug.cgi?id=278645
rdar://135134725
Reviewed by Alan Baradlay.
In 276633 at main, we changed logicalHeightForGridItem to be more restrictive
when it invalidates a grid item and performs layout on it. This ended
up exposing another bug where we would incorrectly compute the minimum contribution of a
grid item that is a scroll container.
The spec defines the minimum contribution as "the outer size that would result from
assuming the item’s used minimum size as its preferred size." In the case where the
grid item's minimum size is auto and it is a scroll container, then we default to some
logic that calls minLogicalSizeForGridItem.
However, grid defines how an item's used automatic minimum size should be calculated,
and in the case of it being a scroll container, the spec says that it does not have one,
so it should just be 0. In this case, we should just return 0 for the item’s minimum
contribution instead of trying to compute some (possibly incorrect) value.
* LayoutTests/imported/w3c/web-platform-tests/css/css-grid/grid-items/overflow-hidden-min-content-contribution-in-abs-pos-grid-in-flexbox-expected.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-grid/grid-items/overflow-hidden-min-content-contribution-in-abs-pos-grid-in-flexbox.html: Added.
* Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:
(WebCore::GridTrackSizingAlgorithmStrategy::minLogicalSizeForGridItem const):
Canonical link: https://commits.webkit.org/286122@main
Canonical link: https://commits.webkit.org/283286.458@safari-7620-branch
Commit: 1bba978595f853f4441ed058fde4d458fc599fc1
https://github.com/WebKit/WebKit/commit/1bba978595f853f4441ed058fde4d458fc599fc1
Author: Dan Hecht <dan.hecht at apple.com>
Date: 2024-11-07 (Thu, 07 Nov 2024)
Changed paths:
M Source/JavaScriptCore/heap/BlockDirectory.cpp
Log Message:
-----------
Cherry-pick f37d9259bd1c. rdar://139330273
[JSC] Fix BlockDirectory::findMarkedBlockHandleDebug() null pointer deref
https://bugs.webkit.org/show_bug.cgi?id=282649
rdar://139317312
Reviewed by Yijia Huang.
BlockDirectory::removeBlock() will null out entries in m_blocks when
removing a block, so this debugging code should skip these null entries.
* Source/JavaScriptCore/heap/BlockDirectory.cpp:
(JSC::BlockDirectory::findMarkedBlockHandleDebug):
Canonical link: https://commits.webkit.org/286197@main
Canonical link: https://commits.webkit.org/283286.459@safari-7620-branch
Commit: cd6dbea7a64fdc6c5b00803f5ed1c73b41939590
https://github.com/WebKit/WebKit/commit/cd6dbea7a64fdc6c5b00803f5ed1c73b41939590
Author: Wenson Hsieh <wenson_hsieh at apple.com>
Date: 2024-11-07 (Thu, 07 Nov 2024)
Changed paths:
M Source/WebCore/page/Quirks.cpp
M Source/WebCore/page/Quirks.h
Log Message:
-----------
Cherry-pick 952ca668cb88. rdar://139078315
[macOS] Text selection incorrectly appears when clicking on playback controls on amazon.co.uk/gb/video
https://bugs.webkit.org/show_bug.cgi?id=281787
rdar://138115410
Reviewed by Abrar Rahman Protyasha and Richard Robinson.
Generalize the quirk added in https://commits.webkit.org/285267@main, so that it applies to all
Amazon domains (not just amazon.com).
* Source/WebCore/page/Quirks.cpp:
(WebCore::Quirks::needsPrimeVideoUserSelectNoneQuirk const):
* Source/WebCore/page/Quirks.h:
Canonical link: https://commits.webkit.org/285449@main
Canonical link: https://commits.webkit.org/283286.460@safari-7620-branch
Commit: 5fa1fa0274baa06dee93715a97c5a4817a0a1f12
https://github.com/WebKit/WebKit/commit/5fa1fa0274baa06dee93715a97c5a4817a0a1f12
Author: Timothy Hatcher <timothy at apple.com>
Date: 2024-11-08 (Fri, 08 Nov 2024)
Changed paths:
M Source/WTF/wtf/Language.cpp
M Source/WTF/wtf/Language.h
M Source/WTF/wtf/cocoa/LanguageCocoa.mm
M Source/WebCore/en.lproj/Localizable.strings
M Source/WebKit/Shared/Extensions/_WKWebExtensionLocalization.mm
M Source/WebKit/UIProcess/API/Cocoa/WKWebExtension.mm
M Source/WebKit/UIProcess/Extensions/Cocoa/WebExtensionCocoa.mm
M Source/WebKit/UIProcess/Extensions/WebExtension.h
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebExtension.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebExtensionAPILocalization.mm
Log Message:
-----------
Cherry-pick 5cb898d5fbec. rdar://139078357
Web Extensions fail to load Chinese localizations.
https://webkit.org/b/281928
rdar://problem/138435009
Reviewed by Brian Weinstein.
* Improve best match logic by using `indexOfBestMatchingLanguageInList()` with the extension's
supported locales. This properly handles Chinese script codes.
* Add error handling for `default_locale` by validating it against the locales provided in the
extension's `_locales` directory.
* Source/WTF/wtf/Language.cpp:
(WTF::canonicalLanguageIdentifier): Simplified to handle more than 2 parts.
(WTF::parseLocale): Added.
(WTF::indexOfBestMatchingLanguageInList): Simplified and use canonicalized input.
* Source/WTF/wtf/Language.h:
* Source/WTF/wtf/cocoa/LanguageCocoa.mm:
(WTF::parseLocale): Added.
* Source/WebCore/en.lproj/Localizable.strings: Updated.
* Source/WebKit/Shared/Extensions/_WKWebExtensionLocalization.mm:
(-[_WKWebExtensionLocalization initWithWebExtension:]): Use new helpers from WebExtension
to load the three possible localization dictionaries.
* Source/WebKit/UIProcess/API/Cocoa/WKWebExtension.mm:
(-[WKWebExtension defaultLocale]): Make the `NSLocale` here.
* Source/WebKit/UIProcess/Extensions/Cocoa/WebExtensionCocoa.mm:
(WebKit::WebExtension::parseManifest): Add error handling for `default_locale`.
(WebKit::WebExtension::preferredSystemLocales): Added.
(WebKit::WebExtension::parseLocale): Added.
(WebKit::WebExtension::defaultLocale): Deleted.
* Source/WebKit/UIProcess/Extensions/WebExtension.cpp:
(WebKit::toAPI): Added InvalidDefaultLocale error.
(WebKit::WebExtension::createError): Ditto.
(WebKit::WebExtension::supportedLocales): Added.
(WebKit::WebExtension::defaultLocale): Added.
(WebKit::WebExtension::bestMatchLocale): Added.
* Source/WebKit/UIProcess/Extensions/WebExtension.h:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebExtension.mm:
(TestWebKitAPI::TEST(WKWebExtension, DefaultLocaleParsing)): Added.
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebExtensionAPILocalization.mm:
(TestWebKitAPI::TEST(WKWebExtensionAPILocalization, i18nWithFallback)): Force `en-US` to match expectations.
(TestWebKitAPI::TEST(WKWebExtensionAPILocalization, i18nChineseSimplified)): Added.
(TestWebKitAPI::TEST(WKWebExtensionAPILocalization, i18nChineseSimplifiedOnly)): Added.
(TestWebKitAPI::TEST(WKWebExtensionAPILocalization, i18nChineseSimplifiedScript)): Added.
(TestWebKitAPI::TEST(WKWebExtensionAPILocalization, i18nChineseTraditional)): Added.
(TestWebKitAPI::TEST(WKWebExtensionAPILocalization, i18nChineseSimplifiedInTaiwan)): Added.
(TestWebKitAPI::TEST(WKWebExtensionAPILocalization, i18nChineseTraditionalInChina)): Added.
(TestWebKitAPI::TEST(WKWebExtensionAPILocalization, i18nChineseSimplifiedInHongKong)): Added.
(TestWebKitAPI::TEST(WKWebExtensionAPILocalization, i18nChineseTraditionalOnly)): Added.
(TestWebKitAPI::TEST(WKWebExtensionAPILocalization, i18nChineseTraditionalScript)): Added.
(TestWebKitAPI::TEST(WKWebExtensionAPILocalization, i18nChineseLanguageFallback)): Added.
(TestWebKitAPI::TEST(WKWebExtensionAPILocalization, i18nPortugueseBrazilian)): Added.
(TestWebKitAPI::TEST(WKWebExtensionAPILocalization, i18nPortugueseEuropean)): Added.
(TestWebKitAPI::TEST(WKWebExtensionAPILocalization, i18nPortugueseUnitedStates)): Added.
(TestWebKitAPI::TEST(WKWebExtensionAPILocalization, i18nPortugueseUnitedStatesFallbackToBrazilian)): Added.
(TestWebKitAPI::TEST(WKWebExtensionAPILocalization, i18nPortugueseUnitedStatesFallbackToGeneric)): Added.
(TestWebKitAPI::TEST(WKWebExtensionAPILocalization, i18nPortugueseLanguageFallback)): Added.
Canonical link: https://commits.webkit.org/285633@main
Canonical link: https://commits.webkit.org/283286.461@safari-7620-branch
Commit: 90939eb5335e919c0720e25587c9d792d9339421
https://github.com/WebKit/WebKit/commit/90939eb5335e919c0720e25587c9d792d9339421
Author: Vitor Roriz <vitor.roriz at apple.com>
Date: 2024-11-08 (Fri, 08 Nov 2024)
Changed paths:
A LayoutTests/imported/w3c/web-platform-tests/css/css-text-decor/text-shadow/text-shadow-emoji-transparent-expected.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-text-decor/text-shadow/text-shadow-emoji-transparent-ref.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-text-decor/text-shadow/text-shadow-emoji-transparent.html
M Source/WebCore/platform/graphics/FontCascade.h
M Source/WebCore/platform/graphics/cairo/FontCairoHarfbuzzNG.cpp
M Source/WebCore/platform/graphics/coretext/FontCascadeCoreText.cpp
M Source/WebCore/platform/graphics/skia/FontCascadeSkia.cpp
M Source/WebCore/platform/graphics/win/FontWin.cpp
M Source/WebCore/rendering/TextBoxPainter.cpp
M Source/WebCore/rendering/TextPainter.cpp
M Source/WebCore/rendering/TextPainter.h
Log Message:
-----------
Cherry-pick 1db24f6817a9. rdar://139078251
Regression(279037 at main) Safari stopped rendering shadow under emoji when color is set to transparent.
https://bugs.webkit.org/show_bug.cgi?id=282068
rdar://136067858
Reviewed by Simon Fraser.
The bug comes from the fact that invisible glyphs that are drawn
as an image won't be recorded into the glyph display list, even if
they have an associated shadow. When that happens we still try to
replay the cached DisplayList instead of drawing the glyph with the
appropriate mutated GraphicsContext.
CoreText won't call the drawImage delegate for glyphs that are invisible,
even if they have an associated shadow applied to its graphic context.
This would result in a glyph display list without the invisible glyph which
is drawn as image and we would not draw its associated shadow.
Therefore, we won't use a display list for runs that are invisible and have
an associated shadow for CoreText platorm use case.
* LayoutTests/imported/w3c/web-platform-tests/css/css-text-decor/text-shadow/text-shadow-emoji-transparent-expected.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-text-decor/text-shadow/text-shadow-emoji-transparent-ref.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-text-decor/text-shadow/text-shadow-emoji-transparent.html: Added.
* Source/WebCore/rendering/GlyphDisplayListCache.cpp:
(WebCore::GlyphDisplayListCache::getDisplayList):
Canonical link: https://commits.webkit.org/285870@main
Canonical link: https://commits.webkit.org/283286.462@safari-7620-branch
Commit: f15042d2eac906158f8ba95a7553dedf6b3423e5
https://github.com/WebKit/WebKit/commit/f15042d2eac906158f8ba95a7553dedf6b3423e5
Author: Sammy Gill <sammy.gill at apple.com>
Date: 2024-11-08 (Fri, 08 Nov 2024)
Changed paths:
A LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/shrink-to-fit-sizing-max-width-min-content-expected.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/shrink-to-fit-sizing-max-width-min-content.html
M Source/WebCore/rendering/RenderBox.cpp
M Source/WebCore/rendering/RenderBox.h
Log Message:
-----------
Cherry-pick 93eee6b40662. rdar://139205951
[Shrink-To-Fit] shrink-to-fit sizing should consider max-inline-size: min-content.
https://bugs.webkit.org/show_bug.cgi?id=280549
rdar://136520853
Reviewed by Alan Baradlay.
Currently, when we compute the preferred logical widths of a renderer, we will consider
the min/max logical width properties if they are fixed values. We should, however, be
able to handle any other values for these properties, and in this patch, we extend support
for min-content of the max logical width.
To accomplish this, I shuffled around some of the logic that was trying to compute the used
min/max logical widths at the top of the method. This should not be a functional change since
these computations don't rely on the values we have so far computed for m_min/maxPreferredLogicalWidth.
In the logic for computing the used max logical width, we now consider max-width: min-content:
- If the m_min/maxPreferredLogicalWidths computed from the style's logical width value, then
we compute the intrinsic logical widths of the renderer. This appears to happen when the
computed logical width is a fixed and positive value in most cases. RenderBlock has some
additional constraints in order to determine this, but I factored out this logic into a
separate method.
- Otherwise, m_min/maxPreferredLogicalWidths should hold the intrinsic values, so we can just
use the already computed value in m_minPreferredLogicalWidth.
(Also, a quick change of argument names in computePreferredLogicalWidths in the declaration
to match the ones used in the definition.)
* LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/shrink-to-fit-sizing-max-width-min-content-expected.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/shrink-to-fit-sizing-max-width-min-content.html: Added.
* Source/WebCore/rendering/RenderBox.cpp:
(WebCore::RenderBox::shouldComputePreferredLogicalWidthsFromStyle const):
(WebCore::RenderBox::computePreferredLogicalWidths):
* Source/WebCore/rendering/RenderBox.h:
Canonical link: https://commits.webkit.org/286051@main
Canonical link: https://commits.webkit.org/283286.463@safari-7620-branch
Commit: 9ea0c9e649a668189f287cc3fb714462474ba111
https://github.com/WebKit/WebKit/commit/9ea0c9e649a668189f287cc3fb714462474ba111
Author: Chris Dumez <cdumez at apple.com>
Date: 2024-11-08 (Fri, 08 Nov 2024)
Changed paths:
M Source/WebKit/UIProcess/Downloads/DownloadProxy.cpp
M Source/WebKit/UIProcess/Downloads/DownloadProxy.h
M Source/WebKit/UIProcess/Downloads/DownloadProxyMap.cpp
M Source/WebKit/UIProcess/Downloads/DownloadProxyMap.h
M Source/WebKit/UIProcess/Network/NetworkProcessProxy.cpp
Log Message:
-----------
Cherry-pick 9f69376c782b. rdar://139309060
Crash under DownloadProxy::~DownloadProxy()
https://bugs.webkit.org/show_bug.cgi?id=282611
rdar://139309060
Reviewed by Geoffrey Garen.
DownloadProxy is ref-counted and thus can outlive its DownloadProxyMap.
As a result, DownloadProxy cannot hold a CheckedRef to its DownloadProxyMap.
Switching to a WeakPtr instead.
* Source/WebKit/UIProcess/Downloads/DownloadProxy.cpp:
(WebKit::DownloadProxy::cancel):
(WebKit::DownloadProxy::didFinish):
(WebKit::DownloadProxy::didFail):
* Source/WebKit/UIProcess/Downloads/DownloadProxy.h:
* Source/WebKit/UIProcess/Downloads/DownloadProxyMap.cpp:
(WebKit::DownloadProxyMap::ref const):
(WebKit::DownloadProxyMap::deref const):
* Source/WebKit/UIProcess/Downloads/DownloadProxyMap.h:
* Source/WebKit/UIProcess/Network/NetworkProcessProxy.cpp:
(WebKit::NetworkProcessProxy::createDownloadProxy):
Canonical link: https://commits.webkit.org/286182@main
* Source/WebKit/UIProcess/Downloads/DownloadProxy.cpp:
(WebKit::DownloadProxy::cancel):
(WebKit::DownloadProxy::didFinish):
(WebKit::DownloadProxy::didFail):
* Source/WebKit/UIProcess/Downloads/DownloadProxy.h:
* Source/WebKit/UIProcess/Downloads/DownloadProxyMap.cpp:
(WebKit::DownloadProxyMap::ref const):
(WebKit::DownloadProxyMap::deref const):
* Source/WebKit/UIProcess/Downloads/DownloadProxyMap.h:
* Source/WebKit/UIProcess/Network/NetworkProcessProxy.cpp:
(WebKit::NetworkProcessProxy::createDownloadProxy):
Canonical link: https://commits.webkit.org/283286.464@safari-7620-branch
Commit: 33d383c835aa2fb30acb45c7a4102b1f58f767d8
https://github.com/WebKit/WebKit/commit/33d383c835aa2fb30acb45c7a4102b1f58f767d8
Author: Sihui Liu <sihui_liu at apple.com>
Date: 2024-11-08 (Fri, 08 Nov 2024)
Changed paths:
M Source/WebKit/NetworkProcess/storage/CacheStorageCache.cpp
M Source/WebKit/NetworkProcess/storage/CacheStorageDiskStore.cpp
M Source/WebKit/NetworkProcess/storage/CacheStorageManager.h
M Source/WebKit/NetworkProcess/storage/CacheStorageMemoryStore.cpp
A Source/WebKit/NetworkProcess/storage/CacheStorageRecord.cpp
M Source/WebKit/NetworkProcess/storage/CacheStorageRecord.h
M Source/WebKit/NetworkProcess/storage/CacheStorageStore.h
M Source/WebKit/Sources.txt
M Source/WebKit/WebKit.xcodeproj/project.pbxproj
Log Message:
-----------
Cherry-pick 981e412577e1. rdar://138931399
Add assertion in CacheStorageRecordInformation to ensure URL does not have AtomString
https://bugs.webkit.org/show_bug.cgi?id=282307
rdar://138931399
Reviewed by Youenn Fablet.
CrashTracer indicates the assertion in CacheStorageCache::findExistingRecord is hit, which means url in stored records
contains AtomString. This is unexpected because CacheStorageRecordInformation (and its members) stored in
CacheStorageCache::m_records should be created with isolatedCopy(). To figure out how CacheStorageRecordInformation
gets an AtomString URL, this patch makes CacheStorageRecordInformation a class and adds assertions in constructor and
URL setter.
* Source/WebKit/NetworkProcess/storage/CacheStorageCache.cpp:
(WebKit::CacheStorageCache::getSize):
(WebKit::CacheStorageCache::open):
(WebKit::toCacheStorageRecord):
(WebKit::CacheStorageCache::retrieveRecords):
(WebKit::CacheStorageCache::removeRecords):
(WebKit::CacheStorageCache::findExistingRecord):
(WebKit::CacheStorageCache::putRecords):
(WebKit::CacheStorageCache::putRecordsAfterQuotaCheck):
(WebKit::CacheStorageCache::putRecordsInStore):
(WebKit::CacheStorageCache::removeAllRecords):
* Source/WebKit/NetworkProcess/storage/CacheStorageDiskStore.cpp:
(WebKit::readRecordInfoFromFileData):
(WebKit::CacheStorageDiskStore::readRecordsInternal):
(WebKit::CacheStorageDiskStore::deleteRecords):
(WebKit::encodeRecordHeader):
(WebKit::CacheStorageDiskStore::writeRecords):
* Source/WebKit/NetworkProcess/storage/CacheStorageManager.h:
* Source/WebKit/NetworkProcess/storage/CacheStorageMemoryStore.cpp:
(WebKit::CacheStorageMemoryStore::readRecords):
(WebKit::CacheStorageMemoryStore::deleteRecords):
(WebKit::CacheStorageMemoryStore::writeRecords):
* Source/WebKit/NetworkProcess/storage/CacheStorageRecord.cpp: Added.
(WebKit::CacheStorageRecordInformation::CacheStorageRecordInformation):
(WebKit::CacheStorageRecordInformation::updateVaryHeaders):
(WebKit::CacheStorageRecordInformation::isolatedCopy):
(WebKit::CacheStorageRecordInformation::setURL):
* Source/WebKit/NetworkProcess/storage/CacheStorageRecord.h:
(WebKit::CacheStorageRecordInformation::key const):
(WebKit::CacheStorageRecordInformation::insertionTime const):
(WebKit::CacheStorageRecordInformation::identifier const):
(WebKit::CacheStorageRecordInformation::updateResponseCounter const):
(WebKit::CacheStorageRecordInformation::size const):
(WebKit::CacheStorageRecordInformation::url const):
(WebKit::CacheStorageRecordInformation::hasVaryStar const):
(WebKit::CacheStorageRecordInformation::varyHeaders const):
(WebKit::CacheStorageRecordInformation::setKey):
(WebKit::CacheStorageRecordInformation::setSize):
(WebKit::CacheStorageRecordInformation::setIdentifier):
(WebKit::CacheStorageRecordInformation::setUpdateResponseCounter):
(WebKit::CacheStorageRecordInformation::setInsertionTime):
(WebKit::CacheStorageRecordInformation::updateVaryHeaders): Deleted.
(WebKit::CacheStorageRecordInformation::isolatedCopy): Deleted.
* Source/WebKit/NetworkProcess/storage/CacheStorageStore.h:
* Source/WebKit/Sources.txt:
* Source/WebKit/WebKit.xcodeproj/project.pbxproj:
Canonical link: https://commits.webkit.org/285908@main
Canonical link: https://commits.webkit.org/283286.465@safari-7620-branch
Commit: 4d456933d70e63cea4aecf151fcdd6e29081853f
https://github.com/WebKit/WebKit/commit/4d456933d70e63cea4aecf151fcdd6e29081853f
Author: Keith Miller <keith_miller at apple.com>
Date: 2024-11-09 (Sat, 09 Nov 2024)
Changed paths:
M Source/WTF/wtf/LockAlgorithm.h
Log Message:
-----------
LockAlgorithm::unlockFast is too fast
https://bugs.webkit.org/show_bug.cgi?id=282865
rdar://139548123
Reviewed by Yusuke Suzuki.
Right now it has relaxed ordering but that's not correct since it means writes to the critical section
could happen after the lock is unlocked. This could lead to arbitrary crashes or other general badness.
* Source/WTF/wtf/LockAlgorithm.h:
(WTF::LockAlgorithm::unlockFast):
Canonical link: https://commits.webkit.org/283286.466@safari-7620-branch
Commit: fbc1283a4a99df554ec1c031a71f26a85d078b41
https://github.com/WebKit/WebKit/commit/fbc1283a4a99df554ec1c031a71f26a85d078b41
Author: Nitin Mahendru <nitinmahendru at apple.com>
Date: 2024-11-11 (Mon, 11 Nov 2024)
Changed paths:
M LayoutTests/http/wpt/webauthn/public-key-credential-get-failure-hid.https-expected.txt
M LayoutTests/http/wpt/webauthn/public-key-credential-get-failure-hid.https.html
M LayoutTests/http/wpt/webauthn/public-key-credential-get-success-hid.https-expected.txt
M LayoutTests/http/wpt/webauthn/public-key-credential-get-success-hid.https.html
M Source/WebCore/Modules/webauthn/fido/DeviceRequestConverter.cpp
M Source/WebCore/Modules/webauthn/fido/DeviceRequestConverter.h
M Source/WebKit/UIProcess/WebAuthentication/fido/CtapAuthenticator.cpp
M Source/WebKit/UIProcess/WebAuthentication/fido/CtapAuthenticator.h
Log Message:
-----------
Unreviewed, reverting "[WebAuthn] Implement batching for checking allowCredentials (48851c3d135a)"
https://bugs.webkit.org/show_bug.cgi?id=282880
rdar://138281493
Fix Login Issues with newer Yubikeys.
Reverted change:
Cherry-pick 52a47cb. rdar://133711978
[WebAuthn] Implement batching for checking allowCredentials
rdar://133711978
https://bugs.webkit.org/show_bug.cgi?id=277979
Reviewed by Brent Fulgham.
This change implements checking the allowCredentials in batches as supported by
the authenticator during getAssertion. This is accomplished with smaller up=0,
get requests to determine if credentials are present on the authenticator.
Then if a credential is detected as present, it is included in the allowCredentials list
in the real request. If no credentials matched, then we already know the call will not
be able to succeed, so we just include the last batch.
Added layout tests for the new behaviors.
* LayoutTests/http/wpt/webauthn/public-key-credential-get-failure-hid.https-expected.txt:
* LayoutTests/http/wpt/webauthn/public-key-credential-get-failure-hid.https.html:
* LayoutTests/http/wpt/webauthn/public-key-credential-get-success-hid.https-expected.txt:
* LayoutTests/http/wpt/webauthn/public-key-credential-get-success-hid.https.html:
* Source/WebKit/UIProcess/WebAuthentication/fido/CtapAuthenticator.cpp:
(WebKit::CtapAuthenticator::makeCredential):
(WebKit::CtapAuthenticator::continueSlientlyCheckCredentials):
(WebKit::CtapAuthenticator::continueMakeCredentialAfterCheckExcludedCredentials):
(WebKit::CtapAuthenticator::getAssertion):
(WebKit::CtapAuthenticator::continueGetAssertionAfterCheckAllowCredentials):
(WebKit::CtapAuthenticator::continueCheckExcludedCredentialsAfterResponseRecieved): Deleted.
* Source/WebKit/UIProcess/WebAuthentication/fido/CtapAuthenticator.h:
Canonical link: https://commits.webkit.org/282246@main
Canonical link: https://commits.webkit.org/283286.467@safari-7620-branch
Commit: aaafcd1e56877f7a838394aa36a6af97b0616b24
https://github.com/WebKit/WebKit/commit/aaafcd1e56877f7a838394aa36a6af97b0616b24
Author: Nitin Mahendru <nitinmahendru at apple.com>
Date: 2024-11-11 (Mon, 11 Nov 2024)
Changed paths:
M LayoutTests/http/wpt/webauthn/public-key-credential-create-failure-hid.https-expected.txt
M LayoutTests/http/wpt/webauthn/public-key-credential-create-failure-hid.https.html
M LayoutTests/http/wpt/webauthn/public-key-credential-create-success-hid.https-expected.txt
M LayoutTests/http/wpt/webauthn/public-key-credential-create-success-hid.https.html
M LayoutTests/http/wpt/webauthn/resources/util.js
M Source/WebCore/Modules/webauthn/fido/AuthenticatorGetInfoResponse.cpp
M Source/WebCore/Modules/webauthn/fido/AuthenticatorGetInfoResponse.h
M Source/WebCore/Modules/webauthn/fido/DeviceRequestConverter.cpp
M Source/WebCore/Modules/webauthn/fido/DeviceRequestConverter.h
M Source/WebCore/Modules/webauthn/fido/DeviceResponseConverter.cpp
M Source/WebCore/Modules/webauthn/fido/FidoConstants.h
M Source/WebCore/testing/MockWebAuthenticationConfiguration.h
M Source/WebCore/testing/MockWebAuthenticationConfiguration.idl
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
M Source/WebKit/UIProcess/WebAuthentication/Mock/MockHidConnection.cpp
M Source/WebKit/UIProcess/WebAuthentication/fido/CtapAuthenticator.cpp
M Source/WebKit/UIProcess/WebAuthentication/fido/CtapAuthenticator.h
Log Message:
-----------
Unreviewed, reverting [WebAuthn] Implement batching for checking excludeCredentials
https://bugs.webkit.org/show_bug.cgi?id=282878
rdar://138281493
Revert to Fix rdar://138281493 Unable to enter PIN for Yubikey
Reverted change:
Cherry-pick f56198757e4b. rdar://133307666
[WebAuthn] Implement batching for checking excludeCredentials
rdar://133307666
https://bugs.webkit.org/show_bug.cgi?id=277695
Reviewed by Charlie Wolfe.
This change starts to implement checking the excludeCredential list in batches as
supported by the authenticator during a makeCredential. This is accomplished by using
smaller, up=0, get requests to detect if a credential is present on the authenticator.
Then if a credential is detected, only that credential may be included with the actual
makeCredential request to get the proper error code back from the authenticator. If none
matched, we don't need to include a excludeCredentials list to the authenticator since
we already know those credentials aren't present.
This patch only implements this logic for makeCredential, getAssertion will be done in
another patch.
Added layout tests to test matching exclude list with batching, non-matching exclude list with
batching, and a security key that supports batches greater than 1.
* LayoutTests/http/wpt/webauthn/public-key-credential-create-failure-hid.https-expected.txt:
* LayoutTests/http/wpt/webauthn/public-key-credential-create-failure-hid.https.html:
* LayoutTests/http/wpt/webauthn/public-key-credential-create-success-hid.https-expected.txt:
* LayoutTests/http/wpt/webauthn/public-key-credential-create-success-hid.https.html:
* LayoutTests/http/wpt/webauthn/resources/util.js:
* Source/WebCore/Modules/webauthn/fido/AuthenticatorGetInfoResponse.cpp:
(fido::AuthenticatorGetInfoResponse::setMaxCredentialCountInList):
(fido::AuthenticatorGetInfoResponse::setMaxCredentialIDLength):
(fido::encodeAsCBOR):
* Source/WebCore/Modules/webauthn/fido/AuthenticatorGetInfoResponse.h:
* Source/WebCore/Modules/webauthn/fido/DeviceRequestConverter.cpp:
(fido::encodeSilentGetAssertion):
* Source/WebCore/Modules/webauthn/fido/DeviceRequestConverter.h:
* Source/WebCore/Modules/webauthn/fido/DeviceResponseConverter.cpp:
(fido::readCTAPGetInfoResponse):
* Source/WebCore/Modules/webauthn/fido/FidoConstants.h:
* Source/WebCore/testing/MockWebAuthenticationConfiguration.h:
* Source/WebCore/testing/MockWebAuthenticationConfiguration.idl:
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:
* Source/WebKit/UIProcess/WebAuthentication/Mock/MockHidConnection.cpp:
(WebKit::MockHidConnection::feedReports):
* Source/WebKit/UIProcess/WebAuthentication/fido/CtapAuthenticator.cpp:
(WebKit::CtapAuthenticator::makeCredential):
(WebKit::CtapAuthenticator::continueCheckExcludedCredentialsAfterResponseRecieved):
(WebKit::CtapAuthenticator::continueMakeCredentialAfterCheckExcludedCredentials):
* Source/WebKit/UIProcess/WebAuthentication/fido/CtapAuthenticator.h:
Canonical link: https://commits.webkit.org/282019@main
Canonical link: https://commits.webkit.org/280938.236@safari-7619-branch
Canonical link: https://commits.webkit.org/283286.468@safari-7620-branch
Commit: 623304fc8be0a8be53f698c7081bf236fc121615
https://github.com/WebKit/WebKit/commit/623304fc8be0a8be53f698c7081bf236fc121615
Author: Tim Nguyen <ntim at apple.com>
Date: 2024-11-11 (Mon, 11 Nov 2024)
Changed paths:
M Source/WebCore/dom/Document.cpp
M Source/WebCore/dom/Document.h
Log Message:
-----------
Cherry-pick 818287041d80. rdar://139078745
[popover] Light dismiss doesn't work on iOS/iPadOS
https://bugs.webkit.org/show_bug.cgi?id=267688
rdar://121591037
Reviewed by Wenson Hsieh.
Invalidate the event regions when the auto popover list changes so internal code can correctly invalidate event regions.
* Source/WebCore/dom/Document.cpp:
(WebCore::Document::addTopLayerElement):
(WebCore::Document::removeTopLayerElement):
* Source/WebCore/dom/Document.h:
(WebCore::Document::needsPointerEventHandlingForPopover const):
Canonical link: https://commits.webkit.org/285990@main
Commit: 39727612b5429c70e245638c2269dd5a642cd815
https://github.com/WebKit/WebKit/commit/39727612b5429c70e245638c2269dd5a642cd815
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2024-11-11 (Mon, 11 Nov 2024)
Changed paths:
A JSTests/wasm/stress/wasm-bbq-catch-unbind.js
M Source/JavaScriptCore/wasm/WasmBBQJIT.cpp
Log Message:
-----------
[JSC] Aborted in JSC::Wasm::BBQJITImpl::BBQJIT::bind
https://bugs.webkit.org/show_bug.cgi?id=282825
rdar://139502479
Reviewed by David Degazio.
This patch adds unbinding for all registers for addCatch and addCatchAll
too since they also should not carry any bindings from the other blocks.
* JSTests/wasm/stress/wasm-bbq-catch-unbind.js: Added.
* Source/JavaScriptCore/wasm/WasmBBQJIT.cpp:
(JSC::Wasm::BBQJITImpl::BBQJIT::addCatch):
(JSC::Wasm::BBQJITImpl::BBQJIT::addCatchAll):
Canonical link: https://commits.webkit.org/283286.470@safari-7620-branch
Commit: 374b5e1de0e55db8ad97e2f0042b3e4db5a67363
https://github.com/WebKit/WebKit/commit/374b5e1de0e55db8ad97e2f0042b3e4db5a67363
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2024-11-11 (Mon, 11 Nov 2024)
Changed paths:
M LayoutTests/TestExpectations
A LayoutTests/compositing/repaint/sticky-repaint-on-scroll-expected.txt
A LayoutTests/compositing/repaint/sticky-repaint-on-scroll.html
M LayoutTests/platform/mac-wk2/TestExpectations
M Source/WebCore/rendering/RenderLayer.cpp
M Source/WebCore/rendering/RenderLayer.h
Log Message:
-----------
Cherry-pick 6a6822efc75a. rdar://139100667
Excessive repainting when scrolling position:sticky in some configurations
https://bugs.webkit.org/show_bug.cgi?id=280316
rdar://120280327
Reviewed by Alan Baradlay.
https://www.stripe.press/poor-charlies-almanack/talk-one has a tiled `position:sticky` element
which repaints on every scroll. This happens when `RenderLayer::recursiveUpdateLayerPositionsAfterScroll()`
and `RenderLayer::recursiveUpdateLayerPositions()` have different criteria for the `clearRepaintRects()`
condition; the former was testing `!isVisuallyNonEmpty()` and the latter just `m_hasVisibleContent`.
The fix is to have both code paths use a new `isVisibilityHiddenOrOpacityZero()` which just does the
simple check for the visibility and opacity properties. This shouldn't cause much new repainting, because
`recursiveUpdateLayerPositionsAfterScroll()` was doing the stricter check, and we'll almost always do layout
after scroll.
The test requires async scrolling (programmatic scrolling triggers layouts on every scroll as the layout viewport changes).
* LayoutTests/TestExpectations:
* LayoutTests/compositing/repaint/sticky-repaint-on-scroll-expected.txt: Added.
* LayoutTests/compositing/repaint/sticky-repaint-on-scroll.html: Added.
* LayoutTests/platform/mac-wk2/TestExpectations:
* Source/WebCore/rendering/RenderLayer.cpp:
(WebCore::RenderLayer::calculateClipRects const):
Canonical link: https://commits.webkit.org/284802@main
Canonical link: https://commits.webkit.org/283286.471@safari-7620-branch
Commit: 4b2e2acdc4e2848027d9200d4831b3361f592108
https://github.com/WebKit/WebKit/commit/4b2e2acdc4e2848027d9200d4831b3361f592108
Author: Sammy Gill <sammy.gill at apple.com>
Date: 2024-11-12 (Tue, 12 Nov 2024)
Changed paths:
A LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/intrinsic-fixed-width-with-max-content-height-expected.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/intrinsic-fixed-width-with-max-content-height.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/intrinsic-fixed-width-with-min-content-height-expected.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/intrinsic-fixed-width-with-min-content-height.html
M Source/WebCore/rendering/RenderBox.cpp
M Source/WebCore/rendering/RenderBoxInlines.h
M Source/WebCore/rendering/RenderReplaced.cpp
M Source/WebCore/rendering/RenderReplaced.h
Log Message:
-----------
Cherry-pick 7a3aefde0128. rdar://139717026
walzr.com: Images are vertically stretched.
https://bugs.webkit.org/show_bug.cgi?id=282634
rdar://137063317
Reviewed by Alan Baradlay.
Images on walzr.com have a fixed width and a computed height of min-content, which is
causing them to vertically stretch.
css-box-sizing-3 defines the min-content size to be: "the size it would have if it was a
float given an auto preferred size in that axis (and no minimum or maximum size in that
axis) and if its containing block was zero-sized in that axis."
CSS2 defines finding the logical height for floating replaced elements. If the width
is a non-auto computed width, a computed width of auto, and an intrinsic ratio, then
the logical height is computed via the aspect ratio.
RenderBox::computeIntrinsicLogicalContentHeightUsing was simply returning the intrinsic
logical height, which was not correct. Let's adjust this by adding some new logic to handle
this specific case for images and fall back to other types of content. We also will fall
back to the old logic if an aspect ratio is specified via the aspect-ratio property.
The max-content size is defined similarly (with a difference in the containing block
size for the float) so let's handle it here too.
https://drafts.csswg.org/css-sizing-3/#intrinsic-sizes
https://drafts.csswg.org/css2/#inline-replaced-height
* LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/intrinsic-fixed-width-with-max-content-height-expected.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/intrinsic-fixed-width-with-max-content-height.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/intrinsic-fixed-width-with-min-content-height-expected.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/intrinsic-fixed-width-with-min-content-height.html: Added.
* Source/WebCore/rendering/RenderBox.cpp:
(WebCore::RenderBox::computeIntrinsicLogicalContentHeightUsing const):
* Source/WebCore/rendering/RenderBoxInlines.h:
(WebCore::resolveHeightForRatio):
* Source/WebCore/rendering/RenderReplaced.cpp:
(WebCore::RenderReplaced::paint):
* Source/WebCore/rendering/RenderReplaced.h:
Canonical link: https://commits.webkit.org/286284@main
Canonical link: https://commits.webkit.org/283286.472@safari-7620-branch
Commit: c5e92067cac8ffcdd07a2acd7188abf56999f9f1
https://github.com/WebKit/WebKit/commit/c5e92067cac8ffcdd07a2acd7188abf56999f9f1
Author: David Kilzer <ddkilzer at apple.com>
Date: 2024-11-12 (Tue, 12 Nov 2024)
Changed paths:
M Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/mtl_library_cache.mm
M Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/mtl_utils.mm
Log Message:
-----------
Cherry-pick 8826887be8c6. rdar://139671574
[ANGLE] Fix leaks in NewMetalLibraryFromMetallib() on every call
<https://bugs.webkit.org/show_bug.cgi?id=282890>
<rdar://139586222>
Reviewed by Kimmo Kinnunen.
* Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/mtl_library_cache.mm:
(rx::(anonymous)::NewMetalLibraryFromMetallib):
- Use adoptObjCObj() to fix leak of id<MTLLibrary>.
- Call dispatch_release() to fix leak of dispatch_data_t.
* Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/mtl_utils.mm:
(rx::mtl::CreateShaderLibraryFromBinary):
- Use DISPATCH_DATA_DESTRUCTOR_DEFAULT instead of empty block.
- Replace ANGLE_MTL_AUTORELEASE with adoptObjCObj() to avoid unneeded
autorelease of id<MTLLibrary> object.
Canonical link: https://commits.webkit.org/286425@main
Canonical link: https://commits.webkit.org/283286.473@safari-7620-branch
Commit: 9700aa3440922413fe1ee8b2631fcf68a6a6e392
https://github.com/WebKit/WebKit/commit/9700aa3440922413fe1ee8b2631fcf68a6a6e392
Author: Sammy Gill <sammy.gill at apple.com>
Date: 2024-11-12 (Tue, 12 Nov 2024)
Changed paths:
A LayoutTests/imported/w3c/web-platform-tests/css/css-contain/content-visibility/content-visibility-auto-svg-text-expected.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-contain/content-visibility/content-visibility-auto-svg-text.html
M Source/WebCore/rendering/svg/RenderSVGText.cpp
M Source/WebCore/rendering/svg/RenderSVGText.h
Log Message:
-----------
Cherry-pick 84a4a18b9d5d. rdar://139667754
thesession.org: [content-visibility] SVG text not shown in content-visibility: auto subtree.
https://bugs.webkit.org/show_bug.cgi?id=281570
rdar://138040315
Reviewed by Alan Baradlay.
RenderSVGText expects to be able to perform some sort of initialization on its first pass
of layout by checking everHadLayout(). Unfortunately, if this renderer is in a
content-visibility: auto subtree, the content-visibility logic will descend down that
subtree, clearing layout on all the renderers, which ends up setting the "ever had layout,"
bit. This ends up confusing RenderSVGText since it thinks it has gone through layout and
assumes that it had performed this initialization, which can result in us not computing
the proper geometry for the content.
To address this, let's keep track of a bit on RenderSVGText that indicates if it has ever
performed a full pass of layout. We can use this in the same places we were previously
using everHadLayout().
* LayoutTests/imported/w3c/web-platform-tests/css/css-contain/content-visibility/content-visibility-auto-svg-text-expected.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-contain/content-visibility/content-visibility-auto-svg-text.html: Added.
* Source/WebCore/rendering/svg/RenderSVGText.cpp:
(WebCore::RenderSVGText::shouldHandleSubtreeMutations const):
(WebCore::RenderSVGText::subtreeTextDidChange):
(WebCore::RenderSVGText::layout):
* Source/WebCore/rendering/svg/RenderSVGText.h:
Canonical link: https://commits.webkit.org/286447@main
Canonical link: https://commits.webkit.org/283286.474@safari-7620-branch
Commit: ded4d02c0a93af990ed12b26254876bdb072f7e7
https://github.com/WebKit/WebKit/commit/ded4d02c0a93af990ed12b26254876bdb072f7e7
Author: Daniel Liu <danlliu at umich.edu>
Date: 2024-11-13 (Wed, 13 Nov 2024)
Changed paths:
M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp
Log Message:
-----------
Don't allocate DFG register after a slow path
https://bugs.webkit.org/show_bug.cgi?id=283063
rdar://139747120
Reviewed by Yusuke Suzuki.
Allocating a DFG register after a slow path means that if the slow path
is taken, we end up with an incorrect global state.
* Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
Canonical link: https://commits.webkit.org/283286.475@safari-7620-branch
Commit: 0be2067be05a7eb0f69954361498371f63683304
https://github.com/WebKit/WebKit/commit/0be2067be05a7eb0f69954361498371f63683304
Author: Gerald Squelart <g_squelart at apple.com>
Date: 2024-11-13 (Wed, 13 Nov 2024)
Changed paths:
M Source/WebCore/accessibility/AXRemoteFrame.h
M Source/WebCore/accessibility/mac/AccessibilityObjectMac.mm
Log Message:
-----------
AXRemoteFrame::generateRemoteToken() should return a Vector
https://bugs.webkit.org/show_bug.cgi?id=281327
rdar://137766980
Reviewed by Timothy Hatcher.
Copy the data out of the local NSData.
* Source/WebCore/accessibility/AXRemoteFrame.h:
* Source/WebCore/accessibility/mac/AccessibilityObjectMac.mm:
(WebCore::AXRemoteFrame::generateRemoteToken const):
Canonical link: https://commits.webkit.org/283286.476@safari-7620-branch
Commit: 2815b4e29829932824e4da59bfc60fce9421d4ee
https://github.com/WebKit/WebKit/commit/2815b4e29829932824e4da59bfc60fce9421d4ee
Author: Charlie Wolfe <charliew at apple.com>
Date: 2024-11-14 (Thu, 14 Nov 2024)
Changed paths:
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp
M Source/WebKit/NetworkProcess/NetworkProcess.cpp
M Source/WebKit/NetworkProcess/NetworkProcess.h
M Source/WebKit/NetworkProcess/NetworkSession.cpp
M Source/WebKit/NetworkProcess/ServiceWorker/WebSWServerConnection.cpp
M Source/WebKit/NetworkProcess/SharedWorker/WebSharedWorkerServerConnection.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/IPCTestingAPI.mm
Log Message:
-----------
Data Isolation bypass via attacker controlled firstPartyForCookies
https://bugs.webkit.org/show_bug.cgi?id=283095
rdar://139818629
Reviewed by Matthew Finkel and Alex Christensen.
`NetworkProcess::allowsFirstPartyForCookies` unconditionally allows cookie access for about:blank or
empty firstPartyForCookies URLs. We tried to remove this in rdar://105733798 and rdar://107270673, but
we needed to revert both because there were rare and subtle bugs where certain requests would incorrectly
have about:blank set as their firstPartyForCookies, causing us to kill the WCP.
This patch is a lower risk change that removes the unconditional cookie access for requests that have an
empty firstPartyForCookies, but will not kill the WCP that is incorrectly sending an empty
firstPartyForCookies.
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:
(WebKit::NetworkConnectionToWebProcess::createSocketChannel):
(WebKit::NetworkConnectionToWebProcess::scheduleResourceLoad):
(WebKit::NetworkConnectionToWebProcess::cookiesForDOM):
(WebKit::NetworkConnectionToWebProcess::setCookiesFromDOM):
(WebKit::NetworkConnectionToWebProcess::cookiesEnabled):
(WebKit::NetworkConnectionToWebProcess::cookieRequestHeaderFieldValue):
(WebKit::NetworkConnectionToWebProcess::getRawCookies):
(WebKit::NetworkConnectionToWebProcess::cookiesForDOMAsync):
(WebKit::NetworkConnectionToWebProcess::setCookieFromDOMAsync):
(WebKit::NetworkConnectionToWebProcess::domCookiesForHost):
(WebKit::NetworkConnectionToWebProcess::establishSWContextConnection):
* Source/WebKit/NetworkProcess/NetworkProcess.cpp:
(WebKit::NetworkProcess::allowsFirstPartyForCookies):
* Source/WebKit/NetworkProcess/NetworkProcess.h:
* Source/WebKit/NetworkProcess/NetworkSession.cpp:
(WebKit::NetworkSession::addAllowedFirstPartyForCookies):
* Source/WebKit/NetworkProcess/ServiceWorker/WebSWServerConnection.cpp:
(WebKit::WebSWServerConnection::scheduleJobInServer):
* Source/WebKit/NetworkProcess/SharedWorker/WebSharedWorkerServerConnection.cpp:
(WebKit::WebSharedWorkerServerConnection::requestSharedWorker):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/IPCTestingAPI.mm:
(EmptyFirstPartyForCookiesCookieRequestHeaderFieldValue)):
Canonical link: https://commits.webkit.org/283286.477@safari-7620-branch
Commit: 2d1b510c05b15f74d04c39fe981e2d3cbe1aca78
https://github.com/WebKit/WebKit/commit/2d1b510c05b15f74d04c39fe981e2d3cbe1aca78
Author: Youenn Fablet <youenn at apple.com>
Date: 2024-11-14 (Thu, 14 Nov 2024)
Changed paths:
M LayoutTests/TestExpectations
M Source/WebCore/platform/mediastream/mac/CoreAudioSharedUnit.cpp
Log Message:
-----------
iOS 18.2 - WebRTC audio input device issues
rdar://139797608
Reviewed by Jean-Yves Avenard.
When stopping capture, if audio rendering is ongoing with VPIO, we were setting kAUVoiceIOProperty_MuteOutput to 1.
This is new in CrystalC code base and is in preparation of supporting voice activity detection.
We were correctly setting kAUVoiceIOProperty_MuteOutput back to 0 if we were keeping the same VPIO unit when restarting.
It appears kAUVoiceIOProperty_MuteOutput is sticky so we would need to set kAUVoiceIOProperty_MuteOutput back to 0 on the new unit.
Instead, we are removing the setting of kAUVoiceIOProperty_MuteOutput.
Setting kAUVoiceIOProperty_MuteOutput is useful to enable muted talker detection, which is a future feature, not available in this branch.
There is no such issue in WebKit trunk since, after the fork to this branch, we added explicit mute setting via [AVAudioApplication setInputMuted:error:].
Marking http/wpt/mediasession/voiceActivityDetection.html as failing since we no longer instruct the mock audio unit that the output is muted.
Manually tested on iOS.
* LayoutTests/TestExpectations:
* Source/WebCore/platform/mediastream/mac/CoreAudioSharedUnit.cpp:
(WebCore::CoreAudioSharedUnit::isProducingMicrophoneSamplesChanged):
Canonical link: https://commits.webkit.org/283286.478@safari-7620-branch
Commit: bc5fc1e127bd174825f771355a7a7f74a6bfbc78
https://github.com/WebKit/WebKit/commit/bc5fc1e127bd174825f771355a7a7f74a6bfbc78
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2024-11-14 (Thu, 14 Nov 2024)
Changed paths:
A LayoutTests/compositing/scrolling/transformed-clipping-inside-scroller-expected.html
A LayoutTests/compositing/scrolling/transformed-clipping-inside-scroller.html
M LayoutTests/compositing/transforms/3d-transformed-fixed.html
M Source/WebCore/rendering/RenderLayer.cpp
M Source/WebCore/rendering/RenderLayer.h
Log Message:
-----------
Cherry-pick b56addc7fbfd. rdar://139100623
Overflow:hidden fails on a transformed element inside overflow scroll (affects motionpictures.org, www.bogleheads.org)
https://bugs.webkit.org/show_bug.cgi?id=281073
rdar://66751438
Reviewed by Alan Baradlay.
When `paintLayerByApplyingTransform()` paints a layer with a transform, that layer becomes a painting
root, which means that clip rects are computed relative to it. However, `RenderLayer::calculateRects()`
has logic that is conditional on a layer being the painting root and `clipRectsContext.respectOverflowClip()`
being unset, resulting in the clip being ignored. `clipRectsContext.respectOverflowClip()` is false for all descendants
of content being painted into an overflow scroller (see `clipRectOptionsForPaintingOverflowContents`).
So a transformed and clipped element inside an overflow scroller would fail to apply the clipping.
Fix this in `paintLayerByApplyingTransform`, since that's the only place we reset the painting root,
by clearing the `PaintLayerFlag::PaintingOverflowContents` painting flag.
Also rename `clipRectOptionsForPaintingOverflowControls`, since it's about painting content inside
overflow, not about overflow controls.
* LayoutTests/compositing/scrolling/transformed-clipping-inside-scroller-expected.html: Added.
* LayoutTests/compositing/scrolling/transformed-clipping-inside-scroller.html: Added.
* LayoutTests/compositing/transforms/3d-transformed-fixed.html: Just add some pixel tolerance so it passes on my machine.
* Source/WebCore/rendering/RenderLayer.cpp:
(WebCore::RenderLayer::paintLayerWithEffects):
(WebCore::RenderLayer::paintLayerContents):
(WebCore::RenderLayer::paintLayerByApplyingTransform):
(WebCore::RenderLayer::paintTransformedLayerIntoFragments):
* Source/WebCore/rendering/RenderLayer.h:
Canonical link: https://commits.webkit.org/284872@main
Canonical link: https://commits.webkit.org/283286.479@safari-7620-branch
Commit: ededfc5bd7a0eff2fb3ea0481da90fa44566a615
https://github.com/WebKit/WebKit/commit/ededfc5bd7a0eff2fb3ea0481da90fa44566a615
Author: Sammy Gill <sammy.gill at apple.com>
Date: 2024-11-14 (Thu, 14 Nov 2024)
Changed paths:
A LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/aspect-ratio/grid-aspect-ratio-align-items-center-expected.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/aspect-ratio/grid-aspect-ratio-align-items-center.html
M Source/WebCore/rendering/RenderGrid.cpp
Log Message:
-----------
Cherry-pick 30864f828c21. rdar://139717241
[Grid][aspect-ratio] Block size computed from aspect ratio is definite for grid layout.
https://bugs.webkit.org/show_bug.cgi?id=282764
rdar://139444773
Reviewed by Brent Fulgham.
If a grid computes its block size from its inline size and aspect ratio, then that block
size should be treated as definite for the purposes of grid layout. In the attached test
case, the grid computes its inline size from the available space and its resulting block
size from that and the 1/1 aspect ratio.
While the grid ends up getting sized correctly in the end, we fail to take into
consideration this definite size for grid layout, which could have a result of not properly
aligning items correctly. This can be seen in the state-of-html-2024 survey within a button
to delete series from filters.
Let's fix this by expanding hasDefiniteLogicalHeight to consider
logical heights computed from the aspect ratio. Later on during grid layout, we will recognize
this, compute a logical height from the aspect ratio, and use it for the purposes of
row sizing.
Aside: In theory, we should be able to resolve this by hoisting up updateLogicalWidth
to right before we compute hasDefiniteLogicalHeight, and it should get resolved in
RenderBlock::hasDefiniteLogicalHeight, which already has logic to handle this scenario.
Sadly, this does not quite work, however, because that logic ends up bailing out early if the
grid's preferredLogicalWidths bits are dirty even if we do not use them for layout.
* LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/aspect-ratio/grid-aspect-ratio-align-items-center-expected.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/aspect-ratio/grid-aspect-ratio-align-items-center.html: Added.
* Source/WebCore/rendering/RenderGrid.cpp:
(WebCore::RenderGrid::layoutGrid):
Canonical link: https://commits.webkit.org/286367@main
Canonical link: https://commits.webkit.org/283286.480@safari-7620-branch
Commit: 8afb258777fa0b5fddad83ca8141d2296c2ee978
https://github.com/WebKit/WebKit/commit/8afb258777fa0b5fddad83ca8141d2296c2ee978
Author: Ben Nham <nham at apple.com>
Date: 2024-11-15 (Fri, 15 Nov 2024)
Changed paths:
M Source/WebKit/webpushd/WebClipCache.mm
Log Message:
-----------
Cherry-pick ddd3cb9235ec. rdar://139920825
Work around issue with empty web clip directories in webpushd
https://bugs.webkit.org/show_bug.cgi?id=283123
rdar://139887816
Reviewed by Brady Eidson.
There is an OS bug which sometimes leaves empty or nearly-empty web clip directories around, which
breaks the logic of WebClipCache in webpushd. Work around this by checking for the existence of the
Info.plist inside the directory rather than just the existence of the directory.
* Source/WebKit/webpushd/WebClipCache.mm: (WebPushD::webClipExists):
Canonical link: https://commits.webkit.org/286603@main
Canonical link: https://commits.webkit.org/283286.481@safari-7620-branch
Commit: 292b438326e4714abc9e77b22873c14348aa6371
https://github.com/WebKit/WebKit/commit/292b438326e4714abc9e77b22873c14348aa6371
Author: Marta Darbinyan <darbinyan at apple.com>
Date: 2024-11-15 (Fri, 15 Nov 2024)
Changed paths:
M LayoutTests/platform/mac-wk2/TestExpectations
Log Message:
-----------
[ Gardening ]: ASSERTION FAILED: !m_messageReceiverMapCount in http/tests/navigation/page-cache-mediastream.html)
rdar://139687069
Unreviewed test gardening
* LayoutTests/platform/mac-wk2/TestExpectations:
Canonical link: https://commits.webkit.org/283286.482@safari-7620-branch
Commit: 62c6fe3761c08c4e0dd385c52fd880cdc80811b2
https://github.com/WebKit/WebKit/commit/62c6fe3761c08c4e0dd385c52fd880cdc80811b2
Author: Tim Nguyen <ntim at apple.com>
Date: 2024-11-15 (Fri, 15 Nov 2024)
Changed paths:
M Source/WebCore/page/Quirks.cpp
M Source/WebCore/page/Quirks.h
M Source/WebCore/style/StyleAdjuster.cpp
Log Message:
-----------
Cherry-pick b4b8ac3e73af. rdar://139717363
Cherry-pick 331f6e1deec3. rdar://139523759
REGRESSION(282068 at main): Flashing scrollbar on Spotify when hovering the fullscreen button
https://bugs.webkit.org/show_bug.cgi?id=282793
rdar://138918575
Reviewed by Simon Fraser.
The temporary glitch is a pre-existing unstable layout bug that was papered over using body::-webkit-scrollbar { display: none } as a workaround.
Spotify also uses body { scrollbar-width: none }, and per-spec, any non-default scrollbar-width value makes ::-webkit-scrollbar styling ineffective, so this workaround no longer works.
While we investigate the root issue further, make a quirk to make `scrollbar-width: none` no-op on body for now, to address the customer issue.
* Source/WebCore/page/Quirks.cpp:
(WebCore::Quirks::needsBodyScrollbarWidthNoneDisabledQuirk const):
* Source/WebCore/page/Quirks.h:
* Source/WebCore/style/StyleAdjuster.cpp:
(WebCore::Style::Adjuster::adjustForSiteSpecificQuirks const):
Canonical link: https://commits.webkit.org/286350@main
Canonical link: https://commits.webkit.org/283286.452@safari-7620.1.16.11-branch
Canonical link: https://commits.webkit.org/283286.483@safari-7620-branch
Commit: e0ab51a432a47bbd2ad73914c72477c26f0a0a77
https://github.com/WebKit/WebKit/commit/e0ab51a432a47bbd2ad73914c72477c26f0a0a77
Author: Ben Nham <nham at apple.com>
Date: 2024-11-15 (Fri, 15 Nov 2024)
Changed paths:
M Source/WebKit/UIProcess/API/Cocoa/_WKWebPushAction.h
M Source/WebKit/UIProcess/API/Cocoa/_WKWebPushAction.mm
Log Message:
-----------
Cherry-pick 6a3a4d8dc9e4. rdar://139491219
Expose webClipIdentifier on WKWebPushAction
https://bugs.webkit.org/show_bug.cgi?id=282725
rdar://136386764
Reviewed by Sihui Liu.
When an app is activated as a result of a notification from a service worker on iOS, the embedder
currently has to figure out the identifier of the associated web clip on its own. This should be
moved in to WKWebPushAction instead so it doesn't have to be duplicated.
* Source/WebKit/UIProcess/API/Cocoa/_WKWebPushAction.h:
* Source/WebKit/UIProcess/API/Cocoa/_WKWebPushAction.mm:
(uuidFromPushPartition):
(+[_WKWebPushAction webPushActionWithDictionary:]):
(+[_WKWebPushAction _webPushActionWithNotificationResponse:]):
Canonical link: https://commits.webkit.org/286316@main
Commit: 7e31cbf39411e28d46d46b818bb80909f15b6d9b
https://github.com/WebKit/WebKit/commit/7e31cbf39411e28d46d46b818bb80909f15b6d9b
Author: Mohsin Qureshi <mohsinq at apple.com>
Date: 2024-11-15 (Fri, 15 Nov 2024)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7620.2.2
Canonical link: https://commits.webkit.org/283286.485@safari-7620-branch
Commit: c44b1c0fb102be9fe48946618569a3b14ae16eac
https://github.com/WebKit/WebKit/commit/c44b1c0fb102be9fe48946618569a3b14ae16eac
Author: Abrar Rahman Protyasha <a_protyasha at apple.com>
Date: 2024-11-17 (Sun, 17 Nov 2024)
Changed paths:
M Source/WebCore/bindings/js/JSDOMPromiseDeferred.h
Log Message:
-----------
Cherry-pick 284560 at main (01c06ea002c2). rdar://140038002
JSDOMPromiseDeferred.h:307:20: "error: use 'template' keyword to treat 'resolve' as a dependent template name" with some Clang versions
https://bugs.webkit.org/show_bug.cgi?id=280744
rdar://136932730
Reviewed by Darin Adler.
In some Clang versions, we get the following error diagnostic:
```
JSDOMPromiseDeferred.h:307:20: error: use 'template' keyword to treat 'resolve' as a dependent template name
307 | m_promise->resolve<IDLType>(std::forward<typename IDLType::ParameterType>(value));
| ^
| template
```
This is a valid error because `m_promise` is indeed a member template
specialization and the `resolve()` call explicitly depends on a template
parameter.
We fix this by prepending the `resolve()` call with keyword `template`.
c.f. ISO C++23 13.3.3.4.
* Source/WebCore/bindings/js/JSDOMPromiseDeferred.h:
(WebCore::DOMPromiseDeferred::resolve):
Canonical link: https://commits.webkit.org/284560@main
Canonical link: https://commits.webkit.org/283286.486@safari-7620-branch
Commit: 250da3ba3c5d9de94db0dd6cf1840569250b0aae
https://github.com/WebKit/WebKit/commit/250da3ba3c5d9de94db0dd6cf1840569250b0aae
Author: Qianlang Chen <qianlangchen at apple.com>
Date: 2024-11-18 (Mon, 18 Nov 2024)
Changed paths:
A LayoutTests/inspector/css/setStyleText-expected.txt
A LayoutTests/inspector/css/setStyleText.html
M Source/WebCore/inspector/InspectorStyleSheet.cpp
M Source/WebCore/inspector/InspectorStyleSheet.h
M Source/WebCore/inspector/agents/InspectorCSSAgent.cpp
Log Message:
-----------
Cherry-pick 227d5b5816c0. rdar://139999131
Web Inspector: Glitches when trying to edit a style from a style sheet that has an @import statement
rdar://125185110
https://bugs.webkit.org/show_bug.cgi?id=271403
Reviewed by BJ Burg.
This commit optimizes the handling of CSS.setStyleText by using CSSOM
to update the style declaration text directly, to avoid re-parsing the
entire style sheet.
The observed glitch is a combination of two bugs, both due to having to
re-parse for any style edits:
1. In the backend, when a style sheet with @import statements is
re-parsed, it (not just the @import-ed ones) may get removed and
re-added, causing the CSS agent to mistakenly send
StyleSheetRemoved and StyleSheetAdded events for that parent
style sheet. (https://webkit.org/b/279773)
2. Due to @import-ed style sheets receiving new IDs as a result of
re-parsing, the frontend thinks any edit to the parent style sheet
is a "significant change." (Source: https://github.com/WebKit/WebKit/blob/24b5b087d18d4baa487dd73905c46589fa353da3/Source/WebInspectorUI/UserInterface/Models/DOMNodeStyles.js#L267)
Handling a significant change triggers a re-render of the entire
styles panel.
Adjacent to this glitch, there's another notable consequence involving
re-parsing:
3. Re-parsing an @import-ed style sheet uses its original text from
its source, meaning editing the parent style sheet will suddenly
revert all edits made to any @import-ed style sheets.
By avoiding re-parsing for style declaration edits, we fix the immediate
glitch in the simplest fashion and move towards a more efficient
approach to handle editing. This commit is a step in the direction of
eliminating re-parsing for all style editing functions in the inspector:
1. Editing the style declaration text is addressed by this PR.
2. Editing the header of a style rule is already done through CSSOM: https://github.com/WebKit/WebKit/blob/6277bccb19de5ebd68797f369f8ff24fc4417f2e/Source/WebCore/inspector/InspectorStyleSheet.cpp#L1116-L1119.
3. Editing the header of a non-style rule isn't directly supported by
CSSOM but can be achieved equivalently by removing and
re-inserting the updated rule using CSSOM.
4. Adding and 5. removing rules can be optimized to use CSSOM in a
similar way to this patch.
(Functions 3, 4, and 5 may still malfunction with @import rules after
this patch due to https://webkit.org/b/279773 as they're still done by
re-parsing.)
* Source/WebCore/inspector/InspectorStyleSheet.h:
* Source/WebCore/inspector/InspectorStyleSheet.cpp:
(WebCore::computeCanonicalRuleText):
(WebCore::InspectorStyleSheet::setRuleStyleText):
- Still canonicalize the rule body text to enable showing it in the
Sources tab, but don't re-parse the whole style sheet just to apply
the styles. Use CSSOM's support for that.
(WebCore::InspectorStyleSheetForInlineStyle::setRuleStyleText):
- Adapt to the signature change of setRuleStyleText.
(WebCore::InspectorStyleSheet::styleSheetTextWithChangedStyle): Deleted.
- Unused.
* Source/WebCore/inspector/agents/InspectorCSSAgent.cpp:
- Add field to record the old rule body text to enable faithful
undoing.
* LayoutTests/inspector/css/setStyleText-expected.txt: Added.
* LayoutTests/inspector/css/setStyleText.html: Added.
Canonical link: https://commits.webkit.org/283950@main
Canonical link: https://commits.webkit.org/283286.487@safari-7620-branch
Commit: d2944cc2b5259158796ac28c07e87cb1b2c306f4
https://github.com/WebKit/WebKit/commit/d2944cc2b5259158796ac28c07e87cb1b2c306f4
Author: Mike Wyrzykowski <mwyrzykowski at apple.com>
Date: 2024-11-18 (Mon, 18 Nov 2024)
Changed paths:
M Source/ThirdParty/ANGLE/src/libANGLE/Framebuffer.cpp
M Source/ThirdParty/ANGLE/src/libANGLE/Framebuffer.h
M Source/WebCore/Modules/webxr/WebXROpaqueFramebufferCocoa.cpp
Log Message:
-----------
Cherry-pick 2aa166d7c00b. rdar://140087837
noclip.website appears broken in Safari 18
https://bugs.webkit.org/show_bug.cgi?id=280799
rdar://137643297
Reviewed by Ada Chan.
Partial revert of 280236 at main to so invalidateFramebuffer()
works as expected.
* Source/ThirdParty/ANGLE/src/libANGLE/Framebuffer.cpp:
(gl::Framebuffer::discard):
(gl::Framebuffer::invalidate):
(gl::Framebuffer::markDrawAttachmentsNeedInit): Deleted.
* Source/ThirdParty/ANGLE/src/libANGLE/Framebuffer.h:
* Source/WebCore/Modules/webxr/WebXROpaqueFramebufferCocoa.cpp:
(WebCore::WebXROpaqueFramebuffer::startFrame):
Canonical link: https://commits.webkit.org/286127@main
Canonical link: https://commits.webkit.org/283286.488@safari-7620-branch
Commit: cf3bded050f6e96c0c6bde6a39424df18ff9b72d
https://github.com/WebKit/WebKit/commit/cf3bded050f6e96c0c6bde6a39424df18ff9b72d
Author: Nitin Mahendru <nitinmahendru at apple.com>
Date: 2024-11-18 (Mon, 18 Nov 2024)
Changed paths:
M Source/WebCore/page/Quirks.cpp
Log Message:
-----------
Cherry-pick 22044c785a3a. rdar://140002804
[bing.com] Disable back/forward cache for image search dialog.
https://bugs.webkit.org/show_bug.cgi?id=281856
rdar://133223599
Reviewed by Chris Dumez.
Disable the cache when the specific dialogue that causes a spinner is visible.
The cached page causes a spinner and the close(cross) button handler will not work
when loaded from the cache for some reason.
* Source/WebCore/page/Quirks.cpp:
(WebCore::Quirks::shouldBypassBackForwardCache const):
Canonical link: https://commits.webkit.org/285526@main
Canonical link: https://commits.webkit.org/283286.489@safari-7620-branch
Commit: b73bb2e7df41765511aaff39dac1513f1d0da697
https://github.com/WebKit/WebKit/commit/b73bb2e7df41765511aaff39dac1513f1d0da697
Author: Aditya Keerthi <akeerthi at apple.com>
Date: 2024-11-18 (Mon, 18 Nov 2024)
Changed paths:
M Source/WebCore/editing/cocoa/EditorCocoa.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/AdaptiveImageGlyph.mm
Log Message:
-----------
Cherry-pick 3102843f9dd6. rdar://140047107
[Cocoa] Genmoji viewed in Gmail and other web mail clients are very large
https://bugs.webkit.org/show_bug.cgi?id=283202
rdar://137165281
Reviewed by Abrar Rahman Protyasha.
In places where Genmoji aren't fully supported, a fallback PNG is displayed
instead. Currently, this fallback is created using the first frame of the
HEIC file that represents a Genmoji. This is problematic, since the size of
the first frame can be inconsistent, and can be quite large, looking very
out of place alongside text.
To fix, create the PNG at a much smaller fixed size. Note that this can
still result in inconsistencies between font size / fallback size, if the
text itself is larger. That issue is out of scope for this change, since
the only general solution is to recreate a PNG every time the used font size
is changed. A partial solution is to offer a post-processing step prior to
sending out an email, but that would only benefit clients that knew to
perform the post-processing step (potentially Apple Mail).
* Source/WebCore/editing/cocoa/EditorCocoa.mm:
(WebCore::fallbackImageForMultiRepresentationHEIC):
(WebCore::Editor::insertMultiRepresentationHEIC):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/AdaptiveImageGlyph.mm:
(TestWebKitAPI::TEST(AdaptiveImageGlyph, InsertAndRemoveWKAttachments)):
(TestWebKitAPI::TEST(AdaptiveImageGlyph, InsertWKAttachmentsCopyFromWebViewPasteToWebView)):
(TestWebKitAPI::TEST(AdaptiveImageGlyph, InsertWKAttachmentsMovingParagraphs)):
Canonical link: https://commits.webkit.org/286692@main
Canonical link: https://commits.webkit.org/283286.490@safari-7620-branch
Commit: ae369124fc38dbb7aabef9bdd44e051b0549d289
https://github.com/WebKit/WebKit/commit/ae369124fc38dbb7aabef9bdd44e051b0549d289
Author: Sihui Liu <sihui_liu at apple.com>
Date: 2024-11-18 (Mon, 18 Nov 2024)
Changed paths:
M Source/WebCore/Modules/indexeddb/IDBDatabase.cpp
M Source/WebCore/Modules/indexeddb/IDBDatabase.h
M Source/WebCore/Modules/indexeddb/client/IDBConnectionProxy.cpp
M Source/WebCore/Modules/indexeddb/client/IDBConnectionProxy.h
M Source/WebCore/dom/ScriptExecutionContext.cpp
M Source/WebCore/dom/ScriptExecutionContext.h
Log Message:
-----------
Pure virtual function called! in WebCore::ScriptExecutionContext::postCrossThreadTask<WebCore::IDBDatabase &,void (WebCore::IDBDatabase::*&)(const WebCore::IDBError &),const WebCore::IDBError &>
https://bugs.webkit.org/show_bug.cgi?id=283040
rdar://139782420
Reviewed by Chris Dumez.
Crash log indicates IDBDatabase (IDBActiveDOMObject) can post task to ScriptExecutionContext from the main thread when
context is being destroyed on a background thread. This is problematic because ScriptExecutionContext is not
thread-safe and IDBDatabase is not supposed to access it directly from a non-context thread. This patch fixes the issue
by posting task via ScriptExecutionContext::ensureOnContextThread function instead, as the function acquires lock as
needed. Also this patch replaces raw pointer in m_databaseConnectionMap with ThreadSafeWeakPtr, and make
IDBDatabase::m_isContextSuspended std::atomic for better thread safety.
* Source/WebCore/Modules/indexeddb/IDBDatabase.cpp:
(WebCore::IDBDatabase::IDBDatabase):
* Source/WebCore/Modules/indexeddb/IDBDatabase.h:
* Source/WebCore/Modules/indexeddb/client/IDBConnectionProxy.cpp:
(WebCore::IDBClient::IDBConnectionProxy::databaseFromConnectionIdentifier):
(WebCore::IDBClient::IDBConnectionProxy::fireVersionChangeEvent):
(WebCore::IDBClient::IDBConnectionProxy::didCloseFromServer):
(WebCore::IDBClient::IDBConnectionProxy::connectionToServerLost):
(WebCore::IDBClient::IDBConnectionProxy::registerDatabaseConnection):
(WebCore::IDBClient::IDBConnectionProxy::unregisterDatabaseConnection):
(WebCore::IDBClient::IDBConnectionProxy::setContextSuspended):
* Source/WebCore/Modules/indexeddb/client/IDBConnectionProxy.h:
* Source/WebCore/dom/ScriptExecutionContext.cpp:
(WebCore::ScriptExecutionContext::ensureOnContextThreadForCrossThreadTask):
* Source/WebCore/dom/ScriptExecutionContext.h:
Canonical link: https://commits.webkit.org/283286.491@safari-7620-branch
Commit: 33b2af279a872e1652a78653d80d8e64f0dd4ffb
https://github.com/WebKit/WebKit/commit/33b2af279a872e1652a78653d80d8e64f0dd4ffb
Author: Alan Baradlay <zalan at apple.com>
Date: 2024-11-18 (Mon, 18 Nov 2024)
Changed paths:
A LayoutTests/fast/block/float/zero-margin-box-float-overlap-expected.html
A LayoutTests/fast/block/float/zero-margin-box-float-overlap.html
M Source/WebCore/rendering/RenderBox.cpp
Log Message:
-----------
Cherry-pick 4e3542612b56. rdar://140002887
REGRESSION (283298 at main): GitHub.com: checks run have condensed UI and not expanded to area in STP207 compared to Safari 18.1
https://bugs.webkit.org/show_bug.cgi?id=283115
<rdar://problem/139882323>
Reviewed by Antti Koivisto.
When there's no float to avoid (in this there's a float on this logical top position, but with zero margin width), our logical width is the same as
if there was no float at all.
* LayoutTests/fast/block/float/zero-margin-box-float-overlap-expected.html: Added.
* LayoutTests/fast/block/float/zero-margin-box-float-overlap.html: Added.
* Source/WebCore/rendering/RenderBox.cpp:
(WebCore::RenderBox::shrinkLogicalWidthToAvoidFloats const):
Canonical link: https://commits.webkit.org/286637@main
Canonical link: https://commits.webkit.org/283286.492@safari-7620-branch
Commit: 8c87bfb6960757b8f60a1778fdc502f7344591c2
https://github.com/WebKit/WebKit/commit/8c87bfb6960757b8f60a1778fdc502f7344591c2
Author: Wenson Hsieh <wenson_hsieh at apple.com>
Date: 2024-11-18 (Mon, 18 Nov 2024)
Changed paths:
A LayoutTests/editing/selection/ios/clear-selection-after-tap-on-video-expected.txt
A LayoutTests/editing/selection/ios/clear-selection-after-tap-on-video.html
M Source/WebKit/UIProcess/WebPageProxy.h
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
M Source/WebKit/UIProcess/ios/WebPageProxyIOS.mm
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKit/WebProcess/WebPage/WebPage.messages.in
M Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm
Log Message:
-----------
Cherry-pick 54f691b62739. rdar://140010013
[iOS] Removing a text selection that covers the video is nearly impossible on YouTube.com
https://bugs.webkit.org/show_bug.cgi?id=281887
rdar://88015073
Reviewed by Richard Robinson.
When tapping selection highlights on iOS, we normally allow UIKit (specifically, the text
interaction's multi tap gesture) to intercept the tap and toggle edit menu visibility, instead of
dispatching synthetic click events to the page.
There's an exception to this rule, which is that a selection covering most (>75%) of the unobscured
content rect will prefer sending the tap gesture through to the page instead of toggling the edit
menu (which clears the selection, due to dispatching a synthetic click).
On YouTube.com, there's a similar case where it makes more sense to prefer dispatching the tap over
the page instead of toggling the edit menu: the scenario where the selection has somehow covered the
main video player (normally by accident). In this case, tapping the video to play/pause/show the
controls overlay is almost always preferable to toggling visibility of the edit menu. Currently,
repeatedly tapping the selection just shows and hides the edit menu, which can feel frustrating to
the user.
To that end, we can mitigate this by separately clearing the text selection, in the case where the
tap over a selection highlight that would normally toggle the edit menu happens to also be over a
video element (unless it's over Live Text).
* LayoutTests/editing/selection/ios/clear-selection-after-tap-on-video-expected.txt: Added.
* LayoutTests/editing/selection/ios/clear-selection-after-tap-on-video.html: Added.
Add a layout test to exercise the change.
* Source/WebKit/UIProcess/WebPageProxy.h:
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _shouldToggleEditMenuAfterTapAt:]):
(-[WKContentView gestureRecognizerShouldBegin:]):
Refactor this to send `ClearSelectionAfterTappingSelectionHighlightIfNeeded` to the web page, in
the event where the selection highlight was tapped.
(-[WKContentView _shouldToggleSelectionCommandsAfterTapAt:]): Deleted.
Rename this to refer to `EditMenu` instead of `SelectionCommands`. The former is the official,
modern API name for the edit menu, while the latter references the older internal name in UIKit.
* Source/WebKit/UIProcess/ios/WebPageProxyIOS.mm:
(WebKit::WebPageProxy::clearSelectionAfterTappingSelectionHighlightIfNeeded):
* Source/WebKit/WebProcess/WebPage/WebPage.h:
* Source/WebKit/WebProcess/WebPage/WebPage.messages.in:
* Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::WebPage::clearSelectionAfterTappingSelectionHighlightIfNeeded):
Implement the main heuristic here — detect when the tap location is over a video (using a piercing
hit-test to take care of the case where custom video controls are rendered in a container covering
the video player), and clear the selection if needed.
Canonical link: https://commits.webkit.org/285543@main
Canonical link: https://commits.webkit.org/283286.493@safari-7620-branch
Commit: 17cc17e4af9cf3d98140e8ce328d37060d758c72
https://github.com/WebKit/WebKit/commit/17cc17e4af9cf3d98140e8ce328d37060d758c72
Author: Matt Woodrow <mattwoodrow at apple.com>
Date: 2024-11-18 (Mon, 18 Nov 2024)
Changed paths:
M LayoutTests/platform/glib/TestExpectations
M Source/WebCore/rendering/RenderLayer.cpp
Log Message:
-----------
Cherry-pick d5061a575da0. rdar://138196100
[css-view-transitions] The ::view-transition pseudo element should create a stacking context.
https://bugs.webkit.org/show_bug.cgi?id=281407
<rdar://137855044>
Reviewed by Tim Nguyen.
https://www.w3.org/TR/css-view-transitions-1/#view-transition-stacking-layer -
"The ::view-transition pseudo-element generates a new stacking context"
* LayoutTests/TestExpectations:
* Source/WebCore/rendering/RenderLayer.cpp:
(WebCore::RenderLayer::shouldBeCSSStackingContext const):
Canonical link: https://commits.webkit.org/285142@main
Canonical link: https://commits.webkit.org/283286.494@safari-7620-branch
Commit: 9df4bed6623f5f9c075e3fc988fb4f77f5e4c78c
https://github.com/WebKit/WebKit/commit/9df4bed6623f5f9c075e3fc988fb4f77f5e4c78c
Author: Qianlang Chen <qianlangchen at apple.com>
Date: 2024-11-19 (Tue, 19 Nov 2024)
Changed paths:
M Source/WebCore/inspector/InspectorStyleSheet.cpp
Log Message:
-----------
Cherry-pick 46d8803827ef. rdar://140002877
Regression(283950 at main): Crash in WebCore::InspectorStyleSheet::setRuleStyleText
rdar://138232398
https://bugs.webkit.org/show_bug.cgi?id=281807
Reviewed by Chris Dumez.
* Source/WebCore/inspector/InspectorStyleSheet.cpp:
(WebCore::computeCanonicalRuleText):
(WebCore::InspectorStyleSheet::setRuleStyleText):
- When writing the helper `computeCanonicalRuleText`, returning a
StringView was incorrect. A String should be returned to properly
pass ownership of the underlying data.
- This change can be tested with
run-webkit-tests -g LayoutTests/inspector/css/setStyleText.html
Canonical link: https://commits.webkit.org/285588@main
Canonical link: https://commits.webkit.org/283286.495@safari-7620-branch
Commit: 7f0b7225dbc9a3a8d6b51bd0d6f500f859b07cf1
https://github.com/WebKit/WebKit/commit/7f0b7225dbc9a3a8d6b51bd0d6f500f859b07cf1
Author: Matt Woodrow <mattwoodrow at apple.com>
Date: 2024-11-19 (Tue, 19 Nov 2024)
Changed paths:
M Source/WebCore/animation/ElementAnimationRareData.cpp
M Source/WebCore/animation/ElementAnimationRareData.h
M Source/WebCore/dom/ElementRareData.cpp
M Source/WebCore/dom/ElementRareData.h
M Source/WebCore/style/PseudoElementIdentifier.h
Log Message:
-----------
Cherry-pick c51ed1c168eb. rdar://140162760
Use a HashTable for animationRareData.
https://bugs.webkit.org/show_bug.cgi?id=282375
<rdar://138980396>
Reviewed by Tim Nguyen.
ViewTransitions can add a lot of pseudo elements to the document node, we should
use a hash table instead of iterating a list.
* Source/WebCore/animation/ElementAnimationRareData.cpp:
(WebCore::ElementAnimationRareData::ElementAnimationRareData):
* Source/WebCore/animation/ElementAnimationRareData.h:
(WebCore::ElementAnimationRareData::pseudoElementIdentifier): Deleted.
* Source/WebCore/dom/ElementRareData.cpp:
* Source/WebCore/dom/ElementRareData.h:
(WebCore::ElementRareData::animationRareData const):
(WebCore::ElementRareData::ensureAnimationRareData):
* Source/WebCore/style/PseudoElementIdentifier.h:
(WTF::HashTraits<std::optional<WebCore::Style::PseudoElementIdentifier>>::constructDeletedValue):
(WTF::HashTraits<std::optional<WebCore::Style::PseudoElementIdentifier>>::isDeletedValue):
Canonical link: https://commits.webkit.org/285997@main
Canonical link: https://commits.webkit.org/283286.496@safari-7620-branch
Commit: 1a85962506bffb342cb5d63bb6cfc620c52ba9b8
https://github.com/WebKit/WebKit/commit/1a85962506bffb342cb5d63bb6cfc620c52ba9b8
Author: Youenn Fablet <youenn at apple.com>
Date: 2024-11-19 (Tue, 19 Nov 2024)
Changed paths:
A LayoutTests/fast/mediastream/mediastreamtrack-clone-muted-expected.txt
A LayoutTests/fast/mediastream/mediastreamtrack-clone-muted.html
M LayoutTests/platform/glib/TestExpectations
M Source/WebCore/platform/mediastream/MediaStreamTrackPrivate.cpp
M Source/WebKit/WebProcess/cocoa/RemoteRealtimeMediaSourceProxy.cpp
M Source/WebKit/WebProcess/cocoa/RemoteRealtimeVideoSource.cpp
Log Message:
-----------
Cherry-pick 782d2a89a9b1. rdar://139724372
Cloning capture MediaStreamTrack should preserve muted/interrupted flags
rdar://139563413
https://bugs.webkit.org/show_bug.cgi?id=282874
Reviewed by Eric Carlson.
When cloning a track, we would ask the source to start producing data if the track producing data flag is set.
This is incorrect when the source is muted/interrupted, as the source producing data flag in that case is false but the track flag is true.
We should probably rename MediaStreamTrackPrivate::m_isProducingData in a follow-up.
Also, for video source clones, we would not copy the muted/interrupted states, which would make the MediaStreamTrackPrivate and its source out of sync.
Covered by added test.
* LayoutTests/fast/mediastream/mediastreamtrack-clone-muted-expected.txt: Added.
* LayoutTests/fast/mediastream/mediastreamtrack-clone-muted.html: Added.
* Source/WebCore/platform/mediastream/MediaStreamTrackPrivate.cpp:
(WebCore::MediaStreamTrackPrivate::clone):
* Source/WebKit/WebProcess/cocoa/RemoteRealtimeMediaSourceProxy.cpp:
(WebKit::RemoteRealtimeMediaSourceProxy::clone):
* Source/WebKit/WebProcess/cocoa/RemoteRealtimeVideoSource.cpp:
(WebKit::RemoteRealtimeVideoSource::clone):
Canonical link: https://commits.webkit.org/286477@main
Canonical link: https://commits.webkit.org/283286.497@safari-7620-branch
Commit: 7a271a5edc7ed7393a068395af81de4d3ff00f99
https://github.com/WebKit/WebKit/commit/7a271a5edc7ed7393a068395af81de4d3ff00f99
Author: Matthieu Dubet <m_dubet at apple.com>
Date: 2024-11-19 (Tue, 19 Nov 2024)
Changed paths:
M LayoutTests/TestExpectations
A LayoutTests/imported/w3c/web-platform-tests/css/css-scoping/host-descendant-003-expected.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-scoping/host-descendant-003.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-scoping/host-multiple-002-expected.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-scoping/host-multiple-002.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-scoping/host-multiple-003-expected.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-scoping/host-multiple-003.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-scoping/host-multiple-004-expected.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-scoping/host-multiple-004.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-scoping/host-multiple-005-expected.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-scoping/host-multiple-005.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-scoping/host-multiple-006-expected.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-scoping/host-multiple-006.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-scoping/host-not-001-expected.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-scoping/host-not-001.html
M Source/WebCore/css/SelectorChecker.cpp
Log Message:
-----------
Cherry-pick 33507394bab5. rdar://140135792
[CSS] Don't combine :not() with :host
https://bugs.webkit.org/show_bug.cgi?id=282960
rdar://139198548
Reviewed by Tim Nguyen.
As a featureless element, only :host matches the shadow host.
Functional pseudoclasses pass the behavior to their arguments,
so :is(:host) matches the same as :host (the shadow host).
This fixes a regression introduced in 281963 at main.
Before 281963, :host combination with a functional pseudoclass
(or anything but a pseudo-element more generally)
was early returning "not match".
281963 has removed the early return for all functional pseudoclass
(to allow :is() combined with :host, but also :not()).
Properly supporting :host combining with :not() is tricky
and will be handled in a followup patch.
* LayoutTests/TestExpectations:
* LayoutTests/imported/w3c/web-platform-tests/css/css-scoping/host-descendant-003-expected.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-scoping/host-descendant-003.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-scoping/host-multiple-002-expected.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-scoping/host-multiple-002.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-scoping/host-multiple-003-expected.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-scoping/host-multiple-003.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-scoping/host-multiple-004-expected.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-scoping/host-multiple-004.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-scoping/host-multiple-005-expected.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-scoping/host-multiple-005.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-scoping/host-multiple-006-expected.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-scoping/host-multiple-006.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-scoping/host-not-001-expected.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-scoping/host-not-001.html: Added.
* Source/WebCore/css/SelectorChecker.cpp:
(WebCore::SelectorChecker::checkOne const):
Canonical link: https://commits.webkit.org/286611@main
Canonical link: https://commits.webkit.org/283286.498@safari-7620-branch
Commit: e5527295dcd7061dd1e9376020b78cd21e4930d9
https://github.com/WebKit/WebKit/commit/e5527295dcd7061dd1e9376020b78cd21e4930d9
Author: Jessica Cheung <jcheung23 at apple.com>
Date: 2024-11-19 (Tue, 19 Nov 2024)
Changed paths:
M Source/WebCore/page/Quirks.cpp
M Source/WebCore/page/Quirks.h
M Source/WebCore/style/StyleAdjuster.cpp
Log Message:
-----------
Cherry-pick 5988703a14ec. rdar://140009955
[Quirk] maps.google.com: [iPad] unable to scroll on google maps print page
https://bugs.webkit.org/show_bug.cgi?id=282721
rdar://67358928
Reviewed by Wenson Hsieh.
Currently, we cannot scroll on maps.google.com via touch b/c there is a `touch-action: none`
on `<body>`. In their code, they recieve all the expected touch events but they do not
move the page to "scroll".
There is a `div .UJrD4b` which touch events are happening on.
There is another `div #print` which is the grandparent of `div .UJrD4b`.
`div #print` has `display: none` on all pages except the printing pages.
Based on the pointer events “Determining supported direct manipulation behavior”spec,
we travel up to the inclusive ancestor which is `<body>`
that has a `touch-action: none` style.
1. To quirk and make touches affect scrolling, we set `<body>`
to have `touch-action: auto` instead. To do so, we check if `.PUtLdf` is present on body.
While this seems to be a generated class name, the proper quirk for this would require
breaking CSS inheritance since `<body>` would now depend on the `display` styling of the
descendant `div #print`, resulting in a circular dependency.
2. Remove `#if ENABLE(TOUCH_EVENTS)` for `Quirks::isGoogleMaps()`.
* Source/WebCore/page/Quirks.cpp:
(WebCore::Quirks::needsGoogleMapsScrollingQuirk const):
* Source/WebCore/page/Quirks.h:
* Source/WebCore/style/StyleAdjuster.cpp:
(WebCore::Style::Adjuster::adjustForSiteSpecificQuirks const):
Canonical link: https://commits.webkit.org/286455@main
Canonical link: https://commits.webkit.org/283286.499@safari-7620-branch
Commit: 6f3e325233b5384a6135ca12a5200feeb62d3abc
https://github.com/WebKit/WebKit/commit/6f3e325233b5384a6135ca12a5200feeb62d3abc
Author: Daniel Liu <danlliu at umich.edu>
Date: 2024-11-19 (Tue, 19 Nov 2024)
Changed paths:
M JSTests/wasm/stress/catch-should-keep-alive-inline-parent-expression-stack.js
M Source/JavaScriptCore/runtime/ErrorInstance.h
Log Message:
-----------
Cherry-pick a2ba2b6959db. rdar://140159505
Stack overflow and OOM should not be catchable from Wasm
https://bugs.webkit.org/show_bug.cgi?id=282959
rdar://139515612
Reviewed by Justin Michaud and Keith Miller.
According to both the old and new exception specs, stack overflow and
out of memory errors should not be catchable from WebAssembly `catch`
(or similar). However, the exceptions were still marked as catchable
from Wasm, meaning they could trigger incorrect handlers.
* JSTests/wasm/stress/catch-should-keep-alive-inline-parent-expression-stack.js:
(async test):
* Source/JavaScriptCore/runtime/ErrorInstance.h:
(JSC::ErrorInstance::setStackOverflowError):
(JSC::ErrorInstance::setOutOfMemoryError):
* Source/JavaScriptCore/wasm/WasmSlowPaths.cpp:
(JSC::LLInt::WASM_SLOW_PATH_DECL):
Canonical link: https://commits.webkit.org/286486@main
Canonical link: https://commits.webkit.org/283286.500@safari-7620-branch
Commit: b7402f10b17c01276ed7b1fc0618b8db7ac88182
https://github.com/WebKit/WebKit/commit/b7402f10b17c01276ed7b1fc0618b8db7ac88182
Author: Charlie Wolfe <charliew at apple.com>
Date: 2024-11-19 (Tue, 19 Nov 2024)
Changed paths:
M Source/WebCore/loader/FrameLoader.cpp
M Source/WebCore/loader/FrameLoader.h
M Source/WebCore/loader/cache/CachedResourceLoader.cpp
M Source/WebCore/page/SecurityPolicy.h
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/IPCTestingAPI.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/SOAuthorizationTests.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WKHTTPCookieStore.mm
Log Message:
-----------
sameSiteInfo.isSameSite may not match URLs used in Data Isolation checks
https://bugs.webkit.org/show_bug.cgi?id=283309
rdar://140129837
Reviewed by Sihui Liu.
This patch fixes an issue where a WebContent process can send IPC with URLs that are not same-site, but
contains `sameSiteInfo` that indicates that the request is same-site. This can lead to requesting cookies
for a URL that was not considered in the data isolation check.
To lower risk, we reject cookie access instead of terminating the sender process. More details provided
below.
* Source/WebCore/loader/FrameLoader.cpp:
(WebCore::FrameLoader::setOriginalURLForDownloadRequest):
(WebCore::FrameLoader::updateRequestAndAddExtraFields):
(WebCore::FrameLoader::addSameSiteInfoToRequestIfNeeded):
* Source/WebCore/loader/FrameLoader.h:
These quirks were added when cookies were SameSite=Lax by default, which is no longer the case, so it can
be removed. Keeping this would mean certain requests would unexpectedly be considered same-site, and
would fail the check being added in the network process.
* Source/WebCore/loader/cache/CachedResourceLoader.cpp:
(WebCore::CachedResourceLoader::requestResource):
This is an existing bug that was revealed by this change, and is needed to fix
`http/tests/cache/disk-cache/disk-cache-vary-cookie.html`.
* Source/WebCore/page/SecurityPolicy.h:
Export `shouldInheritSecurityOriginFromOwner` so that it can be used in the network process.
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:
(WebKit::NetworkConnectionToWebProcess::shouldTreatAsSameSite const):
Add a network process side same-site check, similar to `FrameLoader::addSameSiteInfoToRequestIfNeeded`.
(WebKit::NetworkConnectionToWebProcess::cookiesForDOM):
(WebKit::NetworkConnectionToWebProcess::setCookiesFromDOM):
(WebKit::NetworkConnectionToWebProcess::cookieRequestHeaderFieldValue):
(WebKit::NetworkConnectionToWebProcess::getRawCookies):
(WebKit::NetworkConnectionToWebProcess::cookiesForDOMAsync):
(WebKit::NetworkConnectionToWebProcess::setCookieFromDOMAsync):
Validate all cookie messages that contain `sameSiteInfo`.
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.h:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/IPCTestingAPI.mm:
(InvalidSameSiteInfoCookieRequestHeaderFieldValue)):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/SOAuthorizationTests.mm:
(TestWebKitAPI::TEST(SOAuthorizationSubFrame, InterceptionSucceedWithCookie)):
Fix this test, which was trying to a cookie from example.com on a page with an empty main frame URL.
Canonical link: https://commits.webkit.org/283286.501@safari-7620-branch
Commit: d542dd305ab0d65d36cc4a79a81c75418865fe49
https://github.com/WebKit/WebKit/commit/d542dd305ab0d65d36cc4a79a81c75418865fe49
Author: Ryosuke Niwa <rniwa at webkit.org>
Date: 2024-11-19 (Tue, 19 Nov 2024)
Changed paths:
M Source/WebCore/platform/Timer.cpp
Log Message:
-----------
Disable the release assert in Timer::Timer
https://bugs.webkit.org/show_bug.cgi?id=283383
<rdar://140233024>
Reviewed by Chris Dumez.
Removed the release assert for now.
* Source/WebCore/platform/Timer.cpp:
(WebCore::TimerBase::TimerBase):
Canonical link: https://commits.webkit.org/283286.502@safari-7620-branch
Commit: 2e7ebda19126e80b8c794de284e6b1669907b433
https://github.com/WebKit/WebKit/commit/2e7ebda19126e80b8c794de284e6b1669907b433
Author: Alan Baradlay <zalan at apple.com>
Date: 2024-11-19 (Tue, 19 Nov 2024)
Changed paths:
A LayoutTests/fast/ruby/breaking-opportunity-between-bases-expected.html
A LayoutTests/fast/ruby/breaking-opportunity-between-bases.html
M Source/WebCore/layout/formattingContexts/inline/ruby/RubyFormattingContext.cpp
M Source/WebCore/layout/formattingContexts/inline/text/TextUtil.cpp
M Source/WebCore/layout/formattingContexts/inline/text/TextUtil.h
M Source/WebCore/rendering/InlineWalker.h
M Source/WebCore/rendering/RenderBlockFlow.cpp
Log Message:
-----------
Cherry-pick 0efbdbf5ca5a. rdar://140213501
[Ruby] duolingo.com: Listening text is cut off on several prompts
https://bugs.webkit.org/show_bug.cgi?id=282235
<rdar://131571396>
Reviewed by Antti Koivisto.
This change fixes ruby content (min) sizing when there's breaking opportunity between adjacent bases.
Legacy preferred width computation ignores soft wrap opportunities between inline boxes
e.g. <span>A</span><span>B</span> (assume language rules allow to break between A and B)
^ RenderBlockFlow::computeInlinePreferredLogicalWidths simply does not check for such breaking opportunities between these <span>s.
This is specific to legacy preferred width codepath as IFC runs regular layout which finds such breaking positions (also same content works fine when instead of using 'width: min-width", we force non-preferred with codepath by "width: 0px;")
1. In RenderBlockFlow::computeInlinePreferredLogicalWidths, when at the end of the ruby base, look forward
by calling hasTrailingSoftWrapOpportunity to check for breaking opportunity.
2. hasTrailingSoftWrapOpportunity collects adjacent renderers and calls ICU to figure out whether content can be split.
* LayoutTests/fast/ruby/breaking-opportunity-between-bases-expected.html: Added.
* LayoutTests/fast/ruby/breaking-opportunity-between-bases.html: Added.
* Source/WebCore/layout/formattingContexts/inline/ruby/RubyFormattingContext.cpp:
(WebCore::Layout::RubyFormattingContext::isAtSoftWrapOpportunity):
* Source/WebCore/layout/formattingContexts/inline/text/TextUtil.cpp:
(WebCore::Layout::TextUtil::mayBreakInBetween):
* Source/WebCore/layout/formattingContexts/inline/text/TextUtil.h:
* Source/WebCore/layout/integration/LayoutIntegrationCoverage.cpp:
(WebCore::LayoutIntegration::canUseForPreferredWidthComputation):
* Source/WebCore/rendering/InlineWalker.h:
(WebCore::InlineWalker::InlineWalker):
* Source/WebCore/rendering/RenderBlockFlow.cpp:
(WebCore::trailingRubyBaseAndAdjacentTextContent):
(WebCore::hasTrailingSoftWrapOpportunity):
(WebCore::RenderBlockFlow::computeInlinePreferredLogicalWidths const):
Canonical link: https://commits.webkit.org/285835@main
Canonical link: https://commits.webkit.org/283286.503@safari-7620-branch
Commit: 665f9aafa605582bf9fdb13d7442239b3e066f8d
https://github.com/WebKit/WebKit/commit/665f9aafa605582bf9fdb13d7442239b3e066f8d
Author: Alan Baradlay <zalan at apple.com>
Date: 2024-11-19 (Tue, 19 Nov 2024)
Changed paths:
A LayoutTests/fast/block/hugging-outline-with-out-of-flow-child-expected.html
A LayoutTests/fast/block/hugging-outline-with-out-of-flow-child.html
M Source/WebCore/rendering/RenderBlock.cpp
Log Message:
-----------
Cherry-pick a5a85e331e44. rdar://140213556
images.google.com: Focus Outline is broken for `Share` and `Save` buttons
https://bugs.webkit.org/show_bug.cgi?id=282335
<<rdar://138113654>
Reviewed by Antti Koivisto.
Out-of-flow descendant content is not supposed to inflate (or affect at all) the hugging 'outline: auto' focus ring rect.
* LayoutTests/fast/block/hugging-outline-with-out-of-flow-child-expected.html: Added.
* LayoutTests/fast/block/hugging-outline-with-out-of-flow-child.html: Added.
* Source/WebCore/rendering/RenderBlock.cpp:
(WebCore::RenderBlock::addFocusRingRects const):
Canonical link: https://commits.webkit.org/285918@main
Canonical link: https://commits.webkit.org/283286.504@safari-7620-branch
Commit: 03500a86effc21d1ffaaf87aeb13dd0b7be86497
https://github.com/WebKit/WebKit/commit/03500a86effc21d1ffaaf87aeb13dd0b7be86497
Author: Matthieu Dubet <m_dubet at apple.com>
Date: 2024-11-19 (Tue, 19 Nov 2024)
Changed paths:
A LayoutTests/fast/css/invalidation-not-has-expected.txt
A LayoutTests/fast/css/invalidation-not-has.html
M Source/WebCore/style/ChildChangeInvalidation.cpp
M Source/WebCore/style/RuleSet.cpp
M Source/WebCore/style/RuleSet.h
M Source/WebCore/style/StyleInvalidator.cpp
M Source/WebCore/style/StyleInvalidator.h
Log Message:
-----------
Cherry-pick 95ffd81b29e8. rdar://140215464
[CSS] Fix :not(:has(...)) invalidation
https://bugs.webkit.org/show_bug.cgi?id=276867
rdar://122689282
Reviewed by Antti Koivisto.
Invalidation of :not(:has(...)) is special because while there can be no
element to actually invalidate, the rule matches.
For ChildChangeInvalidation, we thus propagate the isNegation flag to StyleInvalidator
to invalidate in case of non-matching the :has().
The other *Invalidation classes handle :not() differently, thus the
isNegation flag is purposedly not propagated to StyleInvalidator for them.
* LayoutTests/fast/css/invalidation-not-has-expected.txt: Added.
* LayoutTests/fast/css/invalidation-not-has.html: Added.
* Source/WebCore/style/ChildChangeInvalidation.cpp:
(WebCore::Style::ChildChangeInvalidation::invalidateForChangedElement):
* Source/WebCore/style/RuleSet.cpp:
(WebCore::Style::RuleSet::evaluateDynamicMediaQueryRules):
* Source/WebCore/style/RuleSet.h:
* Source/WebCore/style/StyleInvalidator.cpp:
(WebCore::Style::Invalidator::Invalidator):
(WebCore::Style::Invalidator::collectRuleInformation):
(WebCore::Style::Invalidator::invalidateIfNeeded):
(WebCore::Style::Invalidator::invalidateUserAgentParts):
(WebCore::Style::Invalidator::addToMatchElementRuleSets):
(WebCore::Style::Invalidator::addToMatchElementRuleSetsRespectingNegation):
(WebCore::Style::Invalidator::invalidateWithScopeBreakingHasPseudoClassRuleSet):
* Source/WebCore/style/StyleInvalidator.h:
Canonical link: https://commits.webkit.org/285987@main
Canonical link: https://commits.webkit.org/283286.505@safari-7620-branch
Commit: 731eb3e83471a3d54f7e42779aca2fe3819bbfa9
https://github.com/WebKit/WebKit/commit/731eb3e83471a3d54f7e42779aca2fe3819bbfa9
Author: Wenson Hsieh <wenson_hsieh at apple.com>
Date: 2024-11-19 (Tue, 19 Nov 2024)
Changed paths:
M LayoutTests/fast/dom/linkify-phone-numbers-expected.html
M LayoutTests/fast/dom/linkify-phone-numbers.html
M Source/WebCore/html/parser/HTMLTreeBuilder.cpp
Log Message:
-----------
Cherry-pick 51965fbac8b7. rdar://140213507
[iOS] Rendering in Jupyter notebook (MathJAX.js converting LaTeX) is broken due to data detection
https://bugs.webkit.org/show_bug.cgi?id=282567
rdar://116407458
Reviewed by Richard Robinson, Ryosuke Niwa, and Abrar Rahman Protyasha.
Since at least iOS 7, the HTML parser automatically tries to detect phone numbers that appear within
plain text, and replaces them with links; for instance, a normal text node `+1234567` would be
replaced by an anchor element, `<a href="tel:+1234567">+1234567</a>`. This sometimes causes
incompatibilities with certain JavaScript libraries that try to parse text at load time and use it
to convert the text nodes (and their container element) into formatted LaTeX.
Unfortunately, there isn't any obvious indication that we must avoid running data detection for this
text (e.g. based on the element type, style, or other attributes); the only indication of this comes
in the form of a `data-mime-type="text/latex"` DOM attribute on a parent container of the text node.
* LayoutTests/fast/dom/linkify-phone-numbers-expected.html:
* LayoutTests/fast/dom/linkify-phone-numbers.html:
Adjust an existing layout test to cover this scenario.
* Source/WebCore/html/parser/HTMLTreeBuilder.cpp:
(WebCore::HTMLTreeBuilder::linkifyPhoneNumbers):
Walk up the tree to check for ancestor elements with `data-mime-type="text/latex"`; I'm doing this
here (when a phone number is about to be inserted) instead of in `disallowTelephoneNumberParsing`,
so that we don't incur the cost of a potentially expensive attribute lookup multiple times, for
every ancestor element of every text node in the DOM.
(WebCore::shouldParseTelephoneNumbersInNode):
Leave a FIXME here about the fact that on iOS, we perform an ancestor walk when parsing every single
text node in the DOM.
Canonical link: https://commits.webkit.org/286153@main
Canonical link: https://commits.webkit.org/283286.506@safari-7620-branch
Commit: 3f6d9f2f8717daefe553ec069fe07de93ad4ad57
https://github.com/WebKit/WebKit/commit/3f6d9f2f8717daefe553ec069fe07de93ad4ad57
Author: Richard Robinson <richard_robinson2 at apple.com>
Date: 2024-11-19 (Tue, 19 Nov 2024)
Changed paths:
M Source/WebKit/WebKitSwift/WritingTools/WKIntelligenceTextEffectCoordinator.swift
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WritingTools.mm
Log Message:
-----------
Cherry-pick dc67c7bd3684. rdar://140224321
[Writing Tools] Can no longer type in compose view after using Writing Tools proofreading in Mail
https://bugs.webkit.org/show_bug.cgi?id=283329
rdar://140133728
Reviewed by Abrar Rahman Protyasha.
This is essentially the same bug as https://commits.webkit.org/283274@main. This time, even though there
was supposed to be logic to ensure that the view got removed when there were no longer any active effects,
the logic was flawed due to the wrong order of operations; the call to remove the view happened prior to
the effects actually being set to `nil`.
Fix by ensuring that the order of operations of when the effects are set to `nil` and when the view is
requested to be removed is correct.
* Source/WebKit/WebKitSwift/WritingTools/WKIntelligenceTextEffectCoordinator.swift:
(setActivePonderingEffect(_:)):
(setActiveReplacementEffect(_:)):
Canonical link: https://commits.webkit.org/286776@main
Canonical link: https://commits.webkit.org/283286.507@safari-7620-branch
Commit: 3d76fbbe7d3c95d564510ca4fbe71ff47910bb44
https://github.com/WebKit/WebKit/commit/3d76fbbe7d3c95d564510ca4fbe71ff47910bb44
Author: David Degazio <d_degazio at apple.com>
Date: 2024-11-20 (Wed, 20 Nov 2024)
Changed paths:
M Source/JavaScriptCore/runtime/ErrorInstance.h
Log Message:
-----------
Cherry-pick bcf1df7bd5d1. rdar://140283095
Unreviewed fix watchOS build after 286486 at main
https://bugs.webkit.org/show_bug.cgi?id=283001
rdar://139735779
* Source/JavaScriptCore/runtime/ErrorInstance.h:
(JSC::ErrorInstance::setStackOverflowError):
(JSC::ErrorInstance::setOutOfMemoryError):
Canonical link: https://commits.webkit.org/286493@main
Commit: e00ad1b527834f99bf89dd1bea6ddd2da45166e9
https://github.com/WebKit/WebKit/commit/e00ad1b527834f99bf89dd1bea6ddd2da45166e9
Author: Elliott Williams <emw at apple.com>
Date: 2024-11-20 (Wed, 20 Nov 2024)
Changed paths:
M Source/JavaScriptCore/Configurations/Base.xcconfig
M Source/WTF/Configurations/Base.xcconfig
M Source/WebCore/Configurations/Base.xcconfig
M Source/WebCore/PAL/Configurations/Base.xcconfig
M Source/WebCore/PAL/ThirdParty/dav1d/Configurations/Base.xcconfig
M Source/WebInspectorUI/Configurations/Base.xcconfig
M Source/WebKit/Configurations/Base.xcconfig
M Source/bmalloc/Configurations/Base.xcconfig
Log Message:
-----------
Cherry-pick 286656 at main (48cd31e36640). rdar://140302506
[Xcode] Some product dependencies phases not working in recent builds
https://bugs.webkit.org/show_bug.cgi?id=283193
rdar://139990739
Reviewed by Alexey Proskuryakov.
Prior to the XCBuild transition, the legacy build system needed the
paths we list in "Product Dependencies" copy phases to be excluded,
otherwise it would emit errors when conditionally-available content like
WebKitAdditions was not built. XCBuild elides the copy and never
complained about missing files, so in
<https://commits.webkit.org/262162@main> we removed the file names
listed in our EXCLUDED_PRODUCT_DEPENDENCY_NAMES build settings.
It turns out that some targets specify their product dependencies
in plain EXCLUDED_SOURCE_FILE_NAMES settings. Now, recent builds of Xcode
process these excludes rules differently, and elide the entire
dependency between targets when the product's name is excluded.
Fix this by completing the cleanup and removing product dependency names
from these settings.
* Source/JavaScriptCore/Configurations/Base.xcconfig:
* Source/WTF/Configurations/Base.xcconfig:
* Source/WebCore/Configurations/Base.xcconfig:
* Source/WebCore/PAL/Configurations/Base.xcconfig:
* Source/WebCore/PAL/ThirdParty/dav1d/Configurations/Base.xcconfig:
* Source/WebInspectorUI/Configurations/Base.xcconfig:
* Source/WebKit/Configurations/Base.xcconfig:
* Source/bmalloc/Configurations/Base.xcconfig:
Canonical link: https://commits.webkit.org/286656@main
Canonical link: https://commits.webkit.org/283286.509@safari-7620-branch
Commit: 91b566ff89f0a7748cbff85932224fca9165b9d7
https://github.com/WebKit/WebKit/commit/91b566ff89f0a7748cbff85932224fca9165b9d7
Author: Aditya Keerthi <akeerthi at apple.com>
Date: 2024-11-20 (Wed, 20 Nov 2024)
Changed paths:
M Source/WebCore/page/scrolling/AsyncScrollingCoordinator.cpp
M Source/WebCore/page/scrolling/ScrollingCoordinatorTypes.h
M Source/WebCore/page/scrolling/ScrollingStateFrameScrollingNode.cpp
M Source/WebCore/page/scrolling/ScrollingStateFrameScrollingNode.h
M Source/WebCore/page/scrolling/ScrollingStateNode.h
M Source/WebCore/page/scrolling/ScrollingStateOverflowScrollingNode.cpp
M Source/WebCore/page/scrolling/ScrollingStateOverflowScrollingNode.h
M Source/WebCore/page/scrolling/ScrollingStatePluginScrollingNode.cpp
M Source/WebCore/page/scrolling/ScrollingStatePluginScrollingNode.h
M Source/WebCore/page/scrolling/ScrollingStateScrollingNode.cpp
M Source/WebCore/page/scrolling/ScrollingStateScrollingNode.h
M Source/WebCore/page/scrolling/ScrollingTreeScrollingNode.h
M Source/WebCore/page/scrolling/mac/ScrollerMac.h
M Source/WebCore/page/scrolling/mac/ScrollerMac.mm
M Source/WebCore/page/scrolling/mac/ScrollerPairMac.h
M Source/WebCore/page/scrolling/mac/ScrollerPairMac.mm
M Source/WebCore/page/scrolling/mac/ScrollingTreeScrollingNodeDelegateMac.mm
M Source/WebKit/Shared/RemoteLayerTree/RemoteScrollingCoordinatorTransaction.serialization.in
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
M Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
A Tools/TestWebKitAPI/Tests/mac/ScrollbarTests.mm
Log Message:
-----------
Cherry-pick 7ecbfb2d01ac. rdar://140215544
[macOS] Toggling dark mode does not update the scrollbar appearance on <body>
https://bugs.webkit.org/show_bug.cgi?id=282655
rdar://138108344
Reviewed by Wenson Hsieh and Abrar Rahman Protyasha.
With UI-side compositing, scrollbar appearance changes are propagated via
`ScrollableAreaParameters`. However, nothing actually tells the scrollbars
to repaint, resulting in a state mismatch between content and its scrollbars.
Fix by adding a new `ScrollingStateNodeProperty`, noting appearance changes,
and ultimately calling `-[NSScrollerImp setNeedsDisplay:]` to trigger a repaint.
* Source/WebCore/page/scrolling/AsyncScrollingCoordinator.cpp:
(WebCore::AsyncScrollingCoordinator::setScrollingNodeScrollableAreaGeometry):
The bit on `ScrollableAreaParameters` is now redundant with the information on
the state node.
* Source/WebCore/page/scrolling/ScrollingCoordinatorTypes.h:
* Source/WebCore/page/scrolling/ScrollingStateFrameScrollingNode.cpp:
(WebCore::ScrollingStateFrameScrollingNode::ScrollingStateFrameScrollingNode):
* Source/WebCore/page/scrolling/ScrollingStateFrameScrollingNode.h:
* Source/WebCore/page/scrolling/ScrollingStateNode.h:
* Source/WebCore/page/scrolling/ScrollingStateOverflowScrollingNode.cpp:
(WebCore::ScrollingStateOverflowScrollingNode::ScrollingStateOverflowScrollingNode):
* Source/WebCore/page/scrolling/ScrollingStateOverflowScrollingNode.h:
* Source/WebCore/page/scrolling/ScrollingStatePluginScrollingNode.cpp:
(WebCore::ScrollingStatePluginScrollingNode::ScrollingStatePluginScrollingNode):
* Source/WebCore/page/scrolling/ScrollingStatePluginScrollingNode.h:
* Source/WebCore/page/scrolling/ScrollingStateScrollingNode.cpp:
(WebCore::ScrollingStateScrollingNode::ScrollingStateScrollingNode):
(WebCore::ScrollingStateScrollingNode::setUseDarkAppearanceForScrollbars):
* Source/WebCore/page/scrolling/ScrollingStateScrollingNode.h:
(WebCore::ScrollingStateScrollingNode::useDarkAppearanceForScrollbars const):
* Source/WebCore/page/scrolling/ScrollingTreeScrollingNode.h:
* Source/WebCore/page/scrolling/mac/ScrollerMac.h:
* Source/WebCore/page/scrolling/mac/ScrollerMac.mm:
(WebCore::ScrollerMac::setNeedsDisplay):
* Source/WebCore/page/scrolling/mac/ScrollerPairMac.h:
* Source/WebCore/page/scrolling/mac/ScrollerPairMac.mm:
(WebCore::ScrollerPairMac::useDarkAppearance const):
(WebCore::ScrollerPairMac::setUseDarkAppearance):
* Source/WebCore/page/scrolling/mac/ScrollingTreeScrollingNodeDelegateMac.mm:
(WebCore::ScrollingTreeScrollingNodeDelegateMac::updateFromStateNode):
Ensure a repaint is triggered when appearance changes.
* Source/WebKit/Shared/RemoteLayerTree/RemoteScrollingCoordinatorTransaction.serialization.in:
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:
* Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* Tools/TestWebKitAPI/Tests/mac/ScrollbarTests.mm: Added.
(TestWebKitAPI::scrollbarLuminanceForWebView):
(TestWebKitAPI::TEST(ScrollbarTests, AppearanceChangeAfterSystemAppearanceChange)):
Add an API test to verify that the scrollbar takes on the correct appearance.
Previously, the scrollbar would remain white after switching to dark mode,
resulting in a luminance close to 1. The test asserts that the scrollbar is a
dark color.
Canonical link: https://commits.webkit.org/286229@main
Canonical link: https://commits.webkit.org/283286.510@safari-7620-branch
Commit: cb6aee915e9265cc8e6b4b5a11913ba7a2523347
https://github.com/WebKit/WebKit/commit/cb6aee915e9265cc8e6b4b5a11913ba7a2523347
Author: Wenson Hsieh <wenson_hsieh at apple.com>
Date: 2024-11-20 (Wed, 20 Nov 2024)
Changed paths:
M Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml
M Source/WebCore/dom/GlobalEventHandlers.idl
M Source/WebCore/page/Quirks.cpp
M Source/WebCore/page/Quirks.h
M Source/WebKit/Shared/WebsitePoliciesData.cpp
M Source/WebKit/Shared/WebsitePoliciesData.h
M Source/WebKit/Shared/WebsitePoliciesData.serialization.in
M Source/WebKit/UIProcess/API/APIWebsitePolicies.h
M Source/WebKit/UIProcess/ios/WebPageProxyIOS.mm
Log Message:
-----------
Cherry-pick 9468b9f87980. rdar://140213486
[iPadOS] Unable to upload files in Secure Messages center on chase.com
https://bugs.webkit.org/show_bug.cgi?id=281905
rdar://126715227
Reviewed by Abrar Rahman Protyasha.
On the desktop version of chase.com, the file upload widget (in the Secure Messages center) disables
file uploads on iPadOS, based on the presence of the DOM window's "ontouchstart" attribute. Add a
quirk to reenable this feature by hiding these DOM attributes on Chase. See below for more details.
* Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml:
* Source/WebCore/dom/GlobalEventHandlers.idl:
Rename `TouchEventsEnabled` to `TouchEventDOMAttributesEnabled`, to more accurately reflect the fact
that this setting only tracks whether or not the touch event DOM attributes are exposed (not whether
touch events as a whole are enabled).
* Source/WebCore/page/Quirks.cpp:
(WebCore::Quirks::shouldOmitTouchEventDOMAttributesForDesktopWebsite):
Add a new static quirks helper to guard this behavior.
* Source/WebCore/page/Quirks.h:
* Source/WebKit/Shared/WebsitePoliciesData.cpp:
(WebKit::WebsitePoliciesData::applyToDocumentLoader):
* Source/WebKit/Shared/WebsitePoliciesData.h:
Add a new `optional<bool>` member that tracks whether or not we should override support for the
touch event handler DOM attributes (`ontouch*`). `nullopt` represents the default behavior, while
`true` / `false` represent the overridden values.
* Source/WebKit/Shared/WebsitePoliciesData.serialization.in:
* Source/WebKit/UIProcess/API/APIWebsitePolicies.h:
* Source/WebKit/UIProcess/ios/WebPageProxyIOS.mm:
(WebKit::WebPageProxy::effectiveContentModeAfterAdjustingPolicies):
When choosing the desktop version of `secure.chase.com`, turn off support for the aforementioned DOM
attributes unless site-specific quirks are disabled.
Canonical link: https://commits.webkit.org/285561@main
Canonical link: https://commits.webkit.org/283286.511@safari-7620-branch
Commit: 6f338a93f7886f9ab2dbb5e057a84a951daffd23
https://github.com/WebKit/WebKit/commit/6f338a93f7886f9ab2dbb5e057a84a951daffd23
Author: Charlie Wolfe <charliew at apple.com>
Date: 2024-11-20 (Wed, 20 Nov 2024)
Changed paths:
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.h
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.messages.in
M Source/WebKit/NetworkProcess/NetworkLoadParameters.h
M Source/WebKit/NetworkProcess/NetworkProcess.cpp
M Source/WebKit/NetworkProcess/NetworkProcess.h
M Source/WebKit/NetworkProcess/NetworkProcess.messages.in
M Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.serialization.in
M Source/WebKit/NetworkProcess/NetworkSession.cpp
M Source/WebKit/NetworkProcess/NetworkSession.h
M Source/WebKit/NetworkProcess/NetworkSocketChannel.cpp
M Source/WebKit/NetworkProcess/NetworkSocketChannel.h
M Source/WebKit/NetworkProcess/cocoa/NetworkDataTaskCocoa.h
M Source/WebKit/NetworkProcess/cocoa/NetworkDataTaskCocoa.mm
M Source/WebKit/NetworkProcess/cocoa/NetworkSessionCocoa.h
M Source/WebKit/NetworkProcess/cocoa/NetworkSessionCocoa.mm
M Source/WebKit/NetworkProcess/cocoa/NetworkTaskCocoa.h
M Source/WebKit/NetworkProcess/cocoa/NetworkTaskCocoa.mm
M Source/WebKit/NetworkProcess/cocoa/WebSocketTaskCocoa.h
M Source/WebKit/NetworkProcess/cocoa/WebSocketTaskCocoa.mm
M Source/WebKit/NetworkProcess/curl/NetworkSessionCurl.cpp
M Source/WebKit/NetworkProcess/curl/WebSocketTaskCurl.h
M Source/WebKit/Shared/NetworkProcessConnectionParameters.h
M Source/WebKit/Shared/NetworkProcessConnectionParameters.serialization.in
M Source/WebKit/UIProcess/Network/NetworkProcessProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/WebProcess/Network/WebLoaderStrategy.cpp
M Source/WebKit/WebProcess/Network/WebSocketChannel.cpp
M Source/WebKit/WebProcess/WebPage/WebCookieJar.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/IPCTestingAPI.mm
Log Message:
-----------
WebContent processes should not be able to disable third-party cookie blocking via ShouldRelaxThirdPartyCookieBlocking
https://bugs.webkit.org/show_bug.cgi?id=283396
rdar://140252273
Reviewed by Sihui Liu.
This change removes a WebContent -> network process message parameter that allows third-party cookie
blocking to be disabled. Instead, the UI process should notify the network process which pages a client
has set to allow third-party cookies.
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:
(WebKit::NetworkConnectionToWebProcess::createSocketChannel):
(WebKit::NetworkConnectionToWebProcess::cookiesForDOM):
(WebKit::NetworkConnectionToWebProcess::setCookiesFromDOM):
(WebKit::NetworkConnectionToWebProcess::cookiesEnabledSync):
(WebKit::NetworkConnectionToWebProcess::cookiesEnabled):
(WebKit::NetworkConnectionToWebProcess::cookieRequestHeaderFieldValue):
(WebKit::NetworkConnectionToWebProcess::getRawCookies):
(WebKit::NetworkConnectionToWebProcess::cookiesForDOMAsync):
(WebKit::NetworkConnectionToWebProcess::setCookieFromDOMAsync):
(WebKit::NetworkConnectionToWebProcess::clearPageSpecificData):
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.h:
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.messages.in:
* Source/WebKit/NetworkProcess/NetworkLoadParameters.h:
(WebKit::NetworkLoadParameters::NetworkLoadParameters):
* Source/WebKit/NetworkProcess/NetworkProcess.cpp:
(WebKit::NetworkProcess::createNetworkConnectionToWebProcess):
(WebKit::NetworkProcess::removeWebPageNetworkParameters):
(WebKit::NetworkProcess::setShouldRelaxThirdPartyCookieBlockingForPage):
(WebKit::NetworkProcess::shouldRelaxThirdPartyCookieBlockingForPage const):
* Source/WebKit/NetworkProcess/NetworkProcess.h:
* Source/WebKit/NetworkProcess/NetworkProcess.messages.in:
* Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.serialization.in:
* Source/WebKit/NetworkProcess/NetworkSession.cpp:
(WebKit::NetworkSession::createWebSocketTask):
* Source/WebKit/NetworkProcess/NetworkSession.h:
* Source/WebKit/NetworkProcess/NetworkSocketChannel.cpp:
(WebKit::NetworkSocketChannel::create):
(WebKit::NetworkSocketChannel::NetworkSocketChannel):
* Source/WebKit/NetworkProcess/NetworkSocketChannel.h:
* Source/WebKit/NetworkProcess/cocoa/NetworkDataTaskCocoa.h:
* Source/WebKit/NetworkProcess/cocoa/NetworkDataTaskCocoa.mm:
(WebKit::NetworkDataTaskCocoa::NetworkDataTaskCocoa):
* Source/WebKit/NetworkProcess/cocoa/NetworkSessionCocoa.h:
* Source/WebKit/NetworkProcess/cocoa/NetworkSessionCocoa.mm:
(WebKit::NetworkSessionCocoa::continueDidReceiveChallenge):
(WebKit::NetworkSessionCocoa::createWebSocketTask):
* Source/WebKit/NetworkProcess/cocoa/NetworkTaskCocoa.h:
(WebKit::NetworkTaskCocoa::shouldRelaxThirdPartyCookieBlocking const): Deleted.
* Source/WebKit/NetworkProcess/cocoa/NetworkTaskCocoa.mm:
(WebKit::NetworkTaskCocoa::NetworkTaskCocoa):
(WebKit::NetworkTaskCocoa::willPerformHTTPRedirection):
(WebKit::NetworkTaskCocoa::shouldRelaxThirdPartyCookieBlocking const):
* Source/WebKit/NetworkProcess/cocoa/WebSocketTaskCocoa.h:
(WebKit::WebSocketTask::webProxyPageID const): Deleted.
* Source/WebKit/NetworkProcess/cocoa/WebSocketTaskCocoa.mm:
(WebKit::WebSocketTask::WebSocketTask):
* Source/WebKit/NetworkProcess/curl/NetworkSessionCurl.cpp:
(WebKit::NetworkSessionCurl::didReceiveChallenge):
* Source/WebKit/NetworkProcess/curl/WebSocketTaskCurl.h:
(WebKit::WebSocketTask::webProxyPageID const): Deleted.
* Source/WebKit/Shared/NetworkProcessConnectionParameters.h:
* Source/WebKit/Shared/NetworkProcessConnectionParameters.serialization.in:
* Source/WebKit/UIProcess/Network/NetworkProcessProxy.cpp:
(WebKit::NetworkProcessProxy::getNetworkProcessConnection):
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::initializeWebPage):
(WebKit::WebPageProxy::createNewPage):
* Source/WebKit/WebProcess/Network/WebLoaderStrategy.cpp:
(WebKit::addParametersShared):
* Source/WebKit/WebProcess/Network/WebSocketChannel.cpp:
(WebKit::WebSocketChannel::connect):
* Source/WebKit/WebProcess/WebPage/WebCookieJar.cpp:
(WebKit::WebCookieJar::cookies const):
(WebKit::WebCookieJar::setCookies):
(WebKit::WebCookieJar::remoteCookiesEnabledSync const):
(WebKit::WebCookieJar::remoteCookiesEnabled const):
(WebKit::WebCookieJar::cookieRequestHeaderFieldValue const):
(WebKit::WebCookieJar::getRawCookies const):
(WebKit::WebCookieJar::getCookiesAsync const):
(WebKit::WebCookieJar::setCookieAsync const):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/IPCTestingAPI.mm:
(EmptyFirstPartyForCookiesCookieRequestHeaderFieldValue)):
(InvalidSameSiteInfoCookieRequestHeaderFieldValue)):
Canonical link: https://commits.webkit.org/283286.512@safari-7620-branch
Commit: 5e06ca5a17cd3175d7ab42e6f13ce056b12c269c
https://github.com/WebKit/WebKit/commit/5e06ca5a17cd3175d7ab42e6f13ce056b12c269c
Author: Youenn Fablet <youenn at apple.com>
Date: 2024-11-20 (Wed, 20 Nov 2024)
Changed paths:
A LayoutTests/http/wpt/mediastream/getUserMedia-rvfc-remove-expected.txt
A LayoutTests/http/wpt/mediastream/getUserMedia-rvfc-remove.html
A LayoutTests/http/wpt/mediastream/resources/getUserMedia-rvfc-remove-iframe.html
M Source/WebCore/html/HTMLVideoElement.cpp
M Source/WebCore/html/HTMLVideoElement.h
Log Message:
-----------
J475d/24C76: Potential UAF in HTMLVideoElement::serviceRequestVideoFrameCallbacks
rdar://140271547
Reviewed by Eric Carlson.
When servicing rvfc requests, we can navigate the document which will stop the HTMLVideoElement.
This will clear the m_servicedVideoFrameRequests, which will delete the requests.
To prevent this issue, we clear the call of VideoFrameRequest but do not clear m_servicedVideoFrameRequests.
We remove VideoFrameRequest::cancelled as we now store a RefPtr callback.
* LayoutTests/http/wpt/mediastream/getUserMedia-rvfc-remove-expected.txt: Added.
* LayoutTests/http/wpt/mediastream/getUserMedia-rvfc-remove.html: Added.
* LayoutTests/http/wpt/mediastream/resources/getUserMedia-rvfc-remove-iframe.html: Added.
* Source/WebCore/html/HTMLVideoElement.cpp:
(WebCore::HTMLVideoElement::cancelVideoFrameCallback):
(WebCore::HTMLVideoElement::stop):
(WebCore::HTMLVideoElement::serviceRequestVideoFrameCallbacks):
* Source/WebCore/html/HTMLVideoElement.h:
Canonical link: https://commits.webkit.org/283286.513@safari-7620-branch
Commit: f3ee0e300b5de4c2df28c0d89c82089d24e9db6e
https://github.com/WebKit/WebKit/commit/f3ee0e300b5de4c2df28c0d89c82089d24e9db6e
Author: Youenn Fablet <youenn at apple.com>
Date: 2024-11-21 (Thu, 21 Nov 2024)
Changed paths:
M Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/test/svc_datarate_test.cc
M Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/test/test-data.mk
M Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/test/test-data.sha1
M Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/vp9/encoder/vp9_pickmode.c
M Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/vp9/encoder/vp9_svc_layercontext.c
Log Message:
-----------
Potential 'overflow, out of bounds' issue commited to upstream libwebrtc
rdar://138895814
Reviewed by Ryan Reno.
Cherry-picking of https://github.com/webmproject/libvpx/commit/727319a77ffe68e9aacb08e09ae7151b3a8f70a3#diff-f535a6aec9d203c6ec84acfda8634fd78e50cd9e7fd3e05caaf247387bae9497R789.
* Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/test/svc_datarate_test.cc:
* Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/test/test-data.mk:
* Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/test/test-data.sha1:
* Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/vp9/encoder/vp9_pickmode.c:
* Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/vp9/encoder/vp9_svc_layercontext.c:
(vp9_one_pass_svc_start_layer):
Canonical link: https://commits.webkit.org/283286.514@safari-7620-branch
Commit: 2f45443a540c205bbbf70cb7ae67b38c49a91881
https://github.com/WebKit/WebKit/commit/2f45443a540c205bbbf70cb7ae67b38c49a91881
Author: Razvan Caliman <rcaliman at apple.com>
Date: 2024-11-21 (Thu, 21 Nov 2024)
Changed paths:
M Source/WebInspectorUI/UserInterface/Views/DOMTreeOutline.css
Log Message:
-----------
Cherry-pick c0cef41981cc. rdar://140221149
Web Inspector: Elements tab DOM tree view reduces deeply-nested nodes to one character wide
https://bugs.webkit.org/show_bug.cgi?id=234376
rdar://86833831
Reviewed by BJ Burg.
Set a minimum width for DOM tree outline items to prevent wrapping to unusable widths.
Ensure the containing block for the absolutely-positioned selection area
(the blue/gray highlight for selected tree items) spans the full width of the scroll container.
Without this change, the absolutely-positioned element spans only the width of the scroll port,
and appears cut-off when scrolling horizontally.
* Source/WebInspectorUI/UserInterface/Views/DOMTreeContentView.css:
(.content-view.dom-tree > .tree-outline-wrapper):
* Source/WebInspectorUI/UserInterface/Views/DOMTreeContentView.js:
(WI.DOMTreeContentView):
* Source/WebInspectorUI/UserInterface/Views/DOMTreeOutline.css:
(.tree-outline.dom):
(.tree-outline.dom li):
* Source/WebInspectorUI/UserInterface/Views/TreeOutline.js:
(WI.TreeOutline.prototype.treeElementFromEvent):
Canonical link: https://commits.webkit.org/286163@main
Canonical link: https://commits.webkit.org/283286.515@safari-7620-branch
Commit: fc73a0b209cffe5295314f732b0323ff56a66b6e
https://github.com/WebKit/WebKit/commit/fc73a0b209cffe5295314f732b0323ff56a66b6e
Author: Youenn Fablet <youenn at apple.com>
Date: 2024-11-21 (Thu, 21 Nov 2024)
Changed paths:
M Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml
Log Message:
-----------
J718/22C5142a: FaceTime video flipped upside-down in Safari call
rdar://140305310
Reviewed by Eric Carlson.
Rotation is incorrect on some iPads when this flag is on.
We temporarily disable the flag until we fix that issue for those iPads.
* Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml:
Canonical link: https://commits.webkit.org/283286.516@safari-7620-branch
Commit: 0eb059ade84ee1244b10573b217f71ad533b9b67
https://github.com/WebKit/WebKit/commit/0eb059ade84ee1244b10573b217f71ad533b9b67
Author: Timothy Hatcher <timothy at apple.com>
Date: 2024-11-21 (Thu, 21 Nov 2024)
Changed paths:
M Source/WTF/wtf/cocoa/LanguageCocoa.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebExtensionAPILocalization.mm
Log Message:
-----------
Cherry-pick 40b5fc57f5e1. rdar://140279190
Crash in WebKit::WebExtension::bestMatchLocale().
https://webkit.org/b/283387
rdar://140134905
Reviewed by Brian Weinstein.
WebExtension::bestMatchLocale() was expecting notFound from indexOfBestMatchingLanguageInList()
which is the case for non-Cocoa platforms, but this case was missed in the Cocoa implementation.
* Source/WTF/wtf/cocoa/LanguageCocoa.mm:
(WTF::indexOfBestMatchingLanguageInList): Return notFound instead of size() when the array is empty.
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebExtensionAPILocalization.mm:
(TestWebKitAPI::TEST(WKWebExtensionAPILocalization, i18nSwedishDefaultToEnglish)): Added.
Canonical link: https://commits.webkit.org/286839@main
Canonical link: https://commits.webkit.org/283286.517@safari-7620-branch
Commit: 75195593956bab8aa0f230efb1e5e37b895ece22
https://github.com/WebKit/WebKit/commit/75195593956bab8aa0f230efb1e5e37b895ece22
Author: Jean-Yves Avenard <jya at apple.com>
Date: 2024-11-21 (Thu, 21 Nov 2024)
Changed paths:
M Source/WebCore/page/Quirks.cpp
Log Message:
-----------
Cherry-pick c3683f9184f3. rdar://140231789
[iPhone] PiP with Forbes.com stuck on a single frame
https://bugs.webkit.org/show_bug.cgi?id=282160
rdar://102086489
Reviewed by Youenn Fablet.
Add forbes.com quirks setting requiresUserGestureToPauseInPictureInPicture.
Manually tested.
* Source/WebCore/page/Quirks.cpp:
(WebCore::Quirks::requiresUserGestureToPauseInPictureInPicture const):
Canonical link: https://commits.webkit.org/285758@main
Canonical link: https://commits.webkit.org/283286.518@safari-7620-branch
Commit: 21e99e5afce35cff6f1c73feaae7766ee16dba57
https://github.com/WebKit/WebKit/commit/21e99e5afce35cff6f1c73feaae7766ee16dba57
Author: Daniel Liu <daniel_liu4 at apple.com>
Date: 2024-11-21 (Thu, 21 Nov 2024)
Changed paths:
A JSTests/stress/resize-array-buffer-constantly.js
M Source/JavaScriptCore/assembler/AbstractMacroAssembler.h
M Source/JavaScriptCore/dfg/DFGSlowPathGenerator.h
M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp
M Source/JavaScriptCore/dfg/DFGSpeculativeJIT32_64.cpp
M Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp
Log Message:
-----------
Improve DFG_REGISTER_ALLOCATION_VALIDATION robustness
https://bugs.webkit.org/show_bug.cgi?id=283142
rdar://139826086
Reviewed by Yusuke Suzuki.
DFG_REGISTER_ALLOCATION_VALIDATION currently checks for branches, but does not
consider slow paths. This leads to an oversight during validation that could
allow bugs to slip in.
* JSTests/stress/resize-array-buffer-constantly.js: Added.
(main):
* Source/JavaScriptCore/assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::RegisterAllocationOffset::checkOffset):
(JSC::AbstractMacroAssembler::checkRegisterAllocationAgainstSlowPathCall):
* Source/JavaScriptCore/dfg/DFGSlowPathGenerator.h:
(JSC::DFG::slowPathCall):
Canonical link: https://commits.webkit.org/283286.519@safari-7620-branch
Commit: cb547545007c8caf044a903fc0b009062b4caf99
https://github.com/WebKit/WebKit/commit/cb547545007c8caf044a903fc0b009062b4caf99
Author: Ben Nham <nham at apple.com>
Date: 2024-11-21 (Thu, 21 Nov 2024)
Changed paths:
M Source/WebKit/NetworkProcess/Notifications/WebPushDaemonConnection.h
M Source/WebKit/Shared/WebPushDaemonConstants.h
M Source/WebKit/webpushd/PushClientConnection.h
M Source/WebKit/webpushd/PushClientConnection.messages.in
M Source/WebKit/webpushd/PushClientConnection.mm
M Source/WebKit/webpushd/WebPushDaemon.h
M Source/WebKit/webpushd/WebPushDaemon.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WebPushDaemon.mm
Log Message:
-----------
Cherry-pick a427fa53db75. rdar://140226860
Raise exception when a webpushd connection error occurs
https://bugs.webkit.org/show_bug.cgi?id=281886
rdar://138358189
Reviewed by Sihui Liu.
In the past there have been some bugs which cause a WebKit client to try to talk to webpushd with
mismatching IPC protocol versions (e.g. bug 281155). This causes webpushd to terminate the IPC
connection, which then causes a default-constructed response object to be returned to the caller in
the client process.
For most webpushd IPCs, the default-constructed response makes sense. For instance, if the client
tries to send the GetPushPermissionState IPC and this type of IPC protocol mismatch occurs, then a
default-constructed PushPermissionState is returned, which is PushPermissionState::Denied. However,
for SubscribeToPushService, this does not make sense, as a default-constructed PushSubscription
object is returned which has an empty endpoint URL and keys dictionary.
Fix this by making GetPushPermissionState raise an AbortError via an AsyncReplyError if there is an
IPC protocol mismatch. I put this AsyncReplyError in the WebPushDaemonConnection header since it's a
common header imported by both _WKWebPushDaemonConnection and NetworkNotificationManager.
* Source/WebKit/NetworkProcess/Notifications/WebPushDaemonConnection.h:
* Source/WebKit/Shared/WebPushDaemonConstants.h:
* Source/WebKit/webpushd/PushClientConnection.h:
* Source/WebKit/webpushd/PushClientConnection.messages.in:
* Source/WebKit/webpushd/PushClientConnection.mm:
(WebPushD::PushClientConnection::setProtocolVersionForTesting):
* Source/WebKit/webpushd/WebPushDaemon.h:
* Source/WebKit/webpushd/WebPushDaemon.mm:
(WebPushD::WebPushDaemon::connectionEventHandler):
(WebPushD::WebPushDaemon::setProtocolVersionForTesting):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WebPushDaemon.mm:
(TestWebKitAPI::(WebPushDTest, SubscribeWithBadIPCVersionRaisesExceptionTest)):
(TestWebKitAPI::(WebPushD, WKWebPushDaemonConnectionSubscribeWithBadIPCVersionRaisesException)):
Canonical link: https://commits.webkit.org/285610@main
Canonical link: https://commits.webkit.org/283286.520@safari-7620-branch
Commit: c1381e057fea52e345c41b1f75049c55a8ea069a
https://github.com/WebKit/WebKit/commit/c1381e057fea52e345c41b1f75049c55a8ea069a
Author: Elijah Sawyers <esawyers at apple.com>
Date: 2024-11-21 (Thu, 21 Nov 2024)
Changed paths:
M Source/WebKit/UIProcess/API/Cocoa/WKWebExtensionTab.h
M Source/WebKit/UIProcess/Extensions/Cocoa/WebExtensionTabCocoa.mm
M Source/WebKit/UIProcess/Extensions/WebExtensionTab.h
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebExtensionAPITabs.mm
M Tools/TestWebKitAPI/cocoa/WebExtensionUtilities.h
M Tools/TestWebKitAPI/cocoa/WebExtensionUtilities.mm
Log Message:
-----------
Cherry-pick ee317d6acf78. rdar://140122976
Browsers should have a way to allow a tab to skip the permissions check
https://webkit.org/b/283197
rdar://problem/102199510
Reviewed by Timothy Hatcher.
This patch introduces a new delegate method for a WKWebExtensionTab
that allows the browser to specify whether or not a tab should be
able to skip the permissions check.
* Source/WebKit/UIProcess/API/Cocoa/WKWebExtensionTab.h:
* Source/WebKit/UIProcess/Extensions/Cocoa/WebExtensionTabCocoa.mm:
(WebKit::WebExtensionTab::WebExtensionTab):
(WebKit::WebExtensionTab::extensionHasPermission const):
* Source/WebKit/UIProcess/Extensions/WebExtensionTab.h:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebExtensionAPITabs.mm:
(TestWebKitAPI::TEST(WKWebExtensionAPITabs, QueryWithPermissionBypass)):
* Tools/TestWebKitAPI/cocoa/WebExtensionUtilities.h:
* Tools/TestWebKitAPI/cocoa/WebExtensionUtilities.mm:
(-[TestWebExtensionTab shouldBypassPermissionsForWebExtensionContext:]):
Canonical link: https://commits.webkit.org/286726@main
Canonical link: https://commits.webkit.org/283286.521@safari-7620-branch
Commit: 02a1e6182b0e211754b5de2a24f2bdd7467b272f
https://github.com/WebKit/WebKit/commit/02a1e6182b0e211754b5de2a24f2bdd7467b272f
Author: Jessica Cheung <jcheung23 at apple.com>
Date: 2024-11-21 (Thu, 21 Nov 2024)
Changed paths:
A LayoutTests/editing/selection/ios/hide-selection-in-hidden-container-noneditable-expected.txt
A LayoutTests/editing/selection/ios/hide-selection-in-hidden-container-noneditable.html
M Source/WebCore/dom/Position.h
M Source/WebKit/Shared/EditorState.h
M Source/WebKit/Shared/EditorState.serialization.in
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.h
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
M Source/WebKit/UIProcess/mac/WebViewImpl.mm
M Source/WebKit/WebProcess/WebPage/Cocoa/WebPageCocoa.mm
M Source/WebKit/WebProcess/WebPage/WebPage.h
Log Message:
-----------
Cherry-pick 0bbbd26aee60. rdar://140215491
icloud.com: duplicate and strangely offset highlight in icloud.com notes
https://bugs.webkit.org/show_bug.cgi?id=282102
rdar://137094713
Reviewed by Wenson Hsieh.
icloud.com renders their own selection in their style so we should
hide our real selection UI. However, we display our selection as well
in addition to icloud.com notes which results in the strange duplicate offset
selection being shown.
We should change the logic of supressing selection to include
if selection container element is clipped/transparent instead of just if the
editable root element is clipped/transparent.
In this example, when we are not editing, the duplicate selection is shown.
Finally, added a LayoutTest to confirm this new behavior works as intended by selecting
something noneditable in a hidden container.
* LayoutTests/editing/selection/ios/hide-selection-in-hidden-container-noneditable-expected.txt: Added.
* LayoutTests/editing/selection/ios/hide-selection-in-hidden-container-noneditable.html: Added.
* Source/WebCore/dom/Position.h:
* Source/WebKit/Shared/EditorState.h:
* Source/WebKit/Shared/EditorState.serialization.in:
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.h:
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _updateSelectionAssistantSuppressionState]):
(-[WKContentView hasHiddenContentEditable]):
* Source/WebKit/UIProcess/mac/WebViewImpl.mm:
(WebKit::WebViewImpl::updateCursorAccessoryPlacement):
* Source/WebKit/WebProcess/WebPage/Cocoa/WebPageCocoa.mm:
(WebKit::WebPage::isTransparentOrFullyClipped const):
(WebKit::WebPage::getPlatformEditorStateCommon const):
* Source/WebKit/WebProcess/WebPage/WebPage.h:
Canonical link: https://commits.webkit.org/285925@main
Canonical link: https://commits.webkit.org/283286.522@safari-7620-branch
Commit: 0af14c0675d303472c32f53843f23c9ed88f3aef
https://github.com/WebKit/WebKit/commit/0af14c0675d303472c32f53843f23c9ed88f3aef
Author: Matt Woodrow <mattwoodrow at apple.com>
Date: 2024-11-21 (Thu, 21 Nov 2024)
Changed paths:
M Source/WebCore/rendering/style/RenderStyle.cpp
M Source/WebCore/rendering/style/RenderStyle.h
M Source/WebCore/rendering/updating/RenderTreeUpdater.cpp
M Source/WebCore/style/PseudoElementIdentifier.h
Log Message:
-----------
Cherry-pick 8bf42cf44a8b. rdar://140162808
Use a HashTable for cached pseudo styles.
https://bugs.webkit.org/show_bug.cgi?id=282376
<rdar://138980565>
Reviewed by Antti Koivisto.
View Transitions can add a lot of pseudo elements to the document node, iterating a list is slow.
* Source/WebCore/rendering/style/RenderStyle.cpp:
(WebCore::RenderStyle::copyPseudoElementsFrom):
(WebCore::RenderStyle::hasUniquePseudoStyle const):
(WebCore::RenderStyle::getCachedPseudoStyle const):
(WebCore::RenderStyle::addCachedPseudoStyle):
* Source/WebCore/rendering/style/RenderStyle.h:
* Source/WebCore/rendering/updating/RenderTreeUpdater.cpp:
(WebCore::pseudoStyleCacheIsInvalid):
Canonical link: https://commits.webkit.org/286014@main
Canonical link: https://commits.webkit.org/283286.523@safari-7620-branch
Commit: 76fae8c85e1699e6dac14a9be4b4574d4b466bef
https://github.com/WebKit/WebKit/commit/76fae8c85e1699e6dac14a9be4b4574d4b466bef
Author: Matt Woodrow <mattwoodrow at apple.com>
Date: 2024-11-21 (Thu, 21 Nov 2024)
Changed paths:
A LayoutTests/fast/css/view-transitions-no-content-for-new-pseudo-expected.txt
A LayoutTests/fast/css/view-transitions-no-content-for-new-pseudo.html
A LayoutTests/platform/mac-wk1/fast/css/view-transitions-no-content-for-new-pseudo-expected.txt
M LayoutTests/platform/win/TestExpectations
M Source/WebCore/rendering/RenderEmbeddedObject.cpp
M Source/WebCore/rendering/RenderEmbeddedObject.h
M Source/WebCore/rendering/RenderLayerBacking.cpp
M Source/WebCore/rendering/RenderReplaced.h
M Source/WebCore/rendering/RenderViewTransitionCapture.cpp
M Source/WebCore/rendering/RenderViewTransitionCapture.h
Log Message:
-----------
Cherry-pick 2c059ec5441d. rdar://140162778
RenderViewTransitionCapture unconditionally allocates a backing store.
https://bugs.webkit.org/show_bug.cgi?id=282077
<rdar://138601957>
Reviewed by Tim Nguyen.
The RenderLayerBacking for RenderViewTransitionCapture always allocates a
backing store, since isSimpleContainerCompositingLayer always returns false for
RenderReplaced subclasses.
When being used for a ::view-transition-new() pseudo element, this layer just
exists to attach other composited layers to, and doesn't draw anything itself
(unless it has box decorations etc).
* LayoutTests/fast/css/view-transitions-no-content-for-new-pseudo-expected.txt: Added.
* LayoutTests/fast/css/view-transitions-no-content-for-new-pseudo.html: Added.
* Source/WebCore/rendering/RenderEmbeddedObject.cpp:
(WebCore::RenderEmbeddedObject::paintsContent const):
* Source/WebCore/rendering/RenderEmbeddedObject.h:
* Source/WebCore/rendering/RenderLayerBacking.cpp:
(WebCore::RenderLayerBacking::isSimpleContainerCompositingLayer const):
(WebCore::isCompositedPlugin): Deleted.
* Source/WebCore/rendering/RenderReplaced.h:
(WebCore::RenderReplaced::paintsContent const):
* Source/WebCore/rendering/RenderViewTransitionCapture.cpp:
(WebCore::RenderViewTransitionCapture::paintsContent const):
* Source/WebCore/rendering/RenderViewTransitionCapture.h:
Canonical link: https://commits.webkit.org/285978@main
Canonical link: https://commits.webkit.org/283286.524@safari-7620-branch
Commit: a8c083570032722ec31d35f7b9166ff1d151bb15
https://github.com/WebKit/WebKit/commit/a8c083570032722ec31d35f7b9166ff1d151bb15
Author: Charlie Wolfe <charliew at apple.com>
Date: 2024-11-21 (Thu, 21 Nov 2024)
Changed paths:
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.h
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.messages.in
M Source/WebKit/NetworkProcess/NetworkSession.h
M Source/WebKit/WebProcess/WebPage/WebCookieJar.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/IPCTestingAPI.mm
Log Message:
-----------
WebContent processes should not be able to disable third-party cookie blocking via ApplyTrackingPrevention
https://bugs.webkit.org/show_bug.cgi?id=283462
rdar://140320313
Reviewed by Sihui Liu.
This change removes a WebContent -> network process message parameter `ApplyTrackingPrevention` that
allows third-party cookie blocking to be disabled. The conditions that were being checked in the web
process to determine if tracking prevention should be applied should match the network process side
function that all of these IPC endpoints use (`NetworkStorageSession::shouldBlockCookies`).
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:
(WebKit::NetworkConnectionToWebProcess::cookiesForDOM):
(WebKit::NetworkConnectionToWebProcess::setCookiesFromDOM):
(WebKit::NetworkConnectionToWebProcess::cookieRequestHeaderFieldValue):
(WebKit::NetworkConnectionToWebProcess::getRawCookies):
(WebKit::NetworkConnectionToWebProcess::cookiesForDOMAsync):
(WebKit::NetworkConnectionToWebProcess::setCookieFromDOMAsync):
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.h:
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.messages.in:
* Source/WebKit/NetworkProcess/NetworkSession.h:
(WebKit::NetworkSession::thirdPartyCookieBlockingMode const):
* Source/WebKit/WebProcess/WebPage/WebCookieJar.cpp:
(WebKit::shouldBlockCookies):
(WebKit::WebCookieJar::cookies const):
(WebKit::WebCookieJar::setCookies):
(WebKit::WebCookieJar::cookiesEnabled):
(WebKit::WebCookieJar::cookieRequestHeaderFieldValue const):
(WebKit::WebCookieJar::getRawCookies const):
(WebKit::WebCookieJar::getCookiesAsync const):
(WebKit::WebCookieJar::setCookieAsync const):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/IPCTestingAPI.mm:
(EmptyFirstPartyForCookiesCookieRequestHeaderFieldValue)):
(InvalidSameSiteInfoCookieRequestHeaderFieldValue)):
Canonical link: https://commits.webkit.org/283286.525@safari-7620-branch
Commit: ec43b7b8b8e63568c6673cd97ff00189171d4120
https://github.com/WebKit/WebKit/commit/ec43b7b8b8e63568c6673cd97ff00189171d4120
Author: Charlie Wolfe <charliew at apple.com>
Date: 2024-11-21 (Thu, 21 Nov 2024)
Changed paths:
M Source/WebCore/loader/CookieJar.cpp
M Source/WebCore/platform/network/NetworkStorageSession.h
M Source/WebCore/platform/network/cocoa/NetworkStorageSessionCocoa.mm
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.h
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.messages.in
M Source/WebKit/WebProcess/WebPage/WebCookieJar.cpp
Log Message:
-----------
NetworkConnectionToWebProcess::setRawCookie and NetworkConnectionToWebProcess::deleteCookie are missing Data Isolation checks
https://bugs.webkit.org/show_bug.cgi?id=283470
rdar://140187716
Reviewed by Pascoe.
* Source/WebCore/loader/CookieJar.cpp:
(WebCore::CookieJar::deleteCookie):
* Source/WebCore/platform/network/NetworkStorageSession.h:
* Source/WebCore/platform/network/cocoa/NetworkStorageSessionCocoa.mm:
(WebCore::NetworkStorageSession::setCookie):
(WebCore::NetworkStorageSession::deleteCookie const):
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:
(WebKit::NetworkConnectionToWebProcess::setRawCookie):
(WebKit::NetworkConnectionToWebProcess::deleteCookie):
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.h:
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.messages.in:
* Source/WebKit/WebProcess/WebPage/WebCookieJar.cpp:
(WebKit::WebCookieJar::setRawCookie):
(WebKit::WebCookieJar::deleteCookie):
Canonical link: https://commits.webkit.org/283286.526@safari-7620-branch
Commit: 8ade047f9f0b06f77371b7a3c012420598921a58
https://github.com/WebKit/WebKit/commit/8ade047f9f0b06f77371b7a3c012420598921a58
Author: Abrar Rahman Protyasha <a_protyasha at apple.com>
Date: 2024-11-22 (Fri, 22 Nov 2024)
Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm
Log Message:
-----------
Cherry-pick 286217 at main (2e5a1a1dc7af). rdar://140380909
Build failure: -[PDFSelection {html, webArchive}] is deprecated in certain SDKs
https://bugs.webkit.org/show_bug.cgi?id=282679
rdar://139343962
Unreviewed build fix.
Fix the macOS build by allowing deprecated declarations for
-[PDFSelection {html, webAcrhive}], since the methods in question have
been deprecated in certain SDKs.
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::performCopyEditingOperation const):
Canonical link: https://commits.webkit.org/286217@main
Canonical link: https://commits.webkit.org/283286.527@safari-7620-branch
Commit: 1265651ee93fa58dc20c66708cad9ae2ebc02a37
https://github.com/WebKit/WebKit/commit/1265651ee93fa58dc20c66708cad9ae2ebc02a37
Author: Jean-Yves Avenard <jya at apple.com>
Date: 2024-11-22 (Fri, 22 Nov 2024)
Changed paths:
A LayoutTests/media/content/test-vp9-dar.webm
A LayoutTests/media/media-vp9-dar-webm-expected.txt
A LayoutTests/media/media-vp9-dar-webm.html
M LayoutTests/platform/mac-wk1/TestExpectations
M Source/WebCore/PAL/pal/cf/CoreMediaSoftLink.cpp
M Source/WebCore/PAL/pal/cf/CoreMediaSoftLink.h
M Source/WebCore/platform/graphics/cocoa/CMUtilities.mm
M Source/WebCore/platform/graphics/cocoa/SourceBufferParserWebM.cpp
M Source/WebCore/platform/graphics/cocoa/VP9UtilitiesCocoa.h
M Source/WebCore/platform/graphics/cocoa/VP9UtilitiesCocoa.mm
Log Message:
-----------
Cherry-pick f5992b64d864. rdar://140303538
DAR/SAR/PAR aspect ratios not respected for VP9 WebM
https://bugs.webkit.org/show_bug.cgi?id=281781
rdar://138642717
Reviewed by Eric Carlson.
Display Aspect Ratio set in the webm container or VP9 bytestream were ignored.
Additionally, prefer the container's display size over the vp9's bytestream one.
Added test.
* LayoutTests/media/content/test-vp9-dar.webm: Added.
* LayoutTests/media/media-vp9-dar-webm-expected.txt: Added.
* LayoutTests/media/media-vp9-dar-webm.html: Added.
* Source/WebCore/PAL/pal/cf/CoreMediaSoftLink.cpp:
* Source/WebCore/PAL/pal/cf/CoreMediaSoftLink.h:
* Source/WebCore/platform/graphics/cocoa/CMUtilities.mm:
(WebCore::createFormatDescriptionFromTrackInfo):
* Source/WebCore/platform/graphics/cocoa/SourceBufferParserWebM.cpp:
(WebCore::WebMParser::VideoTrackData::consumeFrameData):
* Source/WebCore/platform/graphics/cocoa/VP9UtilitiesCocoa.h:
* Source/WebCore/platform/graphics/cocoa/VP9UtilitiesCocoa.mm:
(WebCore::createVideoInfoFromVPCodecConfigurationRecord):
(WebCore::createVideoInfoFromVP9HeaderParser):
(WebCore::createVideoInfoFromVP8Header):
Canonical link: https://commits.webkit.org/285809@main
Canonical link: https://commits.webkit.org/283286.528@safari-7620-branch
Commit: 3b2a3236c52ab463c5c4e89ea58392206097c7ac
https://github.com/WebKit/WebKit/commit/3b2a3236c52ab463c5c4e89ea58392206097c7ac
Author: Ada Chan <adachan at apple.com>
Date: 2024-11-22 (Fri, 22 Nov 2024)
Changed paths:
M Source/WebCore/Modules/webxr/WebXRSession.cpp
M Source/WebCore/platform/xr/PlatformXR.h
M Source/WebKit/Shared/XR/XRDeviceInfo.h
M Source/WebKit/Shared/XR/XRDeviceProxy.cpp
M Source/WebKit/Shared/XR/XRDeviceProxy.h
M Source/WebKit/Shared/XR/XRSystem.serialization.in
Log Message:
-----------
Cherry-pick d0b1b549a5d4. rdar://140284122
[WebXR] Use minimum near clip plane distance from the system for clamping
https://bugs.webkit.org/show_bug.cgi?id=282321
rdar://138811538
Reviewed by Mike Wyrzykowski.
Instead of hardcoding the minimum near clip plane distance, allow the system
to pass that value via XRDeviceInfo. WebXRSession will get that value
from PlatformXR::Device::minimumNearClipPlane().
* Source/WebCore/Modules/webxr/WebXRSession.cpp:
(WebCore::WebXRSession::WebXRSession):
(WebCore::WebXRSession::applyPendingRenderState):
Set the PlatformXR::RequestData based on the depth range from m_activeRenderState
after the values are clamped.
* Source/WebCore/platform/xr/PlatformXR.h:
(PlatformXR::Device::minimumNearClipPlane const):
* Source/WebKit/Shared/XR/XRDeviceInfo.h:
* Source/WebKit/Shared/XR/XRDeviceProxy.cpp:
(WebKit::XRDeviceProxy::XRDeviceProxy):
* Source/WebKit/Shared/XR/XRDeviceProxy.h:
* Source/WebKit/Shared/XR/XRSystem.serialization.in:
Canonical link: https://commits.webkit.org/285955@main
Canonical link: https://commits.webkit.org/283286.529@safari-7620-branch
Commit: a655dfcb45385f6bd863b48f397d8c4b5b7de8f9
https://github.com/WebKit/WebKit/commit/a655dfcb45385f6bd863b48f397d8c4b5b7de8f9
Author: Abrar Rahman Protyasha <a_protyasha at apple.com>
Date: 2024-11-22 (Fri, 22 Nov 2024)
Changed paths:
M Source/WebKit/Platform/spi/Cocoa/PDFKitSPI.h
M Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.mm
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm
Log Message:
-----------
Cherry-pick 9f8355e31ea0. rdar://140213549
Cannot paste text from PDF in Safari to Keynote
https://bugs.webkit.org/show_bug.cgi?id=282715
rdar://136075998
Reviewed by Wenson Hsieh.
Both -[PDFSelection {webArchive, html}] have been deprecated, with the
former returning nil unconditionally and the latter being generally
broken in macOS 15. This meant that we were advertisting pasteboard data
types with empty items, which mislead clients and resulted in symptoms
captured by the bug title.
This patch does the following to address the bug:
1. Drops our call to -[PDFSelection webArchive], since we would never
have any meaningful web archive content to put on the pasteboard.
2. Adopts -[PDFSelection htmlData] in lieu of -[PDFSelection html].
3. Advertises RTF data on the pasteboard by adopting -[PDFSelection
rtfData].
We also:
1. Reorder the order of the pasteboard items we are inserting in the
plugin so that higher fidelity data (HTML/RTF) appears before plain
string data.
2. Change the signature of PDFPluginBase::writeItemsToPasteboard() so
that callers cannot mistakenly provide mismatching arrays for items
and types.
* Source/WebKit/Platform/spi/Cocoa/PDFKitSPI.h:
* Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm:
(-[WKPDFLayerControllerDelegate writeItemsToPasteboard:withTypes:]):
(WebKit::PDFPlugin::handleEditingCommand):
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h:
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.mm:
(WebKit::PDFPluginBase::writeItemsToPasteboard const):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::performCopyLinkOperation const):
(WebKit::htmlDataFromSelection):
(WebKit::UnifiedPDFPlugin::performCopyEditingOperation const):
(WebKit::UnifiedPDFPlugin::takeFindStringFromSelection):
Canonical link: https://commits.webkit.org/286274@main
Canonical link: https://commits.webkit.org/283286.530@safari-7620-branch
Commit: f390e74cbf1d708df210db1a5bd2686002e76b47
https://github.com/WebKit/WebKit/commit/f390e74cbf1d708df210db1a5bd2686002e76b47
Author: Matt Woodrow <mattwoodrow at apple.com>
Date: 2024-11-22 (Fri, 22 Nov 2024)
Changed paths:
M Source/WebCore/platform/graphics/GraphicsLayer.h
M Source/WebCore/platform/graphics/ca/GraphicsLayerCA.cpp
M Source/WebCore/platform/graphics/ca/GraphicsLayerCA.h
M Source/WebCore/rendering/RenderLayerBacking.cpp
M Source/WebCore/rendering/RenderViewTransitionCapture.h
M Source/WebKit/Shared/RemoteLayerTree/RemoteLayerWithRemoteRenderingBackingStore.mm
M Source/WebKit/WebProcess/WebPage/RemoteLayerTree/GraphicsLayerCARemote.h
M Source/WebKit/WebProcess/WebPage/RemoteLayerTree/GraphicsLayerCARemote.mm
Log Message:
-----------
Cherry-pick 66eb479d335a. rdar://140162829
RenderViewTransitionCapture should be able to use its ImageBuffer directly as layer contents.
https://bugs.webkit.org/show_bug.cgi?id=282424
<rdar://139050217>
Reviewed by Kimmo Kinnunen.
The existing setContentsToImage path is disabled for UI-side compositing, due to
lack of support for a remote NativeImage. Adds a new option that is supported
with UI-side compositing, setContentsToImageBuffer.
Change RenderLayerBacking to detect RenderViewTransitionCapture as a suitable
image source, and pass the ImageBuffer through to the GraphicsLayer.
* Source/WebCore/platform/graphics/GraphicsLayer.h:
(WebCore::GraphicsLayer::setContentsToImageBuffer):
(WebCore::GraphicsLayer::shouldDirectlyCompositeImageBuffer const):
* Source/WebCore/platform/graphics/ca/GraphicsLayerCA.cpp:
(WebCore::GraphicsLayerCA::setContentsToImage):
(WebCore::GraphicsLayerCA::setContentsToImageBuffer):
(WebCore::GraphicsLayerCA::platformCALayerDelegatesDisplay const):
(WebCore::GraphicsLayerCA::platformCALayerLayerDisplay):
(WebCore::GraphicsLayerCA::updateContentsImage):
* Source/WebCore/platform/graphics/ca/GraphicsLayerCA.h:
(WebCore::GraphicsLayerCA::setLayerContentsToImageBuffer):
* Source/WebCore/rendering/RenderLayerBacking.cpp:
(WebCore::RenderLayerBacking::updateConfiguration):
(WebCore::RenderLayerBacking::updateContentsRects):
(WebCore::RenderLayerBacking::isDirectlyCompositedImage const):
(WebCore::RenderLayerBacking::updateImageContents):
(WebCore::RenderLayerBacking::contentsBox const):
* Source/WebCore/rendering/RenderViewTransitionCapture.h:
* Source/WebKit/Shared/RemoteLayerTree/RemoteLayerWithRemoteRenderingBackingStore.mm:
(WebKit::RemoteLayerWithRemoteRenderingBackingStore::ensureBackingStore):
* Source/WebKit/WebProcess/WebPage/RemoteLayerTree/GraphicsLayerCARemote.h:
* Source/WebKit/WebProcess/WebPage/RemoteLayerTree/GraphicsLayerCARemote.mm:
(WebKit::GraphicsLayerCARemote::shouldDirectlyCompositeImageBuffer const):
(WebKit::GraphicsLayerCARemote::setLayerContentsToImageBuffer):
Canonical link: https://commits.webkit.org/286139@main
Canonical link: https://commits.webkit.org/283286.531@safari-7620-branch
Commit: 69a2c6c07e30e5706a5c7671b789da75b1047366
https://github.com/WebKit/WebKit/commit/69a2c6c07e30e5706a5c7671b789da75b1047366
Author: Jean-Yves Avenard <jya at apple.com>
Date: 2024-11-22 (Fri, 22 Nov 2024)
Changed paths:
A LayoutTests/media/content/test-h264-709-fullrange.mp4
A LayoutTests/media/content/test-h264-709-videorange.mp4
A LayoutTests/media/content/test-vp8-709-fullrange.webm
A LayoutTests/media/content/test-vp9-709-fullrange.webm
A LayoutTests/media/media-video-fullrange-expected.txt
A LayoutTests/media/media-video-fullrange.html
M LayoutTests/platform/mac-wk1/TestExpectations
M LayoutTests/platform/wpe/TestExpectations
M Source/WebCore/Headers.cmake
M Source/WebCore/PlatformGTK.cmake
M Source/WebCore/PlatformMac.cmake
M Source/WebCore/PlatformPlayStation.cmake
M Source/WebCore/PlatformWPE.cmake
M Source/WebCore/PlatformWin.cmake
M Source/WebCore/platform/graphics/VP9Utilities.cpp
M Source/WebCore/platform/graphics/VP9Utilities.h
M Source/WebCore/platform/graphics/cocoa/VP9UtilitiesCocoa.mm
M Source/WebCore/platform/graphics/cocoa/WebCoreDecompressionSession.h
M Source/WebCore/platform/graphics/cocoa/WebCoreDecompressionSession.mm
M Source/WebCore/platform/libwebrtc/LibWebRTCVPXVideoDecoder.cpp
Log Message:
-----------
Cherry-pick 58383a97b1c6. rdar://140231781
WebCodec's VP8/VP9 VideoDecoder ignore video/full bitrange.
https://bugs.webkit.org/show_bug.cgi?id=267400
rdar://120830372
Reviewed by Youenn Fablet.
Pass the vpcC atom to the VideoDecoder and have LibWebRTCVPXVideoDecoder parse the VP's codec configuration.
to determine which CVPixelFormatType to use (FullRange or VideoRange).
If no vpcC is passed to the VideoDecoder at construction, we will retrieve the information from the VPx bytestream instead.
Added tests. While the tests do not exercise directly WebCodecs API per say, the VideoDecoder is used when
playing vp8 on iOS and we are indirectly testing the code.
* LayoutTests/media/content/test-h264-709-fullrange.mp4: Added.
* LayoutTests/media/content/test-h264-709-videorange.mp4: Added.
* LayoutTests/media/content/test-vp8-709-fullrange.webm: Added.
* LayoutTests/media/content/test-vp9-709-fullrange.webm: Added.
* LayoutTests/media/media-video-fullrange-expected.txt: Added.
* LayoutTests/media/media-video-fullrange.html: Added.
* LayoutTests/platform/mac-wk1/TestExpectations:
* LayoutTests/platform/wpe/TestExpectations: WPE incorrectly renders all values as 0
* Source/WebCore/PlatformGTK.cmake: Add video_codes to search path.
* Source/WebCore/PlatformMac.cmake:
* Source/WebCore/PlatformPlayStation.cmake:
* Source/WebCore/PlatformWPE.cmake:
* Source/WebCore/PlatformWin.cmake:
* Source/WebCore/Headers.cmake: Added missing BitReader.h header.
* Source/WebCore/platform/graphics/VP9Utilities.cpp:
(WebCore::parseVPCodecParameters):
(WebCore::createVPCodecConfigurationRecordFromVPCC): Add method to parse VPCC box.
(WebCore::vpcCFromVPCodecConfigurationRecord): Extract code in its own method as it is needed to return information from the bytestream.
(WebCore::setConfigurationColorSpaceFromVP9ColorSpace):
(WebCore::vpcCFromVPXByteStream):
* Source/WebCore/platform/graphics/VP9Utilities.h:
* Source/WebCore/platform/graphics/cocoa/VP9UtilitiesCocoa.mm:
(WebCore::createVideoInfoFromVPCodecConfigurationRecord):
(WebCore::createVideoInfoFromVP9HeaderParser):
* Source/WebCore/platform/graphics/cocoa/WebCoreDecompressionSession.h:
* Source/WebCore/platform/graphics/cocoa/WebCoreDecompressionSession.mm:
(WebCore::WebCoreDecompressionSession::decodeSampleInternal):
(WebCore::WebCoreDecompressionSession::initializeVideoDecoder):
* Source/WebCore/platform/libwebrtc/LibWebRTCVPXVideoDecoder.cpp:
(WebCore::LibWebRTCVPXInternalVideoDecoder::isVPx const):
(WebCore::LibWebRTCVPXInternalVideoDecoder::decode):
(WebCore::LibWebRTCVPXInternalVideoDecoder::LibWebRTCVPXInternalVideoDecoder):
(WebCore::LibWebRTCVPXInternalVideoDecoder::createPixelBuffer):
Canonical link: https://commits.webkit.org/286305@main
Canonical link: https://commits.webkit.org/283286.532@safari-7620-branch
Commit: e975090744cf36d580c619c92a5c712ed0d25daa
https://github.com/WebKit/WebKit/commit/e975090744cf36d580c619c92a5c712ed0d25daa
Author: Youenn Fablet <youenn at apple.com>
Date: 2024-11-29 (Fri, 29 Nov 2024)
Changed paths:
M Source/WebCore/platform/libwebrtc/LibWebRTCVPXVideoDecoder.cpp
M Source/WebCore/platform/libwebrtc/LibWebRTCVPXVideoEncoder.cpp
Log Message:
-----------
Access to vpxDecoderQueueSingleton() is not-threadsafe
rdar://140577403
Reviewed by Jean-Yves Avenard.
Make use of std::call-once to initialize the queue only once.
* Source/WebCore/platform/libwebrtc/LibWebRTCVPXVideoDecoder.cpp:
(WebCore::vpxDecoderQueue):
* Source/WebCore/platform/libwebrtc/LibWebRTCVPXVideoEncoder.cpp:
(WebCore::vpxEncoderQueue):
Canonical link: https://commits.webkit.org/283286.533@safari-7620-branch
Commit: 39b5b5e2415600389c462a6e0bb0e7a5f5bfa434
https://github.com/WebKit/WebKit/commit/39b5b5e2415600389c462a6e0bb0e7a5f5bfa434
Author: Youenn Fablet <youenn at apple.com>
Date: 2024-11-29 (Fri, 29 Nov 2024)
Changed paths:
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp
Log Message:
-----------
`SubscribeToCookieChangeNotifications` and `UnsubscribeFromCookieChangeNotifications` IPC messages do not verify cookie access
rdar://140448767
Reviewed by Chris Dumez.
Add MESSAGE_CHECK to subscribeToCookieChangeNotifications and unsubscribeFromCookieChangeNotifications as they may come from WebProcess.
These are similar checks to NetworkConnectionToWebProcess::domCookiesForHost and are necessary for subscribeToCookieChangeNotifications,
as it would otherwise allow a WebProcess to learn about new cookies.
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:
(WebKit::NetworkConnectionToWebProcess::subscribeToCookieChangeNotifications):
(WebKit::NetworkConnectionToWebProcess::unsubscribeFromCookieChangeNotifications):
Canonical link: https://commits.webkit.org/283286.534@safari-7620-branch
Commit: 6bfd37a9ea77f4a6cf4a944699a3bd0baca286c9
https://github.com/WebKit/WebKit/commit/6bfd37a9ea77f4a6cf4a944699a3bd0baca286c9
Author: Charlie Wolfe <charliew at apple.com>
Date: 2024-11-29 (Fri, 29 Nov 2024)
Changed paths:
M Source/WebCore/page/Page.cpp
M Source/WebCore/page/ResourceUsageOverlay.h
Log Message:
-----------
REGRESSION(283286.393 at safari-7620-branch): Crash in `PageOverlayController::uninstallPageOverlay`
https://bugs.webkit.org/show_bug.cgi?id=283832
rdar://140529810
Reviewed by Chris Dumez.
283286.393 at safari-7620-branch made the ResourceUsageOverlay destructor access the page it was holding
instead of the page held by the page’s mainframe. This was a behavior change because the page destructor
nulls the page held by the mainframe, so we would not try to uninstall the overlay if page destruction
has begun.
This change clears the page held by ResourceUsageOverlay in the page’s destructor to avoid uninstalling
the overlay during page destruction.
* Source/WebCore/page/Page.cpp:
(WebCore::Page::~Page):
* Source/WebCore/page/ResourceUsageOverlay.h:
Canonical link: https://commits.webkit.org/283286.535@safari-7620-branch
Commit: d2f4d88de0f842b2b37d2139e26e10f7e0329bf2
https://github.com/WebKit/WebKit/commit/d2f4d88de0f842b2b37d2139e26e10f7e0329bf2
Author: Matt Woodrow <mattwoodrow at apple.com>
Date: 2024-12-02 (Mon, 02 Dec 2024)
Changed paths:
M LayoutTests/platform/gtk/TestExpectations
M Source/WebCore/dom/ViewTransition.cpp
M Source/WebCore/dom/ViewTransition.h
M Source/WebCore/rendering/RenderBox.cpp
M Source/WebCore/rendering/RenderBox.h
M Source/WebCore/rendering/RenderObject.cpp
M Source/WebCore/rendering/RenderViewTransitionCapture.cpp
Log Message:
-----------
Cherry-pick 77c5d13c77da. rdar://140162820
ViewTransition::updatePseudoElementStyles repeatedly flushes layout.
https://bugs.webkit.org/show_bug.cgi?id=282448
<rdar://139082479>
Reviewed by Tim Nguyen.
This code copies computed style properties which depend on layout, but also
marks renderers as needing layout and does so in a loop.
Split it into two steps, one that reads the style and sets the resulting values
as ::view-transition-group, and another which mutates the
RenderViewTransitionCapture renderer.
It also makes the style update an implicit part of captureNewState, so that we
can avoid a second iteration during activateViewTransition. Previously
updatePseudoElementStyles was blocked on a style flush from updating the dynamic
style sheet, even though it didn't read any related style data.
This results in less invalidation (since we no longer unconditionally call
didChangeStyleSheetContents on the initial update), and exposes a few bugs where
we weren't invalidating the individual changes correctly.
One fix is to make sure setting the image on a RenderViewTransitionCapture
correctly requests a repaint and layer contents change.
Also fixes an existing bug (that got exposed and started causing WPT failures
due to this change) where capturing an element into a view transition didn't
notify ancestors that the background would no longer be painted and obscuration
status needs to be computed.
* Source/WebCore/dom/ViewTransition.cpp:
(WebCore::ViewTransition::updatePropertiesForRenderer):
(WebCore::ViewTransition::captureNewState):
(WebCore::ViewTransition::activateViewTransition):
(WebCore::ViewTransition::handleTransitionFrame):
(WebCore::ViewTransition::updatePseudoElementStyles):
(WebCore::ViewTransition::updatePseudoElementSizes):
* Source/WebCore/dom/ViewTransition.h:
* Source/WebCore/rendering/RenderViewTransitionCapture.cpp:
(WebCore::RenderViewTransitionCapture::setImage):
Canonical link: https://commits.webkit.org/286209@main
Canonical link: https://commits.webkit.org/283286.536@safari-7620-branch
Commit: 694a9b5a1b35bdadf7308f225e2eadca93da1eb3
https://github.com/WebKit/WebKit/commit/694a9b5a1b35bdadf7308f225e2eadca93da1eb3
Author: Qianlang Chen <qianlangchen at apple.com>
Date: 2024-12-02 (Mon, 02 Dec 2024)
Changed paths:
M Source/WebKit/UIProcess/API/C/WKPage.cpp
M Source/WebKit/UIProcess/API/C/WKPagePrivate.h
M Source/WebKit/UIProcess/Inspector/WebInspectorUIProxy.cpp
M Source/WebKit/UIProcess/Inspector/WebInspectorUIProxy.h
M Source/WebKit/UIProcess/Inspector/WebInspectorUIProxy.messages.in
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/WebProcess/InjectedBundle/API/c/WKBundlePage.cpp
M Source/WebKit/WebProcess/InjectedBundle/API/c/WKBundlePage.h
M Source/WebKit/WebProcess/Inspector/WebInspector.cpp
M Source/WebKit/WebProcess/Inspector/WebInspector.h
M Source/WebKit/WebProcess/Inspector/WebInspector.messages.in
M Source/WebKit/WebProcess/Inspector/WebInspectorClient.cpp
M Tools/WebKitTestRunner/InjectedBundle/TestRunner.cpp
M Tools/WebKitTestRunner/TestInvocation.cpp
Log Message:
-----------
A compromised Web Content process should not be able to start Web Inspector
rdar://98891055
https://bugs.webkit.org/show_bug.cgi?id=283092
Reviewed by Ryosuke Niwa and BJ Burg.
There currently exists a message
WebInspectorUIProxy::OpenLocalInspectorFrontend, which the web process
sends to the UI process to show Web Inspector for the current web page.
This introduces security risks as a compromised website may find its way
to send arbitrary messages to the UI process, opening Web Inspector and
weakening the web content sandbox.
The reason this message exists is because there are useful ways the web
process needs to open Web Inspector with initiative. Normally, Web
Inspector is opened via one of the Develop menu's items, which is
controlled by the UI process. However, Web Inspector can also be opened
without being prompted by the UI process first, in these places:
1. In a web page's context menu, the "Inspect Element" option
2. Inside Web Inspector, if the Debug UI is enabled, on the top right
corner, a button to open inspector^2
3. In WebKitTestRunner, via the TestRunner::showWebInspector function
This patch makes it so that web process can no longer send a message to
a UI process to open Web Inspector. This means web process cannot open
Web Inspector at will -- it must be either due to the UI process's
demand, or it's in one of the above three cases. More details below.
I have tested that this change preserves the above three special cases
and does prevent the web page from opening Web Inspector at will.
- Cases #1 and #2 can be tested from the UI.
- Case #3 can be tested with a WebKit test involving Web Inspector.
I ran the test LayoutTests/inspector/console/js-completions.html,
where I saw the test crashing without special treatment for this
case.
- To verify that the web page can't open Web Inspector, I followed
the reproduction steps from the Radar and saw Web Inspector no
longer opens, and opening the external URL also failed as expected.
* Source/WebKit/UIProcess/Inspector/WebInspectorUIProxy.messages.in:
* Source/WebKit/UIProcess/Inspector/WebInspectorUIProxy.h:
* Source/WebKit/UIProcess/Inspector/WebInspectorUIProxy.cpp:
(WebKit::WebInspectorUIProxy::connect):
- If the UI process wants to open Web Inspector, it sends a
WebInspector::Show command to the web process. This patch makes
that command take an async reply, so that the anticipated
WebInspectorUIProxy::OpenLocalInspectorFrontend message from the
web process can now be delivered through that async reply instead.
This ensures that OpenLocalInspectorFrontend can only be done
when initiated from the UI process (due to user interaction).
(WebKit::WebInspectorUIProxy::markAsUnderTest):
(WebKit::WebInspectorUIProxy::openLocalInspectorFrontend):
(WebKit::WebInspectorUIProxy::closeFrontendPageAndWindow):
- To avoid relying on the web process for potentially sensitive
parameters, I reworked and removed the canAttach and underTest
arguments from openLocalInspectorFrontend. These two values
are now stored and managed in the UI process instead, instead of
being passed from the web process all the time.
- For canAttach, I noticed that the
WebInspectorUIProxyMac::platformCanAttach method already
implements the same logic as the web process's
WebInspector::canAttachWindow. I filed https://webkit.org/b/283435
as a follow-up to clean up the webProcessCanAttach parameter,
the canAttachWindow function in the web process, and potentially
the m_attached field too, which all become obsolete due to
this change.
- I couldn't figure out what the `if (m_attached)` in
canAttachWindow check does, and to me it had no effect, as
this function is not called while inspector is open.
- For underTest, I'm now letting the test runner directly set
the flag on the WebInspectorUIProxy, as part of my fix to
address case #3 from above.
(WebKit::WebInspectorUIProxy::showConsole):
(WebKit::WebInspectorUIProxy::showResources):
(WebKit::WebInspectorUIProxy::showMainResourceForFrame):
(WebKit::WebInspectorUIProxy::togglePageProfiling):
- As the web process can longer call OpenLocalInspectorFrontend,
call show/connect/openLocalInspectorFrontend here in the UI process
instead.
(WebKit::WebInspectorUIProxy::requestOpenLocalInspectorFrontend):
- To preserve the open inspector^2 button (case #2 from above), we
still maintain this message, but we ignore it unless it's for
opening inspector^2, thus renaming the message as a request.
This is all assuming that the Web Inspector is not a compromised
web process, so we allow that message from it to come through.
* Source/WebKit/WebProcess/Inspector/WebInspector.messages.in:
* Source/WebKit/WebProcess/Inspector/WebInspector.h:
* Source/WebKit/WebProcess/Inspector/WebInspector.cpp:
(WebKit::WebInspector::show):
- The Show message now takes an async reply, which is used to replace
sending WebInspectorUIProxy::OpenLocalInspectorFrontend later.
(WebKit::WebInspector::showConsole):
(WebKit::WebInspector::showResources):
(WebKit::WebInspector::showMainResourceForFrame):
(WebKit::WebInspector::startPageProfiling):
(WebKit::WebInspector::stopPageProfiling):
- Calling inspectorController()->show() no longer does anything,
since it's now the UI process's job to show Web Inspector first,
for these functions to merely switch to the appropriate tabs.
* Source/WebKit/WebProcess/Inspector/WebInspector.cpp:
(WebKit::WebInspector::openLocalInspectorFrontend):
* Source/WebKit/WebProcess/Inspector/WebInspectorClient.cpp:
(WebKit::WebInspectorClient::openLocalFrontend):
- Adapt to the command's reworked version.
- This is maintained to allow the opening of inspector^2 from the web
process (case #2 from above). For opening inspector^1, this message
will be ignored by the UI process.
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::contextMenuItemSelected):
- When the "Inspect Element" context menu item is selected (case #1
from above), since the web process may not be privileged to open
Web Inspector, handle the showing of inspector here in UI process.
* Tools/WebKitTestRunner/InjectedBundle/TestRunner.cpp:
(WTR::TestRunner::showWebInspector):
* Tools/WebKitTestRunner/TestInvocation.cpp:
(WTR::TestInvocation::didReceiveMessageFromInjectedBundle):
* Source/WebKit/UIProcess/API/C/WKPagePrivate.h:
* Source/WebKit/UIProcess/API/C/WKPage.cpp:
(WKPageShowWebInspectorForTesting):
- Preserve letting the WebKitTestRunner open Web Inspector (case #3
from above).
- Adapt to the change that we now also let the UI process know about
the underTest flag for case #3, rather than letting UI process
rely on the value reported by the web process.
* Source/WebKit/WebProcess/InjectedBundle/API/c/WKBundlePage.h:
* Source/WebKit/WebProcess/InjectedBundle/API/c/WKBundlePage.cpp:
(WKBundlePageShowInspectorForTest): Deleted.
- No longer used due to my special fix for case #3.
Canonical link: https://commits.webkit.org/283286.537@safari-7620-branch
Commit: 7f894e132c95feaa8dfbf22ab47244639d5e250c
https://github.com/WebKit/WebKit/commit/7f894e132c95feaa8dfbf22ab47244639d5e250c
Author: Eric Carlson <eric.carlson at apple.com>
Date: 2024-12-02 (Mon, 02 Dec 2024)
Changed paths:
M Source/WebCore/html/HTMLMediaElement.cpp
M Source/WebCore/html/HTMLMediaElement.h
M Source/WebCore/page/Quirks.cpp
M Source/WebCore/page/Quirks.h
Log Message:
-----------
Cherry-pick 43bf134a6b6a. rdar://140215513
[iPad] Unable to mute the video on hulu.com
https://bugs.webkit.org/show_bug.cgi?id=281697
rdar://126096361
Reviewed by Jer Noble.
Mute implicitly when volume is set to zero on hulu.com on iOS, where we don't have
per-element audio volume control, so their custom controls that use volume to mute and
unmute will work.
* Source/WebCore/html/HTMLMediaElement.cpp:
(WebCore::HTMLMediaElement::HTMLMediaElement): Drive-by change, remove unused member
variable `m_initiallyMuted`.
(WebCore::HTMLMediaElement::setReadyState): Ditto.
(WebCore::HTMLMediaElement::volume const): Return 0 when implicitly muted.
(WebCore::HTMLMediaElement::setVolume): Mute implicitly when volume set to 0, clear
implicit mute when volume set to anything else.
(WebCore::HTMLMediaElement::muted const): Return true when implicitly muted.
(WebCore::HTMLMediaElement::setMuted): Pass flag to setMutedInternal so it runs the update
logic even when `m_muted` doesn't change bug implicit muted does.
(WebCore::HTMLMediaElement::setMutedInternal):
* Source/WebCore/html/HTMLMediaElement.h:
* Source/WebCore/page/Quirks.cpp:
(WebCore::Quirks::implicitMuteWhenVolumeSetToZero const): New Quirk.
* Source/WebCore/page/Quirks.h:
Canonical link: https://commits.webkit.org/285768@main
Canonical link: https://commits.webkit.org/283286.538@safari-7620-branch
Commit: a1abd7e74e4f1433d827bb5747f1c4ff0b09172b
https://github.com/WebKit/WebKit/commit/a1abd7e74e4f1433d827bb5747f1c4ff0b09172b
Author: Youenn Fablet <youenn at apple.com>
Date: 2024-12-02 (Mon, 02 Dec 2024)
Changed paths:
M Source/WebCore/platform/mediastream/mac/AVVideoCaptureSource.h
M Source/WebCore/platform/mediastream/mac/AVVideoCaptureSource.mm
Log Message:
-----------
Cherry-pick e330b5ddc996. rdar://140788879
REGRESSION (iOS 18.2 Beta): Crash when presenting Camera via Web View in - WebCore::AVVideoCaptureSource::create
rdar://140122539
https://bugs.webkit.org/show_bug.cgi?id=283339
Reviewed by Chris Dumez.
Lazy create the timer when we need it (when producing data) to prevent creating it in UIProcess.
* Source/WebCore/platform/mediastream/mac/AVVideoCaptureSource.h:
* Source/WebCore/platform/mediastream/mac/AVVideoCaptureSource.mm:
(WebCore::AVVideoCaptureSource::AVVideoCaptureSource):
(WebCore::AVVideoCaptureSource::startProducingData):
(WebCore::AVVideoCaptureSource::captureSessionIsRunningDidChange):
Canonical link: https://commits.webkit.org/286820@main
Canonical link: https://commits.webkit.org/283286.539@safari-7620-branch
Commit: 9776480310762d48eefb6268b904ae084f0aa6f2
https://github.com/WebKit/WebKit/commit/9776480310762d48eefb6268b904ae084f0aa6f2
Author: Jer Noble <jer.noble at apple.com>
Date: 2024-12-02 (Mon, 02 Dec 2024)
Changed paths:
M Source/WebCore/platform/cocoa/RemoteCommandListenerCocoa.h
M Source/WebCore/platform/cocoa/RemoteCommandListenerCocoa.mm
Log Message:
-----------
Cherry-pick f277ad5b589d. rdar://140469520
[WK1] CRASH in TimerBase::setNextFireTime()
https://bugs.webkit.org/show_bug.cgi?id=283587
rdar://140290399
Reviewed by Eric Carlson.
RemoteCommandListenerCocoa is called into by MediaRemote on the main thread,
rather than the Web thread, which on WK1 will result in a RELEASE_ASSERT when
a timer is restarted. Ensure the RemoteCommandListener callback is moved to
the WebThread on WK1 via ensureMainThread().
* Source/WebCore/platform/cocoa/RemoteCommandListenerCocoa.h:
(WebCore::RemoteCommandListenerCocoa::deref const):
* Source/WebCore/platform/cocoa/RemoteCommandListenerCocoa.mm:
(WebCore::RemoteCommandListenerCocoa::RemoteCommandListenerCocoa):
Canonical link: https://commits.webkit.org/286988@main
Canonical link: https://commits.webkit.org/283286.540@safari-7620-branch
Commit: 61b0d4b242f374c21f2e5fd8eb1dc4dc4cd3da8d
https://github.com/WebKit/WebKit/commit/61b0d4b242f374c21f2e5fd8eb1dc4dc4cd3da8d
Author: Wenson Hsieh <wenson_hsieh at apple.com>
Date: 2024-12-02 (Mon, 02 Dec 2024)
Changed paths:
M Source/WebCore/page/Quirks.cpp
M Source/WebCore/page/Quirks.h
M Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm
Log Message:
-----------
Cherry-pick 2da2a5540fc4. rdar://140213475
[iPadOS] Walmart adds the wrong item color to the cart after switching colors more than once
https://bugs.webkit.org/show_bug.cgi?id=282311
rdar://123734840
Reviewed by Richard Robinson.
On walmart.com, when tapping to change the color or appearance of a shopping item, the page swaps
out a `div` containing the preview `img` for another container underneath the scope of the synthetic
`mousemove` event dispatch. The content change observer (correctly) identifies this as a significant
layout/style change, which causes the tap to be handled as only hover (mouse movement) rather than a
click. However, this results in a confusing user experience where the preview image shows the new
item that was just tapped, but the old item is still selected; subsequently, clicking "Add to cart"
adds the old selected item, instead of the new one shown in the preview.
Since this is effectively indistinguishable from the case where hovering an element shows important
UI and stopping at mouse hover is desirable, work around this with a site-specific hack that targets
this specific UI on Walmart.
* Source/WebCore/page/Quirks.cpp:
(WebCore::Quirks::shouldIgnoreContentObservationForClick const):
Cache a flag that represents whether content observation quirks _may_ be required for the current
top domain, in `m_mayNeedToIgnoreContentObservation`. This guarantees that we'll only perform the
registrable domain lookup once when tapping on any website that does not contain an element affected
by this quirk.
The actual quirk on walmart.com looks for a click target element with `role=button`, immediately
underneath a parent element with `role=listitem`.
* Source/WebCore/page/Quirks.h:
* Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::WebPage::handleSyntheticClick):
Canonical link: https://commits.webkit.org/285881@main
Canonical link: https://commits.webkit.org/283286.541@safari-7620-branch
Commit: 78062d4048b16566271565b6b84f191cbb63859c
https://github.com/WebKit/WebKit/commit/78062d4048b16566271565b6b84f191cbb63859c
Author: Richard Robinson <richard_robinson2 at apple.com>
Date: 2024-12-02 (Mon, 02 Dec 2024)
Changed paths:
M Source/WebKit/UIProcess/Cocoa/FullscreenClient.h
Log Message:
-----------
Cherry-pick 99271c3ed9de. rdar://140804572
[iOS] Entering full screen may not work in web views even when `isElementFullscreenEnabled` is enabled
https://bugs.webkit.org/show_bug.cgi?id=283853
rdar://138336212
Reviewed by Wenson Hsieh.
The bit-field bool values in the `m_delegateMethods` struct in `FullscreenClient.h` are not guaranteed to be
initialized to `false`. As a result, if there is no fullscreen delegate, these values are undefined.
Particularly in the case of `webViewRequestPresentingViewController` being `true`, this causes entering fullscreen
to fail, since the completion handler in `FullscreenClient::requestPresentingViewController` won't actually ever
be invoked.
Fix by default-initializing all the bit-field values in this class to `false`.
* Source/WebKit/UIProcess/Cocoa/FullscreenClient.h:
Canonical link: https://commits.webkit.org/287216@main
Canonical link: https://commits.webkit.org/283286.542@safari-7620-branch
Commit: 99662252b519a07da5ea831e0f4cf6ff7fb01d4a
https://github.com/WebKit/WebKit/commit/99662252b519a07da5ea831e0f4cf6ff7fb01d4a
Author: Matt Woodrow <mattwoodrow at apple.com>
Date: 2024-12-02 (Mon, 02 Dec 2024)
Changed paths:
M Source/WebCore/Sources.txt
M Source/WebCore/WebCore.xcodeproj/project.pbxproj
M Source/WebCore/rendering/RenderObject.h
M Source/WebCore/rendering/RenderView.cpp
M Source/WebCore/rendering/RenderView.h
A Source/WebCore/rendering/RenderViewTransitionRoot.cpp
A Source/WebCore/rendering/RenderViewTransitionRoot.h
M Source/WebCore/rendering/svg/SVGPaintServerHandling.h
M Source/WebCore/rendering/svg/SVGTextBoxPainter.cpp
M Source/WebCore/rendering/updating/RenderTreeUpdaterViewTransition.cpp
M Source/WebCore/style/Styleable.cpp
Log Message:
-----------
Cherry-pick b296bf89104e. rdar://140162837
Styleable::renderer does a linear search over ::view-transition-groups.
https://bugs.webkit.org/show_bug.cgi?id=282410
<rdar://139031118>
Reviewed by Tim Nguyen.
This can be arbitrarily long, we should use a hash-based lookup instead.
Introduces a new RenderBlockFlow subclass, RenderViewTransitionRoot for the
::view-transition psuedo element.
Stores a hashtable of the ::view-transition-group children renderers attached to
the root, and makes Styleable::renderer() use this for faster lookup.
* Source/WebCore/Sources.txt:
* Source/WebCore/WebCore.xcodeproj/project.pbxproj:
* Source/WebCore/rendering/RenderObject.h:
(WebCore::RenderObject::isRenderViewTransitionRoot const):
* Source/WebCore/rendering/RenderView.cpp:
(WebCore::RenderView::viewTransitionRoot const):
(WebCore::RenderView::setViewTransitionRoot):
* Source/WebCore/rendering/RenderView.h:
* Source/WebCore/rendering/RenderViewTransitionRoot.cpp: Added.
(WebCore::RenderViewTransitionRoot::RenderViewTransitionRoot):
(WebCore::RenderViewTransitionRoot::addChildGroup):
(WebCore::RenderViewTransitionRoot::removeChildGroup):
(WebCore::RenderViewTransitionRoot::childGroupForName):
* Source/WebCore/rendering/RenderViewTransitionRoot.h: Added.
* Source/WebCore/rendering/updating/RenderTreeUpdaterViewTransition.cpp:
(WebCore::RenderTreeUpdater::ViewTransition::updatePseudoElementTree):
(WebCore::RenderTreeUpdater::ViewTransition::buildPseudoElementGroup):
* Source/WebCore/style/Styleable.cpp:
(WebCore::Styleable::renderer const):
Canonical link: https://commits.webkit.org/286166@main
Canonical link: https://commits.webkit.org/283286.543@safari-7620-branch
Commit: 53bff510cab1ff42a5a0b71b926cedaa7bb01f39
https://github.com/WebKit/WebKit/commit/53bff510cab1ff42a5a0b71b926cedaa7bb01f39
Author: Youenn Fablet <youenn at apple.com>
Date: 2024-12-02 (Mon, 02 Dec 2024)
Changed paths:
M Source/WebKit/UIProcess/Cocoa/UserMediaCaptureManagerProxy.cpp
Log Message:
-----------
Cherry-pick 874838b28f41. rdar://140788794
UserMediaCaptureManagerProxy is not keeping track of capture sources per page
rdar://140337737
https://bugs.webkit.org/show_bug.cgi?id=283480
Reviewed by Eric Carlson.
When cloning a capture source, we add it to page sources in UserMediaCaptureManagerProxy.
In most cases though, the capture source clone is the clone itself.
When a capture source clone is removed, we would empty the m_pageSources entry for the page.
And we would stop monitoring orientation.
We fix this by checking in UserMediaCaptureManagerProxy::removeSource whether there is still a proxy that is using the source.
If so, we return early. Otherwise we proceed with updating m_pageSources as currently done.
Manually tested.
* Source/WebKit/UIProcess/Cocoa/UserMediaCaptureManagerProxy.cpp:
(WebKit::UserMediaCaptureManagerProxy::removeSource):
Canonical link: https://commits.webkit.org/286909@main
Canonical link: https://commits.webkit.org/283286.544@safari-7620-branch
Commit: 9f1e1b4ba0209b04eedd57ced41fe89cf6df1a33
https://github.com/WebKit/WebKit/commit/9f1e1b4ba0209b04eedd57ced41fe89cf6df1a33
Author: Mohsin Qureshi <mohsinq at apple.com>
Date: 2024-12-02 (Mon, 02 Dec 2024)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7620.2.3
Canonical link: https://commits.webkit.org/283286.545@safari-7620-branch
Commit: c8538e162f80c4c7dd4f5496ca113eb5798e267f
https://github.com/WebKit/WebKit/commit/c8538e162f80c4c7dd4f5496ca113eb5798e267f
Author: Jean-Yves Avenard <jya at apple.com>
Date: 2024-12-02 (Mon, 02 Dec 2024)
Changed paths:
M Source/WebCore/platform/graphics/avfoundation/objc/MediaSampleAVFObjC.h
M Source/WebCore/platform/graphics/avfoundation/objc/MediaSampleAVFObjC.mm
Log Message:
-----------
Cherry-pick 811f1a84f8ca. rdar://140828019
Add MediaSampleAVFObjC::divide utility method
https://bugs.webkit.org/show_bug.cgi?id=281968
rdar://138473636
Reviewed by Youenn Fablet.
Test and code exercising it to be added in another commit.
* Source/WebCore/platform/graphics/avfoundation/objc/MediaSampleAVFObjC.h:
* Source/WebCore/platform/graphics/avfoundation/objc/MediaSampleAVFObjC.mm:
(WebCore::MediaSampleAVFObjC::divide):
Canonical link: https://commits.webkit.org/285598@main
Canonical link: https://commits.webkit.org/283286.546@safari-7620-branch
Commit: 62fe7e1fe50766f358421beb266cd1608d021835
https://github.com/WebKit/WebKit/commit/62fe7e1fe50766f358421beb266cd1608d021835
Author: Matt Woodrow <mattwoodrow at apple.com>
Date: 2024-12-02 (Mon, 02 Dec 2024)
Changed paths:
M Source/WebCore/dom/Element.cpp
M Source/WebCore/dom/Element.h
M Source/WebCore/dom/ElementRareData.cpp
M Source/WebCore/dom/ElementRareData.h
M Source/WebCore/dom/ViewTransition.cpp
M Source/WebCore/style/Styleable.cpp
M Source/WebCore/style/Styleable.h
Log Message:
-----------
Cherry-pick c8e664c1689c. rdar://140162813
viewTransitionNewPseudoForCapturedElement iterates all names elements unnecessarily.
https://bugs.webkit.org/show_bug.cgi?id=282377
<rdar://138980780>
Reviewed by Tim Nguyen.
Both viewTransitionNewPseudoForCapturedElement and
Styleable::capturedInViewTransition do a linear search over the captured
element, since we can't retrieve the 'view-transition-name' property from style
as it might have changed since the transition started.
Fix this by storing the name that we used for capturing on ElementRareData
(possibly indexed by pseudo element identifier, if relevant). This then becomes
the canonical state for 'captured in a view transition', though we still have
the bit set on RenderObject for fast lookups.
If the renderer gets recreated, then RenderElement::initializeStyle uses
Styleable::capturedInViewTransition to re-initialize the bit, which is now fast.
viewTransitionNewPseudoForCapturedElement can directly lookup the name, and then
do a fast lookup using a different styleable for the appropriate pseudo element.
* Source/WebCore/dom/Element.cpp:
(WebCore::Element::viewTransitionCapturedName const):
(WebCore::Element::setViewTransitionCapturedName):
* Source/WebCore/dom/Element.h:
* Source/WebCore/dom/ElementRareData.cpp:
* Source/WebCore/dom/ElementRareData.h:
(WebCore::ElementRareData::viewTransitionCapturedName const):
(WebCore::ElementRareData::setViewTransitionCapturedName):
* Source/WebCore/dom/ViewTransition.cpp:
(WebCore::ViewTransition::activateViewTransition):
(WebCore::ViewTransition::clearViewTransition):
(WebCore::ViewTransition::viewTransitionNewPseudoForCapturedElement):
* Source/WebCore/style/Styleable.cpp:
(WebCore::Styleable::capturedInViewTransition const):
(WebCore::Styleable::setCapturedInViewTransition):
* Source/WebCore/style/Styleable.h:
Canonical link: https://commits.webkit.org/286400@main
Canonical link: https://commits.webkit.org/283286.547@safari-7620-branch
Commit: 84c1168aa3b8e0cdf071caab0bd798a4b23e60cd
https://github.com/WebKit/WebKit/commit/84c1168aa3b8e0cdf071caab0bd798a4b23e60cd
Author: Matt Woodrow <mattwoodrow at apple.com>
Date: 2024-12-03 (Tue, 03 Dec 2024)
Changed paths:
A LayoutTests/compositing/backing/backing-store-attachment-animated-transform-inside-fixed-expected.txt
A LayoutTests/compositing/backing/backing-store-attachment-animated-transform-inside-fixed.html
A LayoutTests/platform/glib/compositing/backing/backing-store-attachment-animated-transform-inside-fixed-expected.txt
A LayoutTests/platform/win/compositing/backing/backing-store-attachment-animated-transform-inside-fixed-expected.txt
M Source/WebCore/rendering/RenderLayerBacking.cpp
M Source/WebCore/rendering/RenderLayerBacking.h
M Source/WebCore/rendering/RenderLayerCompositor.cpp
M Source/WebCore/rendering/RenderLayerCompositor.h
Log Message:
-----------
Cherry-pick 43d5c16a35e7. rdar://140162907
updateAllowsBackingStoreDetaching has wrong coordinates when inside an animated transform.
https://bugs.webkit.org/show_bug.cgi?id=282727
<rdar://139393911>
Reviewed by Simon Fraser.
When descending through a layer that has an animated transform, the layerExtent
is computed using the post-transform animation extents and the transform itself
isn't pushed onto the geometry map.
That means for all descendants, overlap bounds are no longer 'absolute', since
they aren't transformed.
This generally works ok for overlap testing, since everything within the
transform stacking context is in the same coordinate space.
updateAllowsBackingStoreDetaching compares these untransformed coordinates
against the layout viewport though, and this is invalid, leading to backing
stores not being detached.
Actually fixing the layerExtent coordinates to be transformed (with the
transform extents) is complicated unfortunately.
This fixes the symptom by propagating the 'allow backing store detaching'
computation down to descendant layers, if they are in the same containing block
chain (and thus are a subset of the extent computed already).
* LayoutTests/compositing/backing/backing-store-attachment-animated-transform-inside-fixed-expected.txt: Added.
* LayoutTests/compositing/backing/backing-store-attachment-animated-transform-inside-fixed.html: Added.
* Source/WebCore/platform/graphics/ca/GraphicsLayerCA.cpp:
(WebCore::GraphicsLayerCA::updateCoverage):
* Source/WebCore/rendering/RenderLayerBacking.cpp:
(WebCore::RenderLayerBacking::updateAllowsBackingStoreDetaching):
* Source/WebCore/rendering/RenderLayerBacking.h:
* Source/WebCore/rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::CompositingState::stateForPaintOrderChildren const):
(WebCore::RenderLayerCompositor::allowsFixedPositionBackingStoreDetaching):
(WebCore::RenderLayerCompositor::computeCompositingRequirements):
* Source/WebCore/rendering/RenderLayerCompositor.h:
Canonical link: https://commits.webkit.org/286517@main
Canonical link: https://commits.webkit.org/283286.548@safari-7620-branch
Commit: 7a99ebfa9ec0e373eaa251e01f3c4a762650891c
https://github.com/WebKit/WebKit/commit/7a99ebfa9ec0e373eaa251e01f3c4a762650891c
Author: Wenson Hsieh <wenson_hsieh at apple.com>
Date: 2024-12-03 (Tue, 03 Dec 2024)
Changed paths:
M Source/WebCore/page/ChromeClient.h
M Source/WebCore/page/EventHandler.cpp
M Source/WebCore/page/EventHandler.h
M Source/WebCore/page/Quirks.cpp
M Source/WebCore/page/Quirks.h
M Source/WebKit/WebProcess/WebCoreSupport/WebChromeClient.cpp
M Source/WebKit/WebProcess/WebCoreSupport/WebChromeClient.h
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm
Log Message:
-----------
[iPad] cbssports.com: Media controls on videos do not respond to trackpad clicks
https://bugs.webkit.org/show_bug.cgi?id=282794
rdar://140213450
Reviewed by Abrar Rahman Protyasha.
When watching videos on cbssports.com, it's not currently possible to interact with the media
player's custom controls using a trackpad on iPad. This is because the website itself explicitly
prevents click events from triggering any actions on the media player, in the case where touch
capabilities are supported (i.e. `this.isTouch` is set):
```
onClick(e)
{
this.isTouch || this.disabled ? Dt(e) : this.execAction()
}
onTouchStart(e)
{
Dt(e),
this.touchStartStamp = e.timeStamp
}
onTouchEnd(e)
{
!this.disabled && this.touchStartStamp && e.timeStamp - this.touchStartStamp <= this.TAP_THRESHOLD && (this.touchStartStamp = null, this.execAction())
}
```
To make this Just Work, this patch add a site-specific hack that triggers only when clicking on
specific media controls on cbssports.com (precisely, elements with tag name `AVIA-BUTTON`). If the
click is swallowed (i.e. prevented default), we call out into the client layer to simulate a pair of
`touchstart` / `touchend` events, which results in the control being "clicked".
* Source/WebCore/page/ChromeClient.h:
(WebCore::ChromeClient::didSwallowClickEvent):
* Source/WebCore/page/EventHandler.cpp:
(WebCore::EventHandler::swallowAnyClickEvent):
* Source/WebCore/page/EventHandler.h:
* Source/WebCore/page/Quirks.cpp:
(WebCore::Quirks::shouldSynthesizeTouchEventsAfterNonSyntheticClick const):
* Source/WebCore/page/Quirks.h:
* Source/WebKit/WebProcess/WebCoreSupport/WebChromeClient.cpp:
(WebKit::WebChromeClient::didSwallowClickEvent):
* Source/WebKit/WebProcess/WebCoreSupport/WebChromeClient.h:
* Source/WebKit/WebProcess/WebPage/WebPage.h:
(WebKit::WebPage::didSwallowClickEvent):
* Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::WebPage::didSwallowClickEvent):
Add logic to synthesize touchstart/touchend events over the center of the clicked element. See above
for more details.
Canonical link: https://commits.webkit.org/283286.549@safari-7620-branch
Commit: e5f3927d32d177c6ade859b716b38a706c0a8309
https://github.com/WebKit/WebKit/commit/e5f3927d32d177c6ade859b716b38a706c0a8309
Author: Jean-Yves Avenard <jya at apple.com>
Date: 2024-12-03 (Tue, 03 Dec 2024)
Changed paths:
M LayoutTests/TestExpectations
M LayoutTests/media/media-source/media-source-vp8-hiddenframes.html
M LayoutTests/media/media-vp8-hiddenframes.html
M LayoutTests/platform/glib/TestExpectations
M LayoutTests/platform/mac-wk1/TestExpectations
M LayoutTests/platform/mac-wk2/TestExpectations
M Source/WebCore/platform/VideoDecoder.h
M Source/WebCore/platform/graphics/cocoa/WebCoreDecompressionSession.mm
M Source/WebCore/platform/libwebrtc/LibWebRTCVPXVideoDecoder.cpp
Log Message:
-----------
Cherry-pick 2cdde9cb8a0d. rdar://140817250
REGRESSION (282704 at main): [ macOS wk2 ] media/media-vp8-hiddenframes.html is a flaky image only failure.
https://bugs.webkit.org/show_bug.cgi?id=278833
rdar://134903291
Reviewed by Youenn Fablet.
This commit handles two issues.
1- The test incorrectly failed as we weren't always ending the test once the last frame was displayed as expected. For now we will simply wait for 1s
2- On Apple platforms other than mac, decoding of videos with alternate's frame was broken. The WebM demuxer pack all CMSampleBuffer with the same timecode
together so that they can be added to the MSE's TrackBuffer without issues (as we use the time as key). While the VideoToolbox decoder handled
thos CMSampleBuffer properly, the WebCoreDecompressionSession's VideoDecoder didn't. We now iterate over all the inner samples and return the last
deocded frames returned.
* LayoutTests/TestExpectations:
* LayoutTests/media/media-source/media-source-vp8-hiddenframes.html:
* LayoutTests/media/media-vp8-hiddenframes.html:
* LayoutTests/platform/mac-wk2/TestExpectations: Remove failure expectations.
* Source/WebCore/platform/VideoDecoder.h: Add enum to treat no frame as error. This is done to leave the current behaviour of WebCodec which does expect an error. To be further investigated in webkit.org/b/282227
Fly-By, re-order the enum to follow coding style (No first)
* Source/WebCore/platform/graphics/cocoa/WebCoreDecompressionSession.mm:
(WebCore::WebCoreDecompressionSession::decodeSampleInternal):
(WebCore::WebCoreDecompressionSession::initializeVideoDecoder):
* Source/WebCore/platform/libwebrtc/LibWebRTCVPXVideoDecoder.cpp:
(WebCore::LibWebRTCVPXInternalVideoDecoder::decode):
(WebCore::LibWebRTCVPXInternalVideoDecoder::LibWebRTCVPXInternalVideoDecoder):
Canonical link: https://commits.webkit.org/286329@main
Canonical link: https://commits.webkit.org/283286.550@safari-7620-branch
Commit: 09169e87e443979b5cd10c0cea239c0f41ed78b0
https://github.com/WebKit/WebKit/commit/09169e87e443979b5cd10c0cea239c0f41ed78b0
Author: Simon Lewis <simon.lewis at apple.com>
Date: 2024-12-03 (Tue, 03 Dec 2024)
Changed paths:
M Source/WebKit/Shared/Cocoa/CoreIPCPlistArray.mm
M Tools/TestWebKitAPI/Tests/IPC/IPCSerialization.mm
Log Message:
-----------
CoreIPCPlistArray::toID() incorrect lifetime management with createNSArray
rdar://140507449
https://bugs.webkit.org/show_bug.cgi?id=283915
Reviewed by Sihui Liu.
* Source/WebKit/Shared/Cocoa/CoreIPCPlistArray.mm:
(WebKit::CoreIPCPlistArray::toID const):
* Tools/TestWebKitAPI/Tests/IPC/IPCSerialization.mm:
(TEST(IPCSerialization, Plist)):
Canonical link: https://commits.webkit.org/283286.551@safari-7620-branch
Commit: ce901e53947fd5f9874efc22f000c1a40355e793
https://github.com/WebKit/WebKit/commit/ce901e53947fd5f9874efc22f000c1a40355e793
Author: Matt Woodrow <mattwoodrow at apple.com>
Date: 2024-12-03 (Tue, 03 Dec 2024)
Changed paths:
M Source/WebCore/dom/ViewTransition.cpp
M Source/WebCore/dom/ViewTransition.h
M Source/WebCore/rendering/RenderLayerBacking.cpp
Log Message:
-----------
Cherry-pick 0c3e3e18a165. rdar://140162836
View transition old snapshots don't get flushed until we try to use them
https://bugs.webkit.org/show_bug.cgi?id=282676
<rdar://139339149>
Reviewed by Simon Fraser.
View transition old snapshots get recorded during the 'activate' phase which
happens outside of a rendering update.
We have a tradeoff between flushing them immediately so that the work completes
before the rendering update, and flushing more than is needed and having some of
it block the rendering update's work.
This adds a check if the element being captured in the 'old' state intersects
the viewport, and flushes the snapshot if so (after all the snapshot buffers
have been allocated, to prevent rendering work from blocking backend handles
being returned). This isn't strictly what will be used in the first frame of the
animation, since authors can style and locate the pseudos arbitrarily, but it
should be close enough usually.
GraphicsLayerCARemote::setLayerContentsToImageBuffer already flushes buffers as
they get set, so if we ever use a snapshot that wasn't included in the initial
flush then it gets flushed at that point.
It also changes the 'isDirectlyCompositedImage' path to return false for
elements that are known to be offscreen (inside a position:fixed and we computed
that the backing store can be detached). Without this, we just forward the
ImageBuffer to the relevant GraphicsLayer for every single psuedo, which
triggers the 'flush on use' path for everything.
* Source/WebCore/dom/ViewTransition.cpp:
(WebCore::ViewTransition::captureOldState):
(WebCore::ViewTransition::updatePropertiesForRenderer):
(WebCore::ViewTransition::copyElementBaseProperties):
* Source/WebCore/dom/ViewTransition.h:
* Source/WebCore/rendering/RenderLayerBacking.cpp:
(WebCore::RenderLayerBacking::updateAllowsBackingStoreDetaching):
(WebCore::RenderLayerBacking::isDirectlyCompositedImage const):
* Source/WebCore/rendering/RenderViewTransitionCapture.cpp:
(WebCore::RenderViewTransitionCapture::image):
* Source/WebCore/rendering/RenderViewTransitionCapture.h:
Canonical link: https://commits.webkit.org/286553@main
Canonical link: https://commits.webkit.org/283286.552@safari-7620-branch
Commit: 42ecf27ffbca0b63289f3ff761d46771c0deaf1f
https://github.com/WebKit/WebKit/commit/42ecf27ffbca0b63289f3ff761d46771c0deaf1f
Author: Per Arne Vollan <pvollan at apple.com>
Date: 2024-12-03 (Tue, 03 Dec 2024)
Changed paths:
M Source/WebKit/Shared/AuxiliaryProcessExtensions/NetworkingExtension-Info.plist
Log Message:
-----------
Cherry-pick 5e0585ea7336. rdar://140867080
[iOS] The Networking process should use the same localization as the UI process
https://bugs.webkit.org/show_bug.cgi?id=283029
rdar://139264528
Reviewed by Chris Dumez.
Use the same property list key/value for this as we do for the WebContent process.
* Source/WebKit/Shared/AuxiliaryProcessExtensions/NetworkingExtension-Info.plist:
Canonical link: https://commits.webkit.org/286539@main
Canonical link: https://commits.webkit.org/283286.553@safari-7620-branch
Commit: f3ac77c1c0629ed1a0cb475d62a0cff892807cf7
https://github.com/WebKit/WebKit/commit/f3ac77c1c0629ed1a0cb475d62a0cff892807cf7
Author: Mike Wyrzykowski <mwyrzykowski at apple.com>
Date: 2024-12-03 (Tue, 03 Dec 2024)
Changed paths:
M Source/WebGPU/WebGPU/HardwareCapabilities.mm
Log Message:
-----------
Cherry-pick 57b35e7ee82a. rdar://140813502
[WebGPU] Support counter set only on certain devices
https://bugs.webkit.org/show_bug.cgi?id=283441
rdar://139265606
Reviewed by Dan Glastonbury.
Intel Iris returns NSString* instead of NSArray<id<MTLCounterSet>>*
as required by the Metal API.
Workaround Intel driver bug by disabling this optional feature on Intel.
* Source/WebGPU/WebGPU/HardwareCapabilities.mm:
(WebGPU::isIntel):
(WebGPU::baseCapabilities):
Canonical link: https://commits.webkit.org/286890@main
Canonical link: https://commits.webkit.org/283286.554@safari-7620-branch
Commit: 90dea7fd2722fed5d9fabea5cbc2c2e7ea23854b
https://github.com/WebKit/WebKit/commit/90dea7fd2722fed5d9fabea5cbc2c2e7ea23854b
Author: Tim Nguyen <ntim at apple.com>
Date: 2024-12-03 (Tue, 03 Dec 2024)
Changed paths:
M LayoutTests/inspector/css/getMatchedStylesForNodeBackdropPseudoId.html
A LayoutTests/inspector/css/getMatchedStylesForNodeViewTransitionPseudoElements-expected.txt
A LayoutTests/inspector/css/getMatchedStylesForNodeViewTransitionPseudoElements.html
M Source/WebCore/inspector/agents/InspectorCSSAgent.cpp
Log Message:
-----------
Cherry-pick c303cfb174dd. rdar://140832638
Web Inspector crashes due to using erroneous `PseudoElementIdentifier`
https://bugs.webkit.org/show_bug.cgi?id=283574
rdar://140243623
Reviewed by Devin Rousso.
Skip named view transition pseudo-elements until we're able to pass a proper `PseudoElementIdentifier` into
`pseudoStyleRulesForElement`, and once we properly support named view transition pseudo-elements.
* LayoutTests/inspector/css/getMatchedStylesForNodeBackdropPseudoId.html:
* LayoutTests/inspector/css/getMatchedStylesForNodeViewTransitionPseudoElements-expected.txt: Added.
* LayoutTests/inspector/css/getMatchedStylesForNodeViewTransitionPseudoElements.html: Added.
* Source/WebCore/inspector/agents/InspectorCSSAgent.cpp:
(WebCore::InspectorCSSAgent::getMatchedStylesForNode):
Canonical link: https://commits.webkit.org/287254@main
Canonical link: https://commits.webkit.org/283286.555@safari-7620-branch
Commit: 27806e69db6ed1afa5316e253d3046723eb3bc7a
https://github.com/WebKit/WebKit/commit/27806e69db6ed1afa5316e253d3046723eb3bc7a
Author: Jean-Yves Avenard <jya at apple.com>
Date: 2024-12-03 (Tue, 03 Dec 2024)
Changed paths:
A LayoutTests/media/content/test-h264-601-videorange.mp4
A LayoutTests/media/content/test-vp8-601-videorange.webm
A LayoutTests/media/content/test-vp9-601-videorange.webm
M LayoutTests/media/media-source/media-source-vp8-hiddenframes.html
M LayoutTests/media/media-video-fullrange.html
A LayoutTests/media/media-video-videorange-expected.txt
A LayoutTests/media/media-video-videorange.html
M LayoutTests/media/media-vp8-hiddenframes.html
M LayoutTests/platform/glib/TestExpectations
M LayoutTests/platform/ios/TestExpectations
M LayoutTests/platform/mac-wk1/TestExpectations
M LayoutTests/platform/mac-wk2/TestExpectations
M Source/WebCore/Modules/webcodecs/WebCodecsVideoDecoder.cpp
M Source/WebCore/platform/VideoDecoder.h
M Source/WebCore/platform/graphics/VP9Utilities.cpp
M Source/WebCore/platform/graphics/VP9Utilities.h
M Source/WebCore/platform/graphics/cocoa/CMUtilities.h
M Source/WebCore/platform/graphics/cocoa/CMUtilities.mm
M Source/WebCore/platform/graphics/cocoa/VP9UtilitiesCocoa.mm
M Source/WebCore/platform/graphics/cocoa/WebCoreDecompressionSession.h
M Source/WebCore/platform/graphics/cocoa/WebCoreDecompressionSession.mm
M Source/WebCore/platform/libwebrtc/LibWebRTCVPXVideoDecoder.cpp
Log Message:
-----------
Cherry-pick 71710708fe. rdar://140281899
WebCodec's VideoDecoders don't handle colorspace properly
https://bugs.webkit.org/show_bug.cgi?id=282741
rdar://139412312
Reviewed by Youenn Fablet.
Pass colorspace information to the created CVPixelBuffer.
We add utility methods to construct the colorspace data from the vpcC box and VPx bytestream
should the information not be provided on construction.
We prefer colorspace information from this source order given colorspace > description data (vpcC) > inband bytestream.
Added tests verifying that black are pure black, and yellow are almost pure yellow with 601 videos and video range.
Technically they should be exactly pure (255, 255, 0), however, compression artifacts with the source makes it not so.
Fly-by #1: m_isClosed can be accessed concurrently on the decoder's or caller's workqueue. Make it atomic.
Fly-by #2: Make relevant members const and add annotation about where some members can be accessed from.
* LayoutTests/media/content/test-h264-601-videorange.mp4: Added.
* LayoutTests/media/content/test-vp8-601-videorange.webm: Added.
* LayoutTests/media/content/test-vp9-601-videorange.webm: Added.
* LayoutTests/media/media-source/media-source-vp8-hiddenframes.html: We can reduce the fuzz range now that both the VT decoder (mac) will return the same colours as VideoDecoder (ios family)
* LayoutTests/media/media-video-fullrange.html: Wait a maximum of 500ms for the promise to be resolved as the rVFC callback may not always be called.
* LayoutTests/media/media-video-videorange-expected.txt: Added.
* LayoutTests/media/media-video-videorange.html: Added.
* LayoutTests/media/media-vp8-hiddenframes.html: We can reduce the fuzz range now that both the VT decoder (mac) will return the same colours as VideoDecoder (ios family)
* LayoutTests/platform/mac-wk1/TestExpectations:
* LayoutTests/platform/wpe/TestExpectations:
* Source/WebCore/Modules/webcodecs/WebCodecsVideoDecoder.cpp:
(WebCore::createVideoDecoderConfig):
* Source/WebCore/platform/VideoDecoder.h:
* Source/WebCore/platform/graphics/VP9Utilities.cpp:
(WebCore::vPCodecConfigurationRecordFromVPXByteStream):
(WebCore::convertToPlatformVideoColorPrimaries):
(WebCore::convertToPlatformVideoTransferCharacteristics):
(WebCore::convertToPlatformVideoMatrixCoefficients):
(WebCore::colorSpaceFromVPCodecConfigurationRecord):
(WebCore::vpcCFromVPXByteStream): Deleted.
* Source/WebCore/platform/graphics/VP9Utilities.h:
* Source/WebCore/platform/graphics/cocoa/CMUtilities.h:
* Source/WebCore/platform/graphics/cocoa/CMUtilities.mm:
(WebCore::convertToCMTransferFunction): Add transfer value for BT601 (smpte170m) which is the same as 709.2 transfer.
(WebCore::attachColorSpaceToPixelBuffer):
* Source/WebCore/platform/graphics/cocoa/VP9UtilitiesCocoa.mm: Move methods to VP9Utilities.cpp
(WebCore::convertToMatrixCoefficients):
(WebCore::createVideoInfoFromVPCodecConfigurationRecord):
(WebCore::convertToPlatformVideoColorPrimaries): Deleted.
(WebCore::convertToPlatformVideoTransferCharacteristics): Deleted.
(WebCore::convertToPlatformVideoMatrixCoefficients): Deleted.
* Source/WebCore/platform/graphics/cocoa/WebCoreDecompressionSession.h:
* Source/WebCore/platform/graphics/cocoa/WebCoreDecompressionSession.mm:
(WebCore::WebCoreDecompressionSession::decodeSampleInternal): Retrieve colorspace from CMSampleBuffer and give it to the decoder initialization.
(WebCore::WebCoreDecompressionSession::enqueueDecodedSample): Fly-by: the last video frame in a webm doesn't have a duration. A logic
error would have caused to never notify the listener that the frame at currentTime had been decoded, leading to the play() promise to never be resolved (nor rVFC callback to be called)
(WebCore::WebCoreDecompressionSession::initializeVideoDecoder):
* Source/WebCore/platform/libwebrtc/LibWebRTCVPXVideoDecoder.cpp:
(WebCore::LibWebRTCVPXInternalVideoDecoder::decode):
(WebCore::LibWebRTCVPXInternalVideoDecoder::LibWebRTCVPXInternalVideoDecoder):
(WebCore::LibWebRTCVPXInternalVideoDecoder::createPixelBuffer):
(WebCore::LibWebRTCVPXInternalVideoDecoder::Decoded):
Canonical link: https://commits.webkit.org/286474@main
Canonical link: https://commits.webkit.org/283286.556@safari-7620-branch
Commit: d047ba4a144b576f5bfd978de1ff29dad70129b0
https://github.com/WebKit/WebKit/commit/d047ba4a144b576f5bfd978de1ff29dad70129b0
Author: Lily Spiniolas <lily_spiniolas at apple.com>
Date: 2024-12-03 (Tue, 03 Dec 2024)
Changed paths:
M Source/WebCore/page/Quirks.cpp
M Source/WebCore/page/Quirks.h
Log Message:
-----------
Cherry-pick 6bc0ba3efa72. rdar://140381864
[macOS] Quirk needed to detect Bing Maps in order to eventually fix pinch to zoom
https://bugs.webkit.org/show_bug.cgi?id=282860
rdar://139544427
Reviewed by Wenson Hsieh.
Added quirk which can detect if the element passed to it
is the canvas on Bing Maps which currently zooms incorrectly
on macOS.
* Source/WebCore/page/Quirks.cpp:
(WebCore::Quirks::needsBingGestureEventQuirk const):
* Source/WebCore/page/Quirks.h:
Canonical link: https://commits.webkit.org/286381@main
Canonical link: https://commits.webkit.org/283286.557@safari-7620-branch
Commit: 85b173a6e8ab84d19610357d2625b4a2af1f6e29
https://github.com/WebKit/WebKit/commit/85b173a6e8ab84d19610357d2625b4a2af1f6e29
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2024-12-03 (Tue, 03 Dec 2024)
Changed paths:
M LayoutTests/imported/w3c/web-platform-tests/css/css-view-transitions/new-content-flat-transform-ancestor.html
M LayoutTests/platform/mac-wk2/TestExpectations
M Source/WebCore/rendering/RenderObject.cpp
M Source/WebCore/rendering/RenderObject.h
M Source/WebCore/style/Styleable.cpp
Log Message:
-----------
Cherry-pick a2e838aaa252. rdar://140514205
Missing style invalidation in View Transitions
https://bugs.webkit.org/show_bug.cgi?id=283391
rdar://140244893
Reviewed by Matt Woodrow.
Fixing bug 267252 removes some spurious cases where RenderStyles report as different
when they are actually the same. This reveals missing style invalidation bugs in other
parts of the code.
Here in View Transitions we see that the `capturedInViewTransition` state on a RenderObject
affects whether it makes a RenderLayer (via `requiresRenderingConsolidationForViewTransition()`)
and whether `forceToFlat` is set in StyleAdjuster. So when `capturedInViewTransition` changes,
we need to force a style update on the element.
This fixes css/css-view-transitions/element-stops-grouping-after-animation.html when the patch
for 267252 is applied.
* LayoutTests/imported/w3c/web-platform-tests/css/css-view-transitions/new-content-flat-transform-ancestor.html: slight tolerance increase for intel.
* LayoutTests/platform/mac-wk2/TestExpectations:
* Source/WebCore/rendering/RenderObject.cpp:
(WebCore::RenderObject::setCapturedInViewTransition):
* Source/WebCore/rendering/RenderObject.h:
* Source/WebCore/style/Styleable.cpp:
(WebCore::Styleable::setCapturedInViewTransition):
Canonical link: https://commits.webkit.org/286871@main
Canonical link: https://commits.webkit.org/283286.558@safari-7620-branch
Commit: 148e510600a8686431ea1f128b1b7bbebc30723a
https://github.com/WebKit/WebKit/commit/148e510600a8686431ea1f128b1b7bbebc30723a
Author: Tyler Wilcock <tyler_w at apple.com>
Date: 2024-12-03 (Tue, 03 Dec 2024)
Changed paths:
M LayoutTests/accessibility-isolated-tree/TestExpectations
A LayoutTests/accessibility/password-selected-text-range-expected.txt
A LayoutTests/accessibility/password-selected-text-range.html
A LayoutTests/platform/glib/accessibility/password-selected-text-range-expected.txt
M LayoutTests/platform/ios/TestExpectations
A LayoutTests/platform/ios/accessibility/password-selected-text-range-expected.txt
M Source/WebCore/accessibility/AXCoreObject.h
M Source/WebCore/accessibility/AccessibilityRenderObject.cpp
M Source/WebCore/accessibility/ios/WebAccessibilityObjectWrapperIOS.mm
M Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapperMac.mm
Log Message:
-----------
Cherry-pick c3d6184dbe8d. rdar://140839316
AX: Getting the selected text range for secure fields always returns an invalid range, breaking text editing for some assistive technologies
https://bugs.webkit.org/show_bug.cgi?id=283933
rdar://136730209
Reviewed by Chris Fleizach.
The intention of returning an invalid range for secure fields was to prevent malicious assistive technologies from
discovering the length of a user's password. But there are already several other mechanisms they can get this information,
so this restriction makes the life of well-behaving ATs more difficult for no gain. With this commit, we allow retrieiving
the selected text range for a secure field.
* LayoutTests/accessibility-isolated-tree/TestExpectations:
The new test fails because we don't update AXPropertyName::SelectedTextRange. This will be addressed in a follow-up patch.
* LayoutTests/accessibility/password-selected-text-range-expected.txt: Added.
* LayoutTests/accessibility/password-selected-text-range.html: Added.
* LayoutTests/platform/ios/TestExpectations: Enable new test.
* LayoutTests/platform/ios/accessibility/password-selected-text-range-expected.txt: Added.
* Source/WebCore/accessibility/AXCoreObject.h:
(WebCore::AXCoreObject::shouldReturnEmptySelectedText const): Deleted.
* Source/WebCore/accessibility/AccessibilityRenderObject.cpp:
(WebCore::AccessibilityRenderObject::selectedTextRange const):
* Source/WebCore/accessibility/ios/WebAccessibilityObjectWrapperIOS.mm:
(-[WebAccessibilityObjectWrapper browserAccessibilityDeleteTextAtCursor:]):
* Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapperMac.mm:
(-[WebAccessibilityObjectWrapper ALLOW_DEPRECATED_IMPLEMENTATIONS_END]):
Canonical link: https://commits.webkit.org/287258@main
Canonical link: https://commits.webkit.org/283286.559@safari-7620-branch
Commit: 5ea101f9262fad7680f6c6cf545adea8aec162f3
https://github.com/WebKit/WebKit/commit/5ea101f9262fad7680f6c6cf545adea8aec162f3
Author: Wenson Hsieh <wenson_hsieh at apple.com>
Date: 2024-12-04 (Wed, 04 Dec 2024)
Changed paths:
M Source/WebCore/page/Quirks.cpp
Log Message:
-----------
Cherry-pick 0829e2fa6ac3. rdar://140281840
weather.com: [macOS] Unable to dismiss drop-down after clicking on document body
https://bugs.webkit.org/show_bug.cgi?id=282965
rdar://138053733
Reviewed by Abrar Rahman Protyasha and Richard Robinson.
Augment an existing quirk to allow mouse clicks to `focus()` form controls (in this case, a `button`
element). weather.com depends on the button that shows the dropdown menu gaining focus when clicked,
since it dismisses the dropdown when the button loses focus (which, in turn, happens when the user
clicks on the body).
This is a long-standing behavior in WebKit, which (roughly) matches platform convention on macOS;
see https://webkit.org/b/22261 for more context.
* Source/WebCore/page/Quirks.cpp:
(WebCore::Quirks::needsFormControlToBeMouseFocusable const):
Canonical link: https://commits.webkit.org/286468@main
Canonical link: https://commits.webkit.org/283286.560@safari-7620-branch
Commit: 781e602562042814686e898d444c7620cc0a40b9
https://github.com/WebKit/WebKit/commit/781e602562042814686e898d444c7620cc0a40b9
Author: Jer Noble <jer.noble at apple.com>
Date: 2024-12-04 (Wed, 04 Dec 2024)
Changed paths:
A LayoutTests/media/content/test-par-16-9.webm
M LayoutTests/media/media-vp9-dar-webm-expected.txt
M LayoutTests/media/media-vp9-dar-webm.html
A LayoutTests/media/media-vp9-sar-webm-expected.txt
A LayoutTests/media/media-vp9-sar-webm.html
M LayoutTests/platform/mac-wk1/TestExpectations
M Source/WebCore/platform/graphics/cocoa/CMUtilities.mm
Log Message:
-----------
Cherry-pick 29decfd. rdar://140352350
Wikipedia WebM sample has wrong aspect ratio
https://bugs.webkit.org/show_bug.cgi?id=282555
rdar://139229383
Reviewed by Jean-Yves Avenard.
285809 at main fixed aspect ratio of webm files whose source pixels were 1:1,
but the resulting pixel-aspect-ratio setting was incorrect for files with
non-1:1 sources and a sample-aspect-ratio setting.
* LayoutTests/media/content/test-par-16-9.webm: Added.
* LayoutTests/media/media-vp9-dar-webm-expected.txt:
* LayoutTests/media/media-vp9-dar-webm.html:
* LayoutTests/media/media-vp9-sar-webm-expected.txt: Added.
* LayoutTests/media/media-vp9-sar-webm.html: Added.
* Source/WebCore/platform/graphics/cocoa/CMUtilities.mm:
(WebCore::createFormatDescriptionFromTrackInfo):
Canonical link: https://commits.webkit.org/286898@main
Resolve conflicts in CMUtilities.mm
Resolve build errors in CMUtilities.mm
Canonical link: https://commits.webkit.org/283286.561@safari-7620-branch
Commit: 1ea709ad43d7b59b592e6b449db5a1eeaf36c430
https://github.com/WebKit/WebKit/commit/1ea709ad43d7b59b592e6b449db5a1eeaf36c430
Author: Richard Robinson <richard_robinson2 at apple.com>
Date: 2024-12-04 (Wed, 04 Dec 2024)
Changed paths:
M Source/WebCore/platform/graphics/Font.cpp
M Source/WebCore/platform/graphics/SystemFallbackFontCache.cpp
M Source/WebCore/platform/graphics/SystemFallbackFontCache.h
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WritingTools.mm
Log Message:
-----------
Cherry-pick 48d994887c94. rdar://140894649
[Writing Tools] Outlook.app quits unexpectedly with Writing Tools
https://bugs.webkit.org/show_bug.cgi?id=283098
rdar://139513909
Reviewed by Wenson Hsieh and Abrar Rahman Protyasha.
The `SystemFallbackFontCache` system depends on using a `WebCore::Timer`. In the destructor of `Font`,
a font cache is accessed and the font is removed from the cache. Notably, even if there is no cache,
one is erroneously created anyways.
The `AttributedString` type uses the `Font` type and therefore indirectly uses a `WebCore::Timer`.
Therefore, any use of `AttributedString` in the UI process is unsafe, as it is not allowed to use a
`WebCore::Timer` in the UI process.
This issue manifests in the implementation of Writing Tools, which uses AttributedStrings in the UI
process. This issue was always present, however it turned into a crash once a release assert was a
dded in `WebCore::Timer`.
To fix this, ensure that a new font cache is not created in the destructor of Font.
* Source/WebCore/platform/graphics/Font.cpp:
(WebCore::Font::~Font):
* Source/WebCore/platform/graphics/SystemFallbackFontCache.cpp:
(WebCore::SystemFallbackFontCache::forCurrentThreadIfExists):
* Source/WebCore/platform/graphics/SystemFallbackFontCache.h:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WritingTools.mm:
(TEST(WritingTools, AttributedStringWithWebKitLegacy)):
Canonical link: https://commits.webkit.org/286579@main
Canonical link: https://commits.webkit.org/283286.562@safari-7620-branch
Commit: 24c810821167babed64b15629d229b7e24c24c1f
https://github.com/WebKit/WebKit/commit/24c810821167babed64b15629d229b7e24c24c1f
Author: David Kilzer <ddkilzer at apple.com>
Date: 2024-12-04 (Wed, 04 Dec 2024)
Changed paths:
M Source/WebKit/Shared/IPCStreamTester.cpp
Log Message:
-----------
Cherry-pick 283762 at main (1dbf4cd6a307). <rdar://140927293>
[IPC] Fix -Wmissing-designated-field-initializers warning in IPCStreamTester.cpp
<https://bugs.webkit.org/show_bug.cgi?id=279718>
<rdar://136014113>
Reviewed by Kimmo Kinnunen.
* Source/WebKit/Shared/IPCStreamTester.cpp:
(WebKit::IPCStreamTester::checkAutoreleasePool):
- Initialize all fields in CFArrayCallBacks.
Canonical link: https://commits.webkit.org/283762@main
Canonical link: https://commits.webkit.org/283286.563@safari-7620-branch
Commit: 62f26335eb4fa70b1cc8e172722489564c38c5ff
https://github.com/WebKit/WebKit/commit/62f26335eb4fa70b1cc8e172722489564c38c5ff
Author: Aditya Keerthi <akeerthi at apple.com>
Date: 2024-12-04 (Wed, 04 Dec 2024)
Changed paths:
M Source/WebCore/page/Quirks.cpp
Log Message:
-----------
Cherry-pick f5ae761ea033. rdar://140010010
[iOS] thesaurus.com: Unable to select text
https://bugs.webkit.org/show_bug.cgi?id=282946
rdar://138789765
Reviewed by Abrar Rahman Protyasha.
thesaurus.com runs script from player.anyclip.com, which adds a `touchstart`
listener to the document element, when the user agent does not contain Chrome
and Android. Inside this `touchstart` listener, the script calls
`window.getSelection().removeAllRanges()` after a 1 second delay. This results
in the selection getting cleared after the user attempts to select text.
Fix by adding a quirk to add Chrome and Android to the reported user agent in
this scenario. The quirk is scoped to thesaurus.com and the script from
player.anyclip.com to reduce risk, as the original intention of the `touchstart`
listener is unclear.
* Source/WebCore/page/Quirks.cpp:
(WebCore::Quirks::scriptToEvaluateBeforeRunningScriptFromURL):
Canonical link: https://commits.webkit.org/286499@main
Canonical link: https://commits.webkit.org/283286.564@safari-7620-branch
Commit: b52d52d680619c198aa8418b00cb455ea0be79f3
https://github.com/WebKit/WebKit/commit/b52d52d680619c198aa8418b00cb455ea0be79f3
Author: Razvan Caliman <rcaliman at apple.com>
Date: 2024-12-05 (Thu, 05 Dec 2024)
Changed paths:
M LayoutTests/http/tests/inspector/network/copy-as-curl.html
M Source/WebInspectorUI/UserInterface/Models/Resource.js
Log Message:
-----------
Web Inspector: Use safer flag when copying request as cURL in Network tab
https://bugs.webkit.org/show_bug.cgi?id=283718
rdar://139882082
Reviewed by Anne van Kesteren.
Do not treat file-like paths like actual file paths.
* Source/WebInspectorUI/UserInterface/Models/Resource.js:
(WI.Resource):
Canonical link: https://commits.webkit.org/283286.565@safari-7620-branch
Commit: b0be8bc5960e2996f4d2b7d60236754149fed114
https://github.com/WebKit/WebKit/commit/b0be8bc5960e2996f4d2b7d60236754149fed114
Author: Tyler Wilcock <tyler_w at apple.com>
Date: 2024-12-05 (Thu, 05 Dec 2024)
Changed paths:
M Source/WebCore/accessibility/AccessibilityObject.cpp
Log Message:
-----------
Cherry-pick 58ed504f03cc. rdar://140934489
AX: In AccessibilityObject::visibleCharacterRange, we can sometimes loop infinitely over next-line-end positions
https://bugs.webkit.org/show_bug.cgi?id=283640
rdar://140487777
Reviewed by Chris Fleizach.
Based on bug reports, it seems that we can loop infinitely in `AccessibilityObject::visibleCharacterRange()` while trying
to the `nextLineEndPosition`. It would be better if we understood why this happened, but can't reproduce it yet, so for
now just break if `nextLineEndPosition` returns the original position. The ASSERT should help us find a webpage where
this reproduces.
* Source/WebCore/accessibility/AccessibilityObject.cpp:
(WebCore::AccessibilityObject::visibleCharacterRangeInternal const):
Canonical link: https://commits.webkit.org/287036@main
Canonical link: https://commits.webkit.org/283286.566@safari-7620-branch
Commit: 8964a07ea3fb6e4a4ebf379c5ef6e2e5873629e7
https://github.com/WebKit/WebKit/commit/8964a07ea3fb6e4a4ebf379c5ef6e2e5873629e7
Author: David Degazio <d_degazio at apple.com>
Date: 2024-12-06 (Fri, 06 Dec 2024)
Changed paths:
A JSTests/wasm/stress/array-copy-with-constant-null.js
M Source/JavaScriptCore/wasm/WasmBBQJIT.cpp
M Source/JavaScriptCore/wasm/WasmBBQJIT.h
M Source/JavaScriptCore/wasm/WasmBBQJIT32_64.cpp
M Source/JavaScriptCore/wasm/WasmBBQJIT64.cpp
M Source/JavaScriptCore/wasm/WasmFunctionParser.h
M Source/JavaScriptCore/wasm/WasmTypeDefinition.h
Log Message:
-----------
[WASM GC] Reference instructions should consume arguments even when operand is constant null
https://bugs.webkit.org/show_bug.cgi?id=283889
rdar://140774231
Reviewed by Yusuke Suzuki.
Fixes all instances where we have a WASM GC opcode that fails to call
consume() on its arguments. Generally this previously happened in the
case we detected one of the arguments was a JSNull constant.
In order to limit the impact of failing to consume(), this patch also
removes a case in BBQJIT::allocateWithHint that would blindly reuse
the existing register binding for a value. This case seems to only have
been reachable when calling allocate() on the result of a C call - a
procedure that allocates a location for its result internally. I've
replaced these redundant allocate() calls with loadIfNecessary() calls,
although we pretty much always expect the value to already be in a
register.
Finally, this patch adds debug-only verification that every value we
pop from the expression stack is consumed in BBQ. This required some
minor changes to the implementations of some instructions to ensure
we don't detect spurious errors. It was a big help in finding buggy
cases when making this patch and should help defend against such bugs
in the future.
* JSTests/wasm/stress/array-copy-with-constant-null.js: Added.
* Source/JavaScriptCore/wasm/WasmBBQJIT.cpp:
(JSC::Wasm::BBQJITImpl::BBQJIT::addTableSet):
(JSC::Wasm::BBQJITImpl::BBQJIT::addTableInit):
(JSC::Wasm::BBQJITImpl::BBQJIT::addTableFill):
(JSC::Wasm::BBQJITImpl::BBQJIT::addTableCopy):
(JSC::Wasm::BBQJITImpl::BBQJIT::addMemoryFill):
(JSC::Wasm::BBQJITImpl::BBQJIT::addMemoryCopy):
(JSC::Wasm::BBQJITImpl::BBQJIT::addMemoryInit):
(JSC::Wasm::BBQJITImpl::BBQJIT::atomicWait):
(JSC::Wasm::BBQJITImpl::BBQJIT::atomicNotify):
(JSC::Wasm::BBQJITImpl::BBQJIT::pushArrayNewFromSegment):
(JSC::Wasm::BBQJITImpl::BBQJIT::addArrayCopy):
(JSC::Wasm::BBQJITImpl::BBQJIT::addArrayInitElem):
(JSC::Wasm::BBQJITImpl::BBQJIT::addArrayInitData):
(JSC::Wasm::BBQJITImpl::BBQJIT::addAnyConvertExtern):
(JSC::Wasm::BBQJITImpl::BBQJIT::addExternConvertAny):
(JSC::Wasm::BBQJITImpl::BBQJIT::willParseOpcode):
(JSC::Wasm::BBQJITImpl::BBQJIT::didPopValueFromStack):
(JSC::Wasm::BBQJITImpl::BBQJIT::allocateWithHint):
(JSC::Wasm::BBQJITImpl::BBQJIT::consume):
* Source/JavaScriptCore/wasm/WasmBBQJIT.h:
* Source/JavaScriptCore/wasm/WasmBBQJIT32_64.cpp:
(JSC::Wasm::BBQJITImpl::BBQJIT::addTableGet):
(JSC::Wasm::BBQJITImpl::BBQJIT::addArrayNewFixed):
(JSC::Wasm::BBQJITImpl::BBQJIT::addArraySet):
(JSC::Wasm::BBQJITImpl::BBQJIT::addArrayFill):
(JSC::Wasm::BBQJITImpl::BBQJIT::addStructNewDefault):
(JSC::Wasm::BBQJITImpl::BBQJIT::addStructNew):
(JSC::Wasm::BBQJITImpl::BBQJIT::addStructSet):
(JSC::Wasm::BBQJITImpl::BBQJIT::addRefCast):
* Source/JavaScriptCore/wasm/WasmBBQJIT64.cpp:
(JSC::Wasm::BBQJITImpl::BBQJIT::addTableGet):
(JSC::Wasm::BBQJITImpl::BBQJIT::addArrayNew):
(JSC::Wasm::BBQJITImpl::BBQJIT::addArrayNewFixed):
(JSC::Wasm::BBQJITImpl::BBQJIT::addArraySet):
(JSC::Wasm::BBQJITImpl::BBQJIT::addArrayFill):
(JSC::Wasm::BBQJITImpl::BBQJIT::addStructNewDefault):
(JSC::Wasm::BBQJITImpl::BBQJIT::addStructNew):
(JSC::Wasm::BBQJITImpl::BBQJIT::addStructSet):
(JSC::Wasm::BBQJITImpl::BBQJIT::addRefCast):
(JSC::Wasm::BBQJITImpl::BBQJIT::addBranchNull):
(JSC::Wasm::BBQJITImpl::BBQJIT::addCallRef):
* Source/JavaScriptCore/wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseExpression):
* Source/JavaScriptCore/wasm/WasmTypeDefinition.h:
(JSC::Wasm::isCompareOpType):
Canonical link: https://commits.webkit.org/283286.567@safari-7620-branch
Commit: 0fd9aaf87eef5a47c0161e3ef79fe5a206dbdc7a
https://github.com/WebKit/WebKit/commit/0fd9aaf87eef5a47c0161e3ef79fe5a206dbdc7a
Author: Sam Sneddon <gsnedders at apple.com>
Date: 2024-12-06 (Fri, 06 Dec 2024)
Changed paths:
M Tools/Scripts/libraries/webkitcorepy/webkitcorepy/autoinstall.py
Log Message:
-----------
Cherry-pick 287426 at main (881ba2ce3758). rdar://140989986
[AutoInstall] Remove any manifest item on failure
https://bugs.webkit.org/show_bug.cgi?id=284086
Reviewed by Jonathan Bedard.
We had an EWS bot in a state where the manifest said something was
installed but it was not, likely due to installation failing.
When we're changing what version of a package is installed,
installation failing can lead us to a state where we have neither the
new nor old version installed, but the manifest would claim that the
old version still was.
To fix this, we delete any relevant manifest item on failure, which
will force a reinstall (of either version) in the future.
Untested, because of https://bugs.webkit.org/show_bug.cgi?id=284070.
* Tools/Scripts/libraries/webkitcorepy/webkitcorepy/autoinstall.py:
(Package.install):
Canonical link: https://commits.webkit.org/287426@main
Canonical link: https://commits.webkit.org/283286.568@safari-7620-branch
Commit: 5c1303f7ac9956a58d62aee9e58e08b556dd58f1
https://github.com/WebKit/WebKit/commit/5c1303f7ac9956a58d62aee9e58e08b556dd58f1
Author: Brianna Fan <bfan2 at apple.com>
Date: 2024-12-09 (Mon, 09 Dec 2024)
Changed paths:
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/pull_request.py
Log Message:
-----------
Cherry-pick 11d225913771. rdar://136986741
[git-webkit] [pr] unable to create branches that match integration scheme via git-webkit pr
https://bugs.webkit.org/show_bug.cgi?id=283444
rdar://136986741
Reviewed by Jonathan Bedard.
Check that the current branch is not a development branch before trying to create
a new branch. This will allow PRs to be made directly from integration branches.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/pull_request.py:
(PullRequest.pull_request_branch_point):
Canonical link: https://commits.webkit.org/287226@main
Canonical link: https://commits.webkit.org/283286.569@safari-7620-branch
Commit: 3f354cd208be70eded052a726a31f0e0d6cbfdc9
https://github.com/WebKit/WebKit/commit/3f354cd208be70eded052a726a31f0e0d6cbfdc9
Author: Dan Robson <dtr_bugzilla at apple.com>
Date: 2024-12-09 (Mon, 09 Dec 2024)
Changed paths:
R LayoutTests/fast/ruby/breaking-opportunity-between-bases-expected.html
R LayoutTests/fast/ruby/breaking-opportunity-between-bases.html
M Source/WebCore/layout/formattingContexts/inline/ruby/RubyFormattingContext.cpp
M Source/WebCore/layout/formattingContexts/inline/text/TextUtil.cpp
M Source/WebCore/layout/formattingContexts/inline/text/TextUtil.h
M Source/WebCore/rendering/InlineWalker.h
M Source/WebCore/rendering/RenderBlockFlow.cpp
Log Message:
-----------
Revert 0efbdbf5ca5a. rdar://141057729
Canonical link: https://commits.webkit.org/283286.570@safari-7620-branch
Commit: 5f6e2a5cad7c799e4832f64d058fac7db8abf85a
https://github.com/WebKit/WebKit/commit/5f6e2a5cad7c799e4832f64d058fac7db8abf85a
Author: Elika Etemad <fantasai.bugs at inkedblade.net>
Date: 2024-12-09 (Mon, 09 Dec 2024)
Changed paths:
M LayoutTests/imported/w3c/web-platform-tests/css/css-backgrounds/parsing/background-shorthand-serialization-expected.txt
M LayoutTests/imported/w3c/web-platform-tests/css/css-backgrounds/parsing/background-shorthand-serialization.html
M LayoutTests/imported/w3c/web-platform-tests/css/css-backgrounds/parsing/background-valid-expected.txt
M LayoutTests/imported/w3c/web-platform-tests/css/css-backgrounds/parsing/background-valid.html
M Source/WebCore/css/ShorthandSerializer.cpp
M Source/WebCore/css/parser/CSSPropertyParser.cpp
Log Message:
-----------
Cherry-pick 81a73e57243b. rdar://141167096
Make background shorthand default to border-box when border-area specified
https://bugs.webkit.org/show_bug.cgi?id=283308
rdar://140142957
Reviewed by Tim Nguyen.
If the origin is not specified, but clip is given as border-area,
set origin to border-box.
See https://github.com/w3c/csswg-drafts/issues/11167
* LayoutTests/imported/w3c/web-platform-tests/css/css-backgrounds/parsing/background-shorthand-serialization-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/css/css-backgrounds/parsing/background-shorthand-serialization.html:
* LayoutTests/imported/w3c/web-platform-tests/css/css-backgrounds/parsing/background-valid-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/css/css-backgrounds/parsing/background-valid.html:
* Source/WebCore/css/ShorthandSerializer.cpp:
(WebCore::ShorthandSerializer::serializeLayered const):
* Source/WebCore/css/parser/CSSPropertyParser.cpp:
(WebCore::CSSPropertyParser::consumeBackgroundShorthand):
Canonical link: https://commits.webkit.org/287521@main
Canonical link: https://commits.webkit.org/283286.571@safari-7620-branch
Commit: fbcccfb28bc683ff7e99a5e4c045114afe431419
https://github.com/WebKit/WebKit/commit/fbcccfb28bc683ff7e99a5e4c045114afe431419
Author: Alex Christensen <achristensen at apple.com>
Date: 2024-12-10 (Tue, 10 Dec 2024)
Changed paths:
M Source/WebCore/platform/network/NetworkStorageSession.cpp
M Source/WebCore/workers/service/server/SWServer.cpp
Log Message:
-----------
Add URL validity checks in NetworkStorageSession::shouldBlockCookies
rdar://140118202
Reviewed by Brent Fulgham.
If a comporomised web process sends IPC with an invalid URL, it can reach
NetworkStorageSession::shouldBlockCookies which should not allow access to
the cookies in that case.
SWServer::createScriptRequest needed a slight modification to stop it from
setting a firstPartyForCookies to an invalid URL like "https:".
* Source/WTF/wtf/cf/URLCF.cpp:
(WTF::URL::createCFURL const):
* Tools/TestWebKitAPI/Tests/WTF/cocoa/URLExtras.mm:
(TestWebKitAPI::TEST(WTF_URLExtras, InvalidURLToNSURL)):
Canonical link: https://commits.webkit.org/283286.572@safari-7620-branch
Commit: 0622d7e931067cfab681512f2b2ca41519feb1b2
https://github.com/WebKit/WebKit/commit/0622d7e931067cfab681512f2b2ca41519feb1b2
Author: Alan Baradlay <zalan at apple.com>
Date: 2024-12-10 (Tue, 10 Dec 2024)
Changed paths:
M LayoutTests/TestExpectations
A LayoutTests/fast/block/float/float-with-negative-margin-formatting-context-root-expected.html
A LayoutTests/fast/block/float/float-with-negative-margin-formatting-context-root.html
M Source/WebCore/rendering/RenderBox.cpp
Log Message:
-----------
Cherry-pick cd5c9f5b2696. rdar://141044532
[Floats] Citi.com login renders incorrectly, login field is shrunk to the side
https://bugs.webkit.org/show_bug.cgi?id=284143
<rdar://140472029>
Unreviewed revert.
This is a revert of 283298 at main (and its follow-up fix of 286637 at main>).
Apparently part of the layout code relies on the fact that negative margins make the available space wider (they don't).
While adjusting the caller logic (RenderBlockFlow::getClearDelta) fixes this incorrect behavior, it also already introduced a regression -see 249370 at main (which later got reverted).
* LayoutTests/TestExpectations:
* LayoutTests/fast/block/float/float-with-negative-margin-formatting-context-root-expected.html: Added.
* LayoutTests/fast/block/float/float-with-negative-margin-formatting-context-root.html: Added.
* Source/WebCore/rendering/RenderBox.cpp:
(WebCore::RenderBox::shrinkLogicalWidthToAvoidFloats const):
Canonical link: https://commits.webkit.org/287442@main
Canonical link: https://commits.webkit.org/283286.573@safari-7620-branch
Commit: 8fbbb5e792fb2af628228f0d734cb4efb23b2cfa
https://github.com/WebKit/WebKit/commit/8fbbb5e792fb2af628228f0d734cb4efb23b2cfa
Author: Daniel Liu <daniel_liu4 at apple.com>
Date: 2024-12-10 (Tue, 10 Dec 2024)
Changed paths:
A JSTests/wasm/stress/array-init-data-bounds.js
M Source/JavaScriptCore/wasm/WasmOperationsInlines.h
Log Message:
-----------
Update incorrect bounds check in arrayInitData that could lead to overflow
https://bugs.webkit.org/show_bug.cgi?id=284332
rdar://140773517
Reviewed by Yusuke Suzuki.
arrayInitData's operation currently checks that the source index plus the size
has not overflowed. However, size is the number of array elements, meaning that
size * elementSize could potentially overflow later on.
* Source/JavaScriptCore/wasm/WasmOperationsInlines.h:
(JSC::Wasm::arrayInitData):
Canonical link: https://commits.webkit.org/283286.574@safari-7620-branch
Commit: ca83d835b014f07f2abebb53131dbfc1c5be1923
https://github.com/WebKit/WebKit/commit/ca83d835b014f07f2abebb53131dbfc1c5be1923
Author: David Degazio <d_degazio at apple.com>
Date: 2024-12-10 (Tue, 10 Dec 2024)
Changed paths:
A JSTests/wasm/stress/tail-call-should-consume-stack-in-bbq.js
M Source/JavaScriptCore/wasm/WasmBBQJIT.cpp
Log Message:
-----------
[WASM] Tail calls should consume expression stack after call in BBQ
https://bugs.webkit.org/show_bug.cgi?id=284159
rdar://141164805
Reviewed by Yusuke Suzuki.
Adds a loop to consume expression stack elements after we
generate a tail call (direct or indirect) in BBQ. This is
consistent with our behavior in the return opcode, and
prevents register bindings from persisting into the
subsequent unreachable code.
* JSTests/wasm/stress/tail-call-should-consume-stack-in-bbq.js: Added.
* Source/JavaScriptCore/wasm/WasmBBQJIT.cpp:
(JSC::Wasm::BBQJITImpl::BBQJIT::emitTailCall):
(JSC::Wasm::BBQJITImpl::BBQJIT::emitIndirectTailCall):
Canonical link: https://commits.webkit.org/283286.575@safari-7620-branch
Commit: 8796a007c6698eedc965910b2ade596fff93ee0e
https://github.com/WebKit/WebKit/commit/8796a007c6698eedc965910b2ade596fff93ee0e
Author: Timothy Hatcher <timothy at apple.com>
Date: 2024-12-10 (Tue, 10 Dec 2024)
Changed paths:
M Source/WebKit/UIProcess/Extensions/Cocoa/WebExtensionContextCocoa.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebExtensionAPIWindows.mm
Log Message:
-----------
Cherry-pick 60a23fece1e2. rdar://141004356
windows.getLastFocused() returns error when last focused window is incognito without access.
https://webkit.org/b/282703
rdar://138030992
Reviewed by Brian Weinstein.
When retrieving the most recently focused window, iterate through all windows and return the
first one that the extension has access to. This approach will bypass any private windows if
the extension does not have access to private data.
* Source/WebKit/UIProcess/Extensions/Cocoa/WebExtensionContextCocoa.mm:
(WebKit::WebExtensionContext::frontmostWindow const): Added loop over all windows.
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebExtensionAPIWindows.mm:
(TestWebKitAPI::TEST(WKWebExtensionAPIWindows, GetCurrentWindowAfterTabMove)): Added.
(TestWebKitAPI::TEST(WKWebExtensionAPIWindows, GetLastFocusedWithPrivateAccess)): Added.
(TestWebKitAPI::TEST(WKWebExtensionAPIWindows, GetLastFocusedWithoutPrivateAccess)): Added.
Canonical link: https://commits.webkit.org/286245@main
Canonical link: https://commits.webkit.org/283286.576@safari-7620-branch
Commit: 68bea8f81731878044e91f1260dd0d46f2979247
https://github.com/WebKit/WebKit/commit/68bea8f81731878044e91f1260dd0d46f2979247
Author: Mohsin Qureshi <mohsinq at apple.com>
Date: 2024-12-10 (Tue, 10 Dec 2024)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7620.2.4
Canonical link: https://commits.webkit.org/283286.577@safari-7620-branch
Commit: de6e83ab1f4d49d2048129632e616251a65117a1
https://github.com/WebKit/WebKit/commit/de6e83ab1f4d49d2048129632e616251a65117a1
Author: Abrar Rahman Protyasha <a_protyasha at apple.com>
Date: 2024-12-11 (Wed, 11 Dec 2024)
Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/PDFIncrementalLoader.h
M Source/WebKit/WebProcess/Plugins/PDF/PDFIncrementalLoader.mm
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.mm
Log Message:
-----------
OOB crash under WebKit::dataProviderGetBytesAtPositionCallback during off-main-thread incremental PDF loading
https://bugs.webkit.org/show_bug.cgi?id=284408
rdar://131110151
Reviewed by Simon Fraser.
We occasionally crash trying to memcpy a buffer for incremental loading
data provision. Here's a representative trace:
```
Thread 4 Crashed:: Dispatch queue: LinearizedPagePreload
0 _platform_memmove + 96
1 void WTF::memcpySpan<unsigned char, 18446744073709551615ul, unsigned char const, 18446744073709551615ul>(std::__1::span<unsigned char, 18446744073709551615ul>, std::__1::span<unsigned char const, 18446744073709551615ul>) + 16
2 WebKit::PDFIncrementalLoader::dataProviderGetBytesAtPosition(std::__1::span<unsigned char, 18446744073709551615ul>, long long) + 52
3 WebKit::dataProviderGetBytesAtPositionCallback(void*, void*, long long, unsigned long) + 308
4 provider_get_bytes_at_position + 84
5 CGDataProviderDirectGetBytesAtPositionInternal + 308
```
While we don't have a reproducible case yet, some analysis of the
incremental loading code suggests there is a small flaw in the threading
model for PDFPluginBase::dataSpanForRange() callers. That method secures
a lock to produce the data span, but if a load stream fails after a
caller gets the data span and before accessing said span, callers may
end up referencing null data.
This patch is a speculative fix for this issue. We teach
dataSpanForRange to accept a completion handler, which callers will
adopt as a substitute for the work they would have done with the data
span they expect to receive. The completion handler can then be called
while the data lock is still held.
This fix exposed an issue with the threading model for debug logging,
since our logging unconditionally jumps to the main thread and requests
to hold the data lock, thus deadlocking the web process. We address this
by securing a copy of m_streamedBytes before jumping across thread
boundaries -- see PDFPluginBase::streamedBytesForDebugLogging(). This
method skirts around thread safety analysis but ensures that the data
lock _is secured_ by the calling thread, else asserting.
* Source/WebKit/WebProcess/Plugins/PDF/PDFIncrementalLoader.h:
* Source/WebKit/WebProcess/Plugins/PDF/PDFIncrementalLoader.mm:
(WebKit::ByteRangeRequest::completeUnconditionally):
(WebKit::PDFIncrementalLoader::dataSpanForRange const):
(WebKit::PDFIncrementalLoader::requestCompleteIfPossible):
(WebKit::PDFIncrementalLoader::dataProviderGetBytesAtPosition):
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h:
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.mm:
(WebKit::PDFPluginBase::dataSpanForRange const):
(WebKit::PDFPluginBase::incrementalLoaderLog):
(WebKit::PDFPluginBase::incrementalLoaderLogWithBytes):
Canonical link: https://commits.webkit.org/283286.578@safari-7620-branch
Commit: 9d8797837e551b2416fd41b8aaea098176cfa703
https://github.com/WebKit/WebKit/commit/9d8797837e551b2416fd41b8aaea098176cfa703
Author: Sihui Liu <sihui_liu at apple.com>
Date: 2024-12-11 (Wed, 11 Dec 2024)
Changed paths:
A LayoutTests/storage/indexeddb/cursor-continue-add-failure-expected.txt
A LayoutTests/storage/indexeddb/cursor-continue-add-failure-private-expected.txt
A LayoutTests/storage/indexeddb/cursor-continue-add-failure-private.html
A LayoutTests/storage/indexeddb/cursor-continue-add-failure.html
A LayoutTests/storage/indexeddb/resources/cursor-continue-add-failure.js
M Source/WebCore/Modules/indexeddb/server/IndexValueStore.cpp
Log Message:
-----------
Cherry-pick 5352e8654190. rdar://141242656
Null pointer dereference in IndexValueStore::Iterator::nextIndexEntry
https://bugs.webkit.org/show_bug.cgi?id=282186
rdar://136799874
Reviewed by Chris Dumez.
Ensure IndexValueStore::removeRecord updates m_orderedKeys when it updates m_records, otherwise when we retrieve record
from m_records with key from m_orderedKeys (like in IndexValueStore::Iterator::nextIndexEntry), there can be null
pointer derererence.
New tests:
LayoutTests/storage/indexeddb/cursor-continue-add-failure.html
LayoutTests/storage/indexeddb/cursor-continue-add-failure-private.html
* LayoutTests/storage/indexeddb/cursor-continue-add-failure-expected.txt: Added.
* LayoutTests/storage/indexeddb/cursor-continue-add-failure-private-expected.txt: Added.
* LayoutTests/storage/indexeddb/cursor-continue-add-failure-private.html: Added.
* LayoutTests/storage/indexeddb/cursor-continue-add-failure.html: Added.
* LayoutTests/storage/indexeddb/resources/cursor-continue-add-failure.js: Added.
(prepareDatabase):
* Source/WebCore/Modules/indexeddb/server/IndexValueStore.cpp:
(WebCore::IDBServer::IndexValueStore::removeRecord):
Canonical link: https://commits.webkit.org/285814@main
Canonical link: https://commits.webkit.org/283286.579@safari-7620-branch
Commit: b5dc52e770f7c3552c732e0dbdb9861e32468f20
https://github.com/WebKit/WebKit/commit/b5dc52e770f7c3552c732e0dbdb9861e32468f20
Author: Per Arne Vollan <pvollan at apple.com>
Date: 2024-12-11 (Wed, 11 Dec 2024)
Changed paths:
M Source/WebKit/Resources/cocoa/NotificationAllowList/EmbeddedForwardedNotifications.def
Log Message:
-----------
Cherry-pick d0c0654bfc11. rdar://141242664
Forward AX notification from UI process to the WebContent process
https://bugs.webkit.org/show_bug.cgi?id=282199
rdar://135538733
Reviewed by Sihui Liu.
When notifyd is blocked in the WebContent process sandbox, we need to forward notifications from
the UI process to the WebContent process in order to respond as expected to these notifications.
* Source/WebKit/Resources/cocoa/NotificationAllowList/EmbeddedForwardedNotifications.def:
Canonical link: https://commits.webkit.org/285816@main
Canonical link: https://commits.webkit.org/283286.580@safari-7620-branch
Commit: cddad120f97edcbd150949349b29647bbce25805
https://github.com/WebKit/WebKit/commit/cddad120f97edcbd150949349b29647bbce25805
Author: Ryosuke Niwa <rniwa at webkit.org>
Date: 2024-12-11 (Wed, 11 Dec 2024)
Changed paths:
A LayoutTests/editing/selection/update-selection-with-find-dissociates-range-expected.txt
A LayoutTests/editing/selection/update-selection-with-find-dissociates-range.html
A LayoutTests/editing/selection/update-selection-with-modify-dissociates-range-expected.txt
A LayoutTests/editing/selection/update-selection-with-modify-dissociates-range.html
M Source/WebCore/editing/FrameSelection.cpp
M Source/WebCore/editing/FrameSelection.h
Log Message:
-----------
Cherry-pick d187066ee9b0. rdar://141232989
REGRESSION (Safari 17): getRangeAt(0) returns the same JS object even after selection changes, differs from Chrome and Firefox
https://bugs.webkit.org/show_bug.cgi?id=273469
<rdar://problem/127314280>
Reviewed by Wenson Hsieh.
This PR makes WebKit's behavior match Gecko's and Blink's behaviors by dissociating live ranges when updating selection except
when we're updating as a result of DOM mutation or via manipulation of live ranges.
* LayoutTests/editing/selection/update-selection-with-find-dissociates-range-expected.txt: Added.
* LayoutTests/editing/selection/update-selection-with-find-dissociates-range.html: Added.
* LayoutTests/editing/selection/update-selection-with-modify-dissociates-range-expected.txt: Added.
* LayoutTests/editing/selection/update-selection-with-modify-dissociates-range.html: Added.
* Source/WebCore/editing/FrameSelection.cpp:
(WebCore::FrameSelection::setSelectionWithoutUpdatingAppearance):
(WebCore::FrameSelection::respondToNodeModification):
(WebCore::FrameSelection::textWasReplaced):
(WebCore::FrameSelection::updateFromAssociatedLiveRange):
(WebCore::FrameSelection::updateAssociatedLiveRange): Deleted.
* Source/WebCore/editing/FrameSelection.h:
Canonical link: https://commits.webkit.org/285996@main
Canonical link: https://commits.webkit.org/283286.581@safari-7620-branch
Commit: 16a0f908664877f0a2dedd28917e9f4b1c787814
https://github.com/WebKit/WebKit/commit/16a0f908664877f0a2dedd28917e9f4b1c787814
Author: Lily Spiniolas <lily_spiniolas at apple.com>
Date: 2024-12-11 (Wed, 11 Dec 2024)
Changed paths:
M Source/WebKit/UIProcess/Launcher/cocoa/ProcessLauncherCocoa.mm
Log Message:
-----------
Cherry-pick 488f8501bcdc. rdar://141232981
Localization is not working correctly in the Web Process on Catalyst
https://bugs.webkit.org/show_bug.cgi?id=283135
rdar://128854487
Reviewed by Abrar Rahman Protyasha and Per Arne Vollan.
Restore xpc_connection_send_bootstrap for Catalyst since it's not using ExtensionKit.
* Source/WebKit/UIProcess/Launcher/cocoa/ProcessLauncherCocoa.mm:
(WebKit::ProcessLauncher::finishLaunchingProcess):
Canonical link: https://commits.webkit.org/286629@main
Canonical link: https://commits.webkit.org/283286.582@safari-7620-branch
Commit: f936712e6292345f1b3c83e36d07db151cc73dd1
https://github.com/WebKit/WebKit/commit/f936712e6292345f1b3c83e36d07db151cc73dd1
Author: Tadeu Zagallo <tzagallo at apple.com>
Date: 2024-12-11 (Wed, 11 Dec 2024)
Changed paths:
M Source/ThirdParty/ANGLE/src/compiler/translator/Types.h
M Source/ThirdParty/ANGLE/src/compiler/translator/msl/EmitMetal.cpp
M Source/ThirdParty/ANGLE/src/compiler/translator/msl/ProgramPrelude.cpp
M Source/ThirdParty/ANGLE/src/tests/gl_tests/GLSLTest.cpp
Log Message:
-----------
Cherry-pick 11b5279aec61. rdar://141201642
REGRESSION: WebGL shader linking error with Metal backend when mixing scalar with vector
https://bugs.webkit.org/show_bug.cgi?id=283576
rdar://140546518
Reviewed by Kimmo Kinnunen.
Update the arithmetic helpers that handle UB to support operations between scalars and vectors.
* Source/ThirdParty/ANGLE/src/compiler/translator/Types.h:
(sh::TType::isSignedInt const):
(sh::TType::isSignedIntegerValue const): Deleted.
* Source/ThirdParty/ANGLE/src/compiler/translator/msl/EmitMetal.cpp:
(GetOperatorString):
(GenMetalTraverser::visitBinary):
* Source/ThirdParty/ANGLE/src/compiler/translator/msl/ProgramPrelude.cpp:
(PROGRAM_PRELUDE_DECLARE):
* Source/ThirdParty/ANGLE/src/tests/gl_tests/GLSLTest.cpp:
Canonical link: https://commits.webkit.org/287588@main
Canonical link: https://commits.webkit.org/283286.583@safari-7620-branch
Commit: 81cdf598d45da785aa8c4339f742f1e315f04a3a
https://github.com/WebKit/WebKit/commit/81cdf598d45da785aa8c4339f742f1e315f04a3a
Author: Charlie Wolfe <charliew at apple.com>
Date: 2024-12-11 (Wed, 11 Dec 2024)
Changed paths:
M Source/WebKit/NetworkProcess/NetworkProcess.cpp
M Source/WebKit/NetworkProcess/NetworkProcess.h
M Source/WebKit/NetworkProcess/NetworkResourceLoader.cpp
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebProcessPool.cpp
M Source/WebKit/UIProcess/WebProcessPool.h
Log Message:
-----------
Data Isolation bypass using webarchive requests loaded from file URLs
https://bugs.webkit.org/show_bug.cgi?id=284433
rdar://140567264
Reviewed by Alex Christensen.
Loading a web archive will already force a process swap, but the UI process will not always tell the
network process to add unconditional cookie access for the new web process. If we do correctly tell the
network process this, we can remove the web processes ability to give itself cookie access using
webarchives loaded from file URLs.
* Source/WebKit/NetworkProcess/NetworkProcess.cpp:
(WebKit::NetworkProcess::webProcessWillLoadWebArchive): Deleted.
* Source/WebKit/NetworkProcess/NetworkProcess.h:
* Source/WebKit/NetworkProcess/NetworkResourceLoader.cpp:
(WebKit::NetworkResourceLoader::didReceiveMainResourceResponse):
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::receivedNavigationActionPolicyDecision):
* Source/WebKit/UIProcess/WebProcessPool.cpp:
(WebKit::WebProcessPool::processForNavigation):
(WebKit::WebProcessPool::prepareProcessForNavigation):
* Source/WebKit/UIProcess/WebProcessPool.h:
Canonical link: https://commits.webkit.org/283286.584@safari-7620-branch
Commit: dc56db7312ebc778ece5b924256186e77b9c7fac
https://github.com/WebKit/WebKit/commit/dc56db7312ebc778ece5b924256186e77b9c7fac
Author: Charlie Wolfe <charliew at apple.com>
Date: 2024-12-11 (Wed, 11 Dec 2024)
Changed paths:
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp
Log Message:
-----------
NetworkConnectionToWebProcess::performSynchronousLoad should have a Data Isolation check
https://bugs.webkit.org/show_bug.cgi?id=284434
rdar://141255904
Reviewed by Alex Christensen.
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:
(WebKit::NetworkConnectionToWebProcess::performSynchronousLoad):
Canonical link: https://commits.webkit.org/283286.585@safari-7620-branch
Commit: bddd7907adf87ece73f391eda8b814ad92c37263
https://github.com/WebKit/WebKit/commit/bddd7907adf87ece73f391eda8b814ad92c37263
Author: Matthew Finkel <m_finkel at apple.com>
Date: 2024-12-11 (Wed, 11 Dec 2024)
Changed paths:
M LayoutTests/http/tests/security/file-system-access-via-dataTransfer-expected.txt
M LayoutTests/http/tests/security/file-system-access-via-dataTransfer.html
A LayoutTests/platform/mac-wk1/http/tests/security/file-system-access-via-dataTransfer-expected.txt
M Source/WebCore/Modules/entriesapi/DOMFileSystem.cpp
Log Message:
-----------
Enforce m_rootPath for remaining DOMFileSystem file access
https://bugs.webkit.org/show_bug.cgi?id=283117
rdar://139533231
Reviewed by Chris Dumez.
This is a follow-up to 276184 at main where I added validation in
DOMFileSystem::get{Entry,File}. That missed the ability to leverage getParent
and listDirectory for testing if a directory exists. This patch closes that
hole.
* LayoutTests/http/tests/security/file-system-access-via-dataTransfer-expected.txt:
* LayoutTests/http/tests/security/file-system-access-via-dataTransfer.html:
* LayoutTests/platform/mac-wk1/http/tests/security/file-system-access-via-dataTransfer-expected.txt: Copied from LayoutTests/http/tests/security/file-system-access-via-dataTransfer-expected.txt.
* Source/WebCore/Modules/entriesapi/DOMFileSystem.cpp:
(WebCore::DOMFileSystem::listDirectory):
(WebCore::DOMFileSystem::getParent):
Canonical link: https://commits.webkit.org/283286.586@safari-7620-branch
Commit: 13727b6c9d8d59429cb28af6b837e32386520884
https://github.com/WebKit/WebKit/commit/13727b6c9d8d59429cb28af6b837e32386520884
Author: Vitor Roriz <vitor.roriz at apple.com>
Date: 2024-12-11 (Wed, 11 Dec 2024)
Changed paths:
M LayoutTests/imported/w3c/web-platform-tests/encoding/legacy-mb-schinese/gb18030/gb18030-decoder.any.js
M LayoutTests/imported/w3c/web-platform-tests/encoding/legacy-mb-schinese/gb18030/gb18030-encoder.html
M Source/WebCore/PAL/pal/text/TextCodecCJK.cpp
Log Message:
-----------
Cherry-pick 4659e88a8afd. rdar://141296839
Adopt GB18030-2022 <-> Unicode mapping recommendation
https://bugs.webkit.org/show_bug.cgi?id=279761
rdar://124367525
Reviewed by Alex Christensen.
As per [1] the Unicode Technical Committee recommends an updated mapping between GB18030 and Unicode
which we follow here.
Related tests need to be updated and exported to WPT. The PDF [1] contains a text
file attachment with the recommended mapping, which is:
Transcoding From Unicode Standard to GB 18030:
U+E78D -> 0xA6D9
U+E78E -> 0xA6DA
U+E78F -> 0xA6DB
U+E790 -> 0xA6DC
U+E791 -> 0xA6DD
U+E792 -> 0xA6DE
U+E793 -> 0xA6DF
U+E794 -> 0xA6EC
U+E795 -> 0xA6ED
U+E796 -> 0xA6F3
U+E81E -> 0xFE59
U+E826 -> 0xFE61
U+E82B -> 0xFE66
U+E82C -> 0xFE67
U+E832 -> 0xFE6D
U+E843 -> 0xFE7E
U+E854 -> 0xFE90
U+E864 -> 0xFEA0
Transcoding From GB 18030 to Unicode Standard:
0x82359037 -> U+9FB4
0x82359038 -> U+9FB5
0x82359039 -> U+9FB6
0x82359130 -> U+9FB7
0x82359131 -> U+9FB8
0x82359132 -> U+9FB9
0x82359133 -> U+9FBA
0x82359134 -> U+9FBB
0x84318236 -> U+FE10
0x84318237 -> U+FE11
0x84318238 -> U+FE12
0x84318239 -> U+FE13
0x84318330 -> U+FE14
0x84318331 -> U+FE15
0x84318332 -> U+FE16
0x84318333 -> U+FE17
0x84318334 -> U+FE18
0x84318335 -> U+FE19
[1] https://www.unicode.org/L2/L2023/23003r-gb18030-recommendations.pdf brings new mapping recommendations between GB18030 and Unicode.
* LayoutTests/imported/w3c/web-platform-tests/encoding/legacy-mb-schinese/gb18030/gb18030-decoder.any.js:
* LayoutTests/imported/w3c/web-platform-tests/encoding/legacy-mb-schinese/gb18030/gb18030-encoder.html:
* Source/WebCore/PAL/pal/text/TextCodecCJK.cpp:
(PAL::gb180302022Encode):
(PAL::gb180302022Decode):
Canonical link: https://commits.webkit.org/283724@main
Canonical link: https://commits.webkit.org/283286.587@safari-7620-branch
Commit: bfdd18f4ba2348aeda742260bafae735197a1e68
https://github.com/WebKit/WebKit/commit/bfdd18f4ba2348aeda742260bafae735197a1e68
Author: Said Abou-Hallawa <said at apple.com>
Date: 2024-12-11 (Wed, 11 Dec 2024)
Changed paths:
A LayoutTests/svg/custom/quadratic-path-in-tiled-layer-expected.html
A LayoutTests/svg/custom/quadratic-path-in-tiled-layer.html
M Source/WebCore/platform/graphics/PathSegmentData.cpp
Log Message:
-----------
Cherry-pick 5eadead07f65. rdar://141294412
REGRESSION(265569 at main): SVG paths can get clipped at tile boundaries
https://bugs.webkit.org/show_bug.cgi?id=279105
rdar://135280080
Reviewed by Simon Fraser.
When the distance between the current point and the end point of a cubic Bézier
curve is split into three equal parts with the two control points, the slope of
the curve can't be calculated from the derivative of the curve equation.
But in this case, the curve has to be quadratic which means the t-coordinate of
its vertex must be the mid-point between the current point and the end point.
* LayoutTests/svg/custom/quadratic-path-in-tiled-layer-expected.html: Added.
* LayoutTests/svg/custom/quadratic-path-in-tiled-layer.html: Added.
* Source/WebCore/platform/graphics/PathSegmentData.cpp:
(WebCore::calculateBezierExtremities):
Canonical link: https://commits.webkit.org/286550@main
Canonical link: https://commits.webkit.org/283286.588@safari-7620-branch
Commit: 3a50268a98872e61d9fe3239853b86d3914de63e
https://github.com/WebKit/WebKit/commit/3a50268a98872e61d9fe3239853b86d3914de63e
Author: Youenn Fablet <youenn at apple.com>
Date: 2024-12-11 (Wed, 11 Dec 2024)
Changed paths:
M Source/WebKit/GPUProcess/GPUConnectionToWebProcess.cpp
M Source/WebKit/GPUProcess/GPUConnectionToWebProcess.h
M Source/WebKit/GPUProcess/cocoa/GPUConnectionToWebProcessCocoa.mm
M Source/WebKit/Shared/GPUProcessConnectionParameters.h
M Source/WebKit/Shared/GPUProcessConnectionParameters.serialization.in
M Source/WebKit/UIProcess/WebProcessPool.cpp
Log Message:
-----------
Cherry-pick b72771d05c67. rdar://141313819
Use UIProcess application bundle identifier if GPUProcess is not able to compute it itself
rdar://140402550
https://bugs.webkit.org/show_bug.cgi?id=284232
Reviewed by Andy Estes.
The call to LSBundleProxy bundleProxyWithAuditToken sometimes fails in GPUProcess.
We send the bundle identifier from UIProcess to GPUProcess so that, if the above call fails, we fallback to the provided bundle identifier.
This ensures that camera capture will not fail in case media environment is not enabled and the LSBundleProxy bundleProxyWithAuditToken call fails.
Manually tested.
* Source/WebKit/GPUProcess/GPUConnectionToWebProcess.cpp:
* Source/WebKit/GPUProcess/GPUConnectionToWebProcess.h:
(WebKit::GPUConnectionToWebProcess::applicationBundleIdentifier const):
* Source/WebKit/GPUProcess/cocoa/GPUConnectionToWebProcessCocoa.mm:
(WebKit::GPUConnectionToWebProcess::setTCCIdentity):
* Source/WebKit/Shared/GPUProcessConnectionParameters.h:
* Source/WebKit/Shared/GPUProcessConnectionParameters.serialization.in:
* Source/WebKit/UIProcess/WebProcessPool.cpp:
(WebKit::WebProcessPool::createGPUProcessConnection):
Canonical link: https://commits.webkit.org/287561@main
Canonical link: https://commits.webkit.org/283286.589@safari-7620-branch
Commit: 6d0308e77f39e4108680fc32227bf4e9f236c37b
https://github.com/WebKit/WebKit/commit/6d0308e77f39e4108680fc32227bf4e9f236c37b
Author: Timothy Hatcher <timothy at apple.com>
Date: 2024-12-12 (Thu, 12 Dec 2024)
Changed paths:
M Source/WebKit/UIProcess/Extensions/Cocoa/WebExtensionCocoa.mm
M Source/WebKit/UIProcess/Extensions/Cocoa/WebExtensionContextCocoa.mm
M Source/WebKit/UIProcess/Extensions/Cocoa/WebExtensionDynamicScriptsCocoa.mm
M Source/WebKit/UIProcess/Extensions/Cocoa/WebExtensionURLSchemeHandlerCocoa.mm
M Source/WebKit/UIProcess/Extensions/WebExtension.h
M Source/WebKit/UIProcess/Extensions/WebExtensionContext.h
M Source/WebKit/UIProcess/Extensions/WebExtensionDynamicScripts.h
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebExtensionAPILocalization.mm
Log Message:
-----------
Cherry-pick 563ab233542f. rdar://141046751
Web Extensions do not replace @@extension_id in content scripts.
https://webkit.org/b/282259
rdar://138779942
Reviewed by Brian Weinstein.
We were localizing CSS resources loaded in web views, but not the content scripts injected
via `API::UserScript`. Do the same localizing for those content scripts.
* Source/WebKit/UIProcess/Extensions/Cocoa/WebExtensionCocoa.mm:
(WebKit::WebExtension::imageForPath): Check MIME type.
(WebKit::WebExtension::resourceTypeForPath): Deleted.
* Source/WebKit/UIProcess/Extensions/Cocoa/WebExtensionContextCocoa.mm:
(WebKit::WebExtensionContext::localizedResourceData): Added.
(WebKit::WebExtensionContext::localizedResourceString): Added.
(WebKit::WebExtensionContext::addInjectedContent): Localize string.
* Source/WebKit/UIProcess/Extensions/Cocoa/WebExtensionDynamicScriptsCocoa.mm:
(WebKit::WebExtensionDynamicScripts::sourcePairForResource): Localize string.
* Source/WebKit/UIProcess/Extensions/Cocoa/WebExtensionURLSchemeHandlerCocoa.mm:
(WebKit::WebExtensionURLSchemeHandler::platformStartTask):
* Source/WebKit/UIProcess/Extensions/WebExtension.cpp:
(WebKit::WebExtension::resourceMIMETypeForPath): Added.
* Source/WebKit/UIProcess/Extensions/WebExtension.h:
* Source/WebKit/UIProcess/Extensions/WebExtensionContext.h:
* Source/WebKit/UIProcess/Extensions/WebExtensionDynamicScripts.h:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebExtensionAPILocalization.mm:
(TestWebKitAPI::TEST(WKWebExtensionAPILocalization, CSSLocalizationInContentScript)): Added.
(TestWebKitAPI::TEST(WKWebExtensionAPILocalization, CSSLocalizationInRegisteredContentScript)): Added.
Canonical link: https://commits.webkit.org/285858@main
Canonical link: https://commits.webkit.org/283286.590@safari-7620-branch
Commit: b31ed7f5f5279672f9a0f243cec259be695a5816
https://github.com/WebKit/WebKit/commit/b31ed7f5f5279672f9a0f243cec259be695a5816
Author: Nitin Mahendru <nitinmahendru at apple.com>
Date: 2024-12-12 (Thu, 12 Dec 2024)
Changed paths:
M Source/WebCore/bindings/js/SerializedScriptValue.cpp
Log Message:
-----------
Add fail() to correctly terminate deserialization
https://bugs.webkit.org/show_bug.cgi?id=284558
rdar://140885860
Reviewed by Pascoe.
Just returning JSValue() will not stop the deserialization process.
* Source/WebCore/bindings/js/SerializedScriptValue.cpp:
(WebCore::CloneDeserializer::readTerminal):
Canonical link: https://commits.webkit.org/283286.591@safari-7620-branch
Commit: e1c799f4f3fd98c002cb6c5d500c451371d8c1d7
https://github.com/WebKit/WebKit/commit/e1c799f4f3fd98c002cb6c5d500c451371d8c1d7
Author: Jessica Cheung <jcheung23 at apple.com>
Date: 2024-12-13 (Fri, 13 Dec 2024)
Changed paths:
M Source/WebKit/UIProcess/ios/DragDropInteractionState.h
M Source/WebKit/UIProcess/ios/DragDropInteractionState.mm
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
Log Message:
-----------
Cherry-pick 3b34f7ad5178. rdar://141233047
Fix drag previews to disappear when cancelling drag in Safari
https://bugs.webkit.org/show_bug.cgi?id=280854
rdar://136328215
Reviewed by Wenson Hsieh.
Currently, drag previews remain on the screen because we do not remove
all of the previews from the view hierarchy.
This is fixed by having a vector of views to be removed instead of just one view.
* Source/WebKit/UIProcess/ios/DragDropInteractionState.h:
(WebKit::DragDropInteractionState::takePreviewViewsForDragCancel):
(WebKit::DragDropInteractionState::takePreviewViewForDragCancel): Deleted.
* Source/WebKit/UIProcess/ios/DragDropInteractionState.mm:
(WebKit::DragDropInteractionState::previewForCancelling):
(WebKit::DragDropInteractionState::dragAndDropSessionsDidBecomeInactive):
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView dragInteraction:item:willAnimateCancelWithAnimator:]):
Canonical link: https://commits.webkit.org/284657@main
Canonical link: https://commits.webkit.org/283286.592@safari-7620-branch
Commit: 949d5623b168b5a5097603c13790bab70dffbd55
https://github.com/WebKit/WebKit/commit/949d5623b168b5a5097603c13790bab70dffbd55
Author: Matt Woodrow <mattwoodrow at apple.com>
Date: 2024-12-13 (Fri, 13 Dec 2024)
Changed paths:
M Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeDrawingAreaProxyMac.mm
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.h
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKit/WebProcess/WebPage/WebPage.messages.in
M Source/WebKit/WebProcess/WebPage/mac/RemoteLayerTreeDrawingAreaMac.h
M Source/WebKit/WebProcess/WebPage/mac/RemoteLayerTreeDrawingAreaMac.mm
Log Message:
-----------
Cherry-pick 489ebd22bb25. rdar://141448654
Make RemoteLayerTreeDrawingAreaProxyMac::sendCommitTransientZoom go via the WebPageProxy.
https://bugs.webkit.org/show_bug.cgi?id=280165
<rdar://136468076>
Reviewed by Simon Fraser.
Page scales currently get set via the WebPageProxy, and the WebProcess/WebPage.
It will make things simpler for site-isolation (and update remote frame
processes) if we can canonically go via the the WebPageProxy.
This moves commitTransientZoom to use the WebPageProxy setters.
* Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeDrawingAreaProxyMac.mm:
(WebKit::RemoteLayerTreeDrawingAreaProxyMac::sendCommitTransientZoom):
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::scalePage):
(WebKit::WebPageProxy::scalePageInViewCoordinates):
(WebKit::WebPageProxy::scalePageRelativeToScrollPosition):
* Source/WebKit/UIProcess/WebPageProxy.h:
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::didScalePage):
(WebKit::WebPage::didScalePageInViewCoordinates):
(WebKit::WebPage::didScalePageRelativeToScrollPosition):
(WebKit::WebPage::scalePage):
(WebKit::WebPage::scalePageInViewCoordinates): Deleted.
* Source/WebKit/WebProcess/WebPage/WebPage.h:
* Source/WebKit/WebProcess/WebPage/WebPage.messages.in:
* Source/WebKit/WebProcess/WebPage/mac/RemoteLayerTreeDrawingAreaMac.h:
* Source/WebKit/WebProcess/WebPage/mac/RemoteLayerTreeDrawingAreaMac.mm:
(WebKit::RemoteLayerTreeDrawingAreaMac::applyTransientZoomToPage): Deleted.
(WebKit::RemoteLayerTreeDrawingAreaMac::commitTransientZoom): Deleted.
Canonical link: https://commits.webkit.org/284111@main
Canonical link: https://commits.webkit.org/283286.593@safari-7620-branch
Commit: a32d9df60636f4ee4087eef84170468556aa3542
https://github.com/WebKit/WebKit/commit/a32d9df60636f4ee4087eef84170468556aa3542
Author: Tyler Wilcock <tyler_w at apple.com>
Date: 2024-12-16 (Mon, 16 Dec 2024)
Changed paths:
A LayoutTests/accessibility/display-none-descendant-of-relation-expected.txt
A LayoutTests/accessibility/display-none-descendant-of-relation.html
M LayoutTests/platform/glib/TestExpectations
M LayoutTests/platform/ios/TestExpectations
A LayoutTests/platform/ios/accessibility/display-none-descendant-of-relation-expected.txt
M Source/WebCore/accessibility/AXObjectCache.cpp
M Source/WebCore/accessibility/AXObjectCache.h
M Source/WebCore/accessibility/AccessibilityNodeObject.cpp
M Source/WebCore/accessibility/AccessibilityObject.cpp
M Source/WebCore/accessibility/AccessibilityObject.h
M Source/WebCore/accessibility/AccessibilityTableRow.cpp
Log Message:
-----------
Cherry-pick db2c73f6239b. rdar://141174582
AX: content of <script> elements announced by VoiceOver inside containers with display: contents
https://bugs.webkit.org/show_bug.cgi?id=283645
rdar://problem/140493798
Reviewed by Chris Fleizach.
Up until this point, we have got away with not handling display:none (which is the user-agent default `display` for
script) because it causes the content within to not have a renderer, and thus not be a candidate for AX object creation,
minus a few exceptions — display:contents, elements within a canvas, a few others, and most notably: elements descending
from another element involved in a relation.
Because the unrendered text inside the script tag is descendant of an element with a relation, we create an AX object
for it. And because AccessibilityNodeObject::computeIsIgnored didn't check for a display:none ancestor, we compute
the unrendered text inside the script to be unignored.
With this commit, we check for display:none in our existing walk up the ancestry as part of the
AccessibilityObject::defaultObjectInclusion(), and ignore the object if we find one.
* LayoutTests/accessibility/display-none-descendant-of-relation-expected.txt: Added.
* LayoutTests/accessibility/display-none-descendant-of-relation.html: Added.
* LayoutTests/platform/glib/TestExpectations: Skip new test.
* LayoutTests/platform/ios/TestExpectations: Enable new test.
* LayoutTests/platform/ios/accessibility/display-none-descendant-of-relation-expected.txt: Added.
* Source/WebCore/accessibility/AXObjectCache.cpp:
(WebCore::isDOMHidden):
* Source/WebCore/accessibility/AXObjectCache.h:
* Source/WebCore/accessibility/AccessibilityNodeObject.cpp:
(WebCore::AccessibilityNodeObject::computeIsIgnored const):
* Source/WebCore/accessibility/AccessibilityObject.cpp:
(WebCore::AccessibilityObject::style const):
(WebCore::AccessibilityObject::existingStyle const):
(WebCore::AccessibilityObject::defaultObjectInclusion const):
* Source/WebCore/accessibility/AccessibilityObject.h:
Canonical link: https://commits.webkit.org/287159@main
Canonical link: https://commits.webkit.org/283286.594@safari-7620-branch
Commit: 0053acf9bc558b4e84ac31d66ddd79ede81c4dd3
https://github.com/WebKit/WebKit/commit/0053acf9bc558b4e84ac31d66ddd79ede81c4dd3
Author: Jonathan Bedard <jbedard at apple.com>
Date: 2024-12-16 (Mon, 16 Dec 2024)
Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.mm
Log Message:
-----------
Fixed Debug build after 283286.578 at safari-7620-branch
https://bugs.webkit.org/show_bug.cgi?id=284408
rdar://141548517
Unreviewed build fix.
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.mm:
(WebKit::PDFPluginBase::incrementalLoaderLogWithBytes): Guard logging
with HAVE(INCREMENTAL_PDF_APIS).
Canonical link: https://commits.webkit.org/283286.595@safari-7620-branch
Commit: e57de05ab1d332fd2dc5fddb8687e5f1bf02646e
https://github.com/WebKit/WebKit/commit/e57de05ab1d332fd2dc5fddb8687e5f1bf02646e
Author: Qianlang Chen <qianlangchen at apple.com>
Date: 2024-12-16 (Mon, 16 Dec 2024)
Changed paths:
M Source/WebCore/inspector/agents/InspectorWorkerAgent.cpp
M Source/WebCore/inspector/agents/InspectorWorkerAgent.h
M Source/WebCore/inspector/agents/page/PageWorkerAgent.cpp
M Source/WebCore/inspector/agents/page/PageWorkerAgent.h
M Source/WebCore/inspector/agents/worker/WorkerWorkerAgent.cpp
M Source/WebCore/inspector/agents/worker/WorkerWorkerAgent.h
M Source/WebCore/workers/WorkerInspectorProxy.cpp
M Source/WebCore/workers/WorkerInspectorProxy.h
Log Message:
-----------
UAF may occur in WorkerInspectorProxy::sendMessageFromWorkerToFrontend
https://bugs.webkit.org/show_bug.cgi?id=284327
rdar://140133704
Reviewed by Chris Dumez.
WorkerInspectorProxy::m_pageChannel is a raw pointer and is prone to
being UAF. However, making the PageChannel class ref-counted is not
straightforward as WorkerInspectorController uses an array of
`std::unique_ptr`s to record that PageChannel and other agent objects (https://github.com/WebKit/WebKit/blob/3fa7ffbf74469b65cf23a05c1780319954860f3c/Source/WebCore/inspector/WorkerInspectorController.cpp#L217,
where WorkerWorkerAgent subclasses InspectorWorkerAgent and PageChannel).
My solution is to make PageChannel ref-counted but also make the class
pointed to by a std::unique_ptr own a PageChannel rather than inheriting
from PageChannel. That way, we can maintain unique_ptrs to
InspectorWorkerAgent and still have RefPtrs to PageChannel.
* Source/WebCore/inspector/agents/InspectorWorkerAgent.h:
* Source/WebCore/inspector/agents/InspectorWorkerAgent.cpp:
(WebCore::InspectorWorkerAgent::InspectorWorkerAgent):
(WebCore::InspectorWorkerAgent::~InspectorWorkerAgent):
(WebCore::InspectorWorkerAgent::connectToWorkerInspectorProxy):
(WebCore::InspectorWorkerAgent::PageChannel::create):
(WebCore::InspectorWorkerAgent::PageChannel::PageChannel):
(WebCore::InspectorWorkerAgent::PageChannel::detachFromParentAgent):
- Make the PageChannel class ref-counted.
(WebCore::InspectorWorkerAgent::frontendDispatcher):
(WebCore::InspectorWorkerAgent::sendMessageFromWorkerToFrontend): Deleted.
(WebCore::InspectorWorkerAgent::PageChannel::sendMessageFromWorkerToFrontend):
- Reroute the sendMessageFromWorkerToFrontend method since now
InspectorWorkerAgent owns the page channel instead of being one.
* Source/WebCore/workers/WorkerInspectorProxy.h:
* Source/WebCore/workers/WorkerInspectorProxy.cpp:
(WebCore::WorkerInspectorProxy::sendMessageFromWorkerToFrontend):
* Source/WebCore/inspector/agents/page/PageWorkerAgent.cpp:
* Source/WebCore/inspector/agents/page/PageWorkerAgent.h:
* Source/WebCore/inspector/agents/worker/WorkerWorkerAgent.cpp:
* Source/WebCore/inspector/agents/worker/WorkerWorkerAgent.h:
- Enable the InspectorWorkerAgent::PageChannel class to be
ref-counted.
Canonical link: https://commits.webkit.org/283286.596@safari-7620-branch
Commit: 44a8fccce2ebff5687f24e88dd943d9ce83c1a9e
https://github.com/WebKit/WebKit/commit/44a8fccce2ebff5687f24e88dd943d9ce83c1a9e
Author: Jer Noble <jer.noble at apple.com>
Date: 2024-12-16 (Mon, 16 Dec 2024)
Changed paths:
M Source/WebCore/dom/Document.cpp
M Source/WebCore/dom/Document.h
M Source/WebCore/dom/FullscreenManager.cpp
M Source/WebCore/dom/FullscreenManager.h
M Source/WebCore/page/Page.cpp
M Source/WebCore/page/Page.h
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.h
M Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm
M Source/WebKit/UIProcess/mac/WKFullScreenWindowController.mm
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKit/WebProcess/WebPage/WebPage.messages.in
Log Message:
-----------
Cherry-pick fa5e0c0d9325. rdar://140010042
[macOS] Videos on Bing.com cannot successfully enter fullscreen
https://bugs.webkit.org/show_bug.cgi?id=282668
rdar://126570526
Reviewed by Jean-Yves Avenard.
On Bing.com, the page includes a list of iframe elements whose contents
point to youtube.com embeds. As the user scrolls through the page, script
running on Bing.com notes that the iframe elements have been scrolled out
of the viewport, and tears down their contents. During the fullscreen
transition, the iframe contents are in fullscreen mode and are visible in
the top layer, but the div containing those contents has been scrolled
offscreen. Additionally, the code checking for whether the iframes are
visible runs when the window fires the "scroll" and "resize" events, which
are fired during the fullscreen transition.
Two changes are needed to fix this behavior:
1. Calling WebPageProxy::setPageScale()
has the side effect of scrolling the page back to the origin of (0, 0). This
call is replaced with scalePageRelativeToScrollPosition(), which does not
change the scroll position.
2. Defer firing "scroll" and "resize" events until after "fullscreenchange"
fires. This ensures that the page doesn't get an intermediate state during
the fullscreen transition in which to check the layout of its contents.
* Source/WebCore/dom/Document.cpp:
(WebCore::Document::setNeedsDOMWindowResizeEvent):
(WebCore::Document::setNeedsVisualViewportResize):
(WebCore::Document::runResizeSteps):
(WebCore::Document::flushDeferredResizeEvents):
(WebCore::Document::runScrollSteps):
(WebCore::Document::flushDeferredScrollEvents):
(WebCore::Document::updateResizeObservations):
* Source/WebCore/dom/Document.h:
* Source/WebCore/dom/FullscreenManager.cpp:
(WebCore::FullscreenManager::setAnimatingFullscreen):
(WebCore::FullscreenManager::clear):
(WebCore::FullscreenManager::addPendingScheduledResize): Deleted.
* Source/WebCore/dom/FullscreenManager.h:
* Source/WebCore/page/Page.cpp:
(WebCore::Page::deferResizeEvents):
(WebCore::Page::flushDeferredResizeEvents):
(WebCore::Page::deferScrollEvents):
(WebCore::Page::flushDeferredScrollEvents):
* Source/WebCore/page/Page.h:
(WebCore::Page::shouldDeferResizeEvents const):
(WebCore::Page::shouldDeferScrollEvents const):
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::deferResizeEvents):
(WebKit::WebPageProxy::flushDeferredResizeEvents):
(WebKit::WebPageProxy::deferScrollEvents):
(WebKit::WebPageProxy::flushDeferredScrollEvents):
* Source/WebKit/UIProcess/WebPageProxy.h:
* Source/WebKit/UIProcess/mac/WKFullScreenWindowController.mm:
(-[WKFullScreenWindowController enterFullScreen:]):
(-[WKFullScreenWindowController finishedEnterFullScreenAnimation:]):
(-[WKFullScreenWindowController exitFullScreen]):
(-[WKFullScreenWindowController finishedExitFullScreenAnimationAndExitImmediately:]):
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::deferResizeEvents):
(WebKit::WebPage::flushDeferredResizeEvents):
(WebKit::WebPage::deferScrollEvents):
(WebKit::WebPage::flushDeferredScrollEvents):
* Source/WebKit/WebProcess/WebPage/WebPage.h:
* Source/WebKit/WebProcess/WebPage/WebPage.messages.in:
* Tools/TestWebKitAPI/SourcesCocoa.txt:
* Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/FullscreenScrollAndResize.mm: Added.
(TestWebKitAPI::TEST(Fullscreen, ScrollAndResize)):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/LoadAndDecodeImage.mm:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WebPushDaemon.mm:
Canonical link: https://commits.webkit.org/286501@main
Fix build errors in WebPageProxy.cpp
Canonical link: https://commits.webkit.org/283286.597@safari-7620-branch
Commit: 9115f8a9fe0bb79ed1b990c410729a94b6ce83e2
https://github.com/WebKit/WebKit/commit/9115f8a9fe0bb79ed1b990c410729a94b6ce83e2
Author: Basuke Suzuki <basuke at apple.com>
Date: 2024-12-16 (Mon, 16 Dec 2024)
Changed paths:
M Source/WebCore/loader/MixedContentChecker.cpp
M Source/WebCore/loader/MixedContentChecker.h
M Tools/TestWebKitAPI/CMakeLists.txt
M Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
A Tools/TestWebKitAPI/Tests/WebCore/MixedContentChecker.cpp
Log Message:
-----------
Cherry-pick 2408b78fe654. rdar://141243756
Allow upgrade requests in mixed content if the scheme is handled by scheme handler.
https://bugs.webkit.org/show_bug.cgi?id=281883
rdar://131077815
Reviewed by Matthew Finkel.
In 274409 at main, request upgrade in mixed content was implemented strictly following the spec.
https://www.w3.org/TR/mixed-content/#upgrade-algorithm
But for the compatibility of WKWebView, request upgrade should be allowed when the request is handled by special scheme handler.
This patch adds exception for the upgradable check in MixedContentChecker::shouldUpgradeInsecureContent().
Also adding first API test for MixedContentChecker by extracting the check for easier unit testing.
* Source/WebCore/loader/MixedContentChecker.cpp:
(WebCore::destinationIsImageAndInitiatorIsImageset):
(WebCore::MixedContentChecker::shouldUpgradeInsecureContent):
(WebCore::MixedContentChecker::canModifyRequest):
* Source/WebCore/loader/MixedContentChecker.h:
* Tools/TestWebKitAPI/CMakeLists.txt:
* Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* Tools/TestWebKitAPI/Tests/WebCore/MixedContentChecker.cpp: Added.
(TestWebKitAPI::TEST(MixedContentChecker, CanModifyRequest)):
Canonical link: https://commits.webkit.org/285709@main
Canonical link: https://commits.webkit.org/283286.598@safari-7620-branch
Commit: 6a1f65e50c2ec8066c9139b5c212a690131e8d2a
https://github.com/WebKit/WebKit/commit/6a1f65e50c2ec8066c9139b5c212a690131e8d2a
Author: Alan Baradlay <zalan at apple.com>
Date: 2024-12-16 (Mon, 16 Dec 2024)
Changed paths:
A LayoutTests/imported/w3c/web-platform-tests/css/css-inline/text-box-trim/text-box-trim-on-button-expected.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-inline/text-box-trim/text-box-trim-on-button-ref.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-inline/text-box-trim/text-box-trim-on-button.html
M Source/WebCore/rendering/RenderButton.cpp
Log Message:
-----------
Cherry-pick b47ee90772a5. rdar://141556699
`text-box` is not working correctly on buttons in Safari
https://bugs.webkit.org/show_bug.cgi?id=284683
<rdar://141460045>
Reviewed by Antti Koivisto.
RenderButton propagates its style to the inner anonymous block container (which has the button content).
* Source/WebCore/rendering/RenderButton.cpp:
(WebCore::RenderButton::updateAnonymousChildStyle const):
Canonical link: https://commits.webkit.org/287876@main
Canonical link: https://commits.webkit.org/283286.599@safari-7620-branch
Commit: 4489b79db747013fbacb4c742c4aee55387f7234
https://github.com/WebKit/WebKit/commit/4489b79db747013fbacb4c742c4aee55387f7234
Author: Jonathan Bedard <jbedard at apple.com>
Date: 2024-12-16 (Mon, 16 Dec 2024)
Changed paths:
M Tools/Scripts/webkitpy/common/system/executive.py
Log Message:
-----------
Cherry-pick 287814 at main (f3b42cb1ebac). rdar://141449707
[webkitpy] Respect webkitcorepy.Timeout in Executive.run_command
https://bugs.webkit.org/show_bug.cgi?id=284648
rdar://141449707
Reviewed by Sam Sneddon.
* Tools/Scripts/webkitpy/common/system/executive.py:
(Executive.run_command): Pass Timeout.difference() to 'wait()' calls.
Canonical link: https://commits.webkit.org/287814@main
Canonical link: https://commits.webkit.org/283286.600@safari-7620-branch
Commit: 16bbd5898352175997dfe8b87e91dd4d22e91bd6
https://github.com/WebKit/WebKit/commit/16bbd5898352175997dfe8b87e91dd4d22e91bd6
Author: Ben Schwartz <ben_schwartz at apple.com>
Date: 2024-12-16 (Mon, 16 Dec 2024)
Changed paths:
M LayoutTests/platform/ios/TestExpectations
Log Message:
-----------
Cherry-pick 287895 at main (4df9e06e4e57). rdar://141555356
[Gardening] [WKTR] imported/w3c/web-platform-tests/screen-orientation/orientation-reading.html is consistently failing, flunking EWS iOS WPT testing.
https://bugs.webkit.org/show_bug.cgi?id=284761
rdar://141555356
Unreviewed test gardening.
Adding "skip" expectation for a layout test that is flunking test runs on EWS.
* LayoutTests/platform/ios/TestExpectations:
Canonical link: https://commits.webkit.org/287895@main
Canonical link: https://commits.webkit.org/283286.601@safari-7620-branch
Commit: 890a3dadda42be471399f96a24bcc617460be50d
https://github.com/WebKit/WebKit/commit/890a3dadda42be471399f96a24bcc617460be50d
Author: Nathan Solomon <nathan_solomon at apple.com>
Date: 2024-12-17 (Tue, 17 Dec 2024)
Changed paths:
A LayoutTests/editing/mac/selection/word-thai-does-not-leak-expected.txt
A LayoutTests/editing/mac/selection/word-thai-does-not-leak.html
M LayoutTests/editing/mac/selection/word-thai.html
M LayoutTests/resources/document-leak-test.js
M Source/WebCore/dom/BoundaryPoint.h
M Source/WebCore/dom/SimpleRange.cpp
M Source/WebCore/dom/SimpleRange.h
M Source/WebCore/page/EventHandler.cpp
M Source/WebCore/page/EventHandler.h
M Source/WebCore/testing/Internals.cpp
Log Message:
-----------
Cherry-pick 72e418d5143c. rdar://141576338
Document Leak occurs in LayoutTests/editing/mac/selection/word-thai.html
https://bugs.webkit.org/show_bug.cgi?id=280688
rdar://137058331
Reviewed by Ryan Reno.
The document leak occurs because the m_dragStartSelection member in
EventHandler, which is of type SimpleRange, holds Refs to Nodes.
This is a problem because the Document holds Refs to these nodes
because the document holds a strong reference to an Editor, which holds a
strong reference to a LocalFrame, which holds a strong reference to an
EventHandler.
This causes a reference cycle to occur between
the Document and the Nodes the EventHandler holds. Fix this reference
cycle by changing the type of m_dragStartSelection to a new type
that allows the member to hold a WeakReference to these nodes. Creating
this new type instead of modifying SimpleRange to hold WeakPtrs to nodes
prevents making extensive changes to areas of the codebase that can
still use a SimpleRange without causing a
reference cycle. Keep the change isolated to what code
relies on accessing m_dragStartSelection's Nodes to prevent adding
extensive amounts of null checking in other areas.
The test I ran to verify the fix was: run-webkit-tests --world-leaks LayoutTests/editing/mac/selection/word-thai.html
This test would previously fail when --world-leaks was passed in.
* Source/WebCore/dom/BoundaryPoint.h:
(WebCore::BoundaryPointWeak::BoundaryPointWeak):
* Source/WebCore/dom/SimpleRange.cpp:
(WebCore::SimpleRangeWeak::SimpleRangeWeak):
(WebCore::firstIntersectingNode):
(WebCore::nodePastLastIntersectingNode):
(WebCore::firstIntersectingNodeWithDeprecatedZeroOffsetStartQuirk):
(WebCore::commonInclusiveAncestor):
(WebCore::IntersectingNodeIterator::IntersectingNodeIterator):
* Source/WebCore/dom/SimpleRange.h:
(WebCore::SimpleRangeWeak::startContainer const):
(WebCore::SimpleRangeWeak::protectedStartContainer const):
(WebCore::SimpleRangeWeak::startOffset const):
(WebCore::SimpleRangeWeak::endContainer const):
(WebCore::SimpleRangeWeak::protectedEndContainer const):
(WebCore::SimpleRangeWeak::endOffset const):
(WebCore::SimpleRangeWeak::collapsed const):
(WebCore::SimpleRange::operator SimpleRangeWeak const):
* Source/WebCore/page/EventHandler.cpp:
(WebCore::EventHandler::updateSelectionForMouseDrag):
* Source/WebCore/page/EventHandler.h:
* Source/WebCore/testing/Internals.cpp:
(WebCore::Internals::treeOrderBoundaryPoints):
Canonical link: https://commits.webkit.org/285629@main
Canonical link: https://commits.webkit.org/283286.602@safari-7620-branch
Commit: 2747c8edf86bcccf85d8f91c16dedeae7f5efeb7
https://github.com/WebKit/WebKit/commit/2747c8edf86bcccf85d8f91c16dedeae7f5efeb7
Author: Wenson Hsieh <wenson_hsieh at apple.com>
Date: 2024-12-17 (Tue, 17 Dec 2024)
Changed paths:
A LayoutTests/editing/caret/ios/place-caret-after-autocorrected-word-expected.txt
A LayoutTests/editing/caret/ios/place-caret-after-autocorrected-word.html
M LayoutTests/resources/ui-helper.js
M Source/WebCore/dom/SimpleRange.h
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm
M Tools/TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl
M Tools/TestRunnerShared/UIScriptContext/UIScriptController.h
M Tools/WebKitTestRunner/ios/UIScriptControllerIOS.h
M Tools/WebKitTestRunner/ios/UIScriptControllerIOS.mm
Log Message:
-----------
Cherry-pick abdb8d25bff5. rdar://141233042
[iOS] [Mail Compose] Unable to tap to put text cursor at end of line if last word was autocorrected
https://bugs.webkit.org/show_bug.cgi?id=283304
rdar://129961069
Reviewed by Abrar Rahman Protyasha and Richard Robinson.
Currently, it's possible to get stuck in a state where you can't move the text cursor to the end of
a line by tapping after the end of the word, if the last word on the line was autocorrected. This is
because UIKit's text interaction tap gesture tells us to `-selectWordForReplacement` when tapping
after the end of the autocorrected word, which we (currently) always honor.
To mitigate this, we prevent the same autocorrected word range from being selected multiple times in
a row, as long as the selection is still inside of the word range. This allows the user to toggle
between selecting the autocorrected word and setting the selection to the end of the line, which
matches platform behavior in Notes.
* LayoutTests/editing/caret/ios/place-caret-after-autocorrected-word-expected.txt: Added.
* LayoutTests/editing/caret/ios/place-caret-after-autocorrected-word.html: Added.
Add a new layout test to exercise this change, by calling into `-selectWordForReplacement` from a
new testing hook. I couldn't reliably get UIKit's text interactions to exhibit this same behavior in
a testing environment purely by tapping to set the selection, but we can still simulate UIKit
behavior at the API boundary using this approach.
* LayoutTests/resources/ui-helper.js:
(window.UIHelper.selectWordForReplacement):
(window.UIHelper.applyAutocorrection):
Add an `underline` argument to this testing helper, to determine whether or not we should add blue
autocorrection underlines.
* Source/WebCore/dom/SimpleRange.h:
(WebCore::makeBoundaryPointHelper):
(WebCore::makeSimpleRangeHelper):
(WebCore::makeSimpleRange):
Add a helper method to convert from `WeakSimpleRange` to `std::optional<SimpleRange>`. This returns
`nullopt` if either of the boundary points are invalidated.
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::didChangeSelection):
(WebKit::WebPage::didCommitLoad):
* Source/WebKit/WebProcess/WebPage/WebPage.h:
* Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::WebPage::extendSelectionForReplacement):
See above for more details.
(WebKit::WebPage::resetLastSelectedReplacementRangeIfNeeded):
Clear out `m_lastSelectedReplacementRange` when the selection moves outside of the range.
* Tools/TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl:
* Tools/TestRunnerShared/UIScriptContext/UIScriptController.h:
(WTR::UIScriptController::selectWordForReplacement):
(WTR::UIScriptController::applyAutocorrection):
* Tools/WebKitTestRunner/ios/UIScriptControllerIOS.h:
* Tools/WebKitTestRunner/ios/UIScriptControllerIOS.mm:
(WTR::UIScriptControllerIOS::selectWordForReplacement):
(WTR::UIScriptControllerIOS::applyAutocorrection):
Canonical link: https://commits.webkit.org/286757@main
Canonical link: https://commits.webkit.org/283286.603@safari-7620-branch
Compare: https://github.com/WebKit/WebKit/compare/26c90c797c07...2747c8edf86b
To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications
More information about the webkit-changes
mailing list