https://bugs.webkit.org/show_bug.cgi?id=229323
Reviewed by John Wilander.
Source/WebKit:
This allows me to run the UIEventAttribution tests on macOS.
It also makes them not time out, which they were doing since r277447.
To accomplish this, I added more test SPI to prevent the network process
suspension message, which was causing the test to time out on the iOS simulator.
* UIProcess/API/Cocoa/WKWebViewPrivateForTesting.h:
* UIProcess/API/Cocoa/WKWebViewTesting.mm:
(-[WKWebView _addEventAttributionWithSourceID:destinationURL:sourceDescription:purchaser:reportEndpoint:optionalNonce:]):
* UIProcess/API/Cocoa/WKWebsiteDataStore.mm:
(+[WKWebsiteDataStore _preventNetworkProcessSuspensionForTesting]):
* UIProcess/API/Cocoa/WKWebsiteDataStorePrivate.h:
* UIProcess/API/ios/WKWebViewPrivateForTestingIOS.h:
* UIProcess/API/ios/WKWebViewTestingIOS.mm:
(-[WKWebView _setUIEventAttributionForTesting:withNonce:]): Deleted.
* UIProcess/Network/NetworkProcessProxy.cpp:
(WebKit::NetworkProcessProxy::preventSuspensionForTesting):
(WebKit::NetworkProcessProxy::sendPrepareToSuspend):
* UIProcess/Network/NetworkProcessProxy.h:
Tools:
* TestWebKitAPI/Tests/WebKitCocoa/EventAttribution.mm:
(TestWebKitAPI::exampleURL):
(TestWebKitAPI::runBasicEventAttributionTest):
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/240764@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@281349 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=229139
Patch by Carlos Garcia Campos <cgarcia@igalia.com> on 2021-08-19
Reviewed by Adrian Perez de Castro.
Source/WebCore:
We are always claiming to be focused when the document in the active window even if the page is not actually
focused.
* dom/Document.cpp:
(WebCore::Document::hasFocus const): Check also that page is focused.
Tools:
Add a unit tests to check document.hasFocus() returns false when a web view is in the active window, but not focused.
* TestWebKitAPI/Tests/WebKitCocoa/_WKWebAuthenticationPanel.mm:
(TestWebKitAPI::TEST): Ensure web view is focused as required by credentials container.
* TestWebKitAPI/Tests/WebKitGLib/TestWebKitWebView.cpp:
(testWebViewDocumentFocus):
(beforeAll):
* TestWebKitAPI/cocoa/TestWKWebView.h:
* TestWebKitAPI/cocoa/TestWKWebView.mm:
(-[TestWKWebView focus]):
Canonical link: https://commits.webkit.org/240665@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@281228 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=229174
Reviewed by Carlos Garcia Campos.
r281079 changed the helper method waitUntilTitleChangedTo to
immediately return if the current title is already the expected one.
While this is working fine in other tests, the deviceidhashsalt tries
to load the same page twice. As the title does not change, the call
returns right away, before the expected side effects of the load
happen.
This commit adds a dummy "about:blank" call between both original
calls to make sure we track the title change correctly.
* TestWebKitAPI/Tests/WebKitGLib/TestWebsiteData.cpp:
(testWebsiteDataDeviceIdHashSalt):
Canonical link: https://commits.webkit.org/240583@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@281129 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=229018
Reviewed by Geoffrey Garen.
Source/WTF:
Introduce CanMakeThreadSafeCheckedPtr which is a thread safe version of CanMakeCheckedPtr.
* wtf/CheckedRef.h:
(WTF::CanMakeCheckedPtrBase): Extracted from CanMakeCheckedPtr.
(WTF::CanMakeCheckedPtrBase::~CanMakeCheckedPtrBase):
(WTF::CanMakeCheckedPtrBase::ptrCount const):
(WTF::SingleThreadIntegralWrapper): Added.
(WTF::SingleThreadIntegralWrapper::SingleThreadIntegralWrapper):
(WTF::SingleThreadIntegralWrapper::operator IntegralType const):
(WTF::SingleThreadIntegralWrapper::operator! const):
(WTF::SingleThreadIntegralWrapper::operator++):
(WTF::SingleThreadIntegralWrapper::operator--):
(WTF::SingleThreadIntegralWrapper::assertThread const):
(WTF::CanMakeCheckedPtr): Redefined using CanMakeCheckedPtrBase and SimpleNonAtomicType.
(WTF::CanMakeThreadSafeCheckedPtr): Added.
Tools:
Added a unit test for CanMakeThreadSafeCheckedPtr
* TestWebKitAPI/Tests/WTF/CheckedPtr.cpp:
(TestWebKitAPI.ThreadSafeCheckedPtrObject)
(WTF_CheckedPtr.CanMakeThreadSafeCheckedPtr): Added.
Canonical link: https://commits.webkit.org/240564@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@281105 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=214804
Reviewed by Adrian Perez de Castro.
Do not wait for title change if the title already changed.
* TestWebKitAPI/Tests/WebKitGLib/TestWebKitWebView.cpp:
(testWebViewPageVisibility):
* TestWebKitAPI/glib/TestExpectations.json:
* TestWebKitAPI/glib/WebKitGLib/WebViewTest.cpp:
(WebViewTest::waitUntilTitleChangedTo):
(WebViewTest::waitUntilTitleChanged):
Canonical link: https://commits.webkit.org/240539@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@281079 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228227
Reviewed by Carlos Garcia Campos.
Source/WebKit:
Added webkit_website_data_manager_set_memory_pressure_settings() API function to pass a
WebKitMemoryPressureSettings instance as the settings to use by all the network processes.
* NetworkProcess/NetworkProcessCreationParameters.cpp:
(WebKit::NetworkProcessCreationParameters::encode const):
(WebKit::NetworkProcessCreationParameters::decode):
* NetworkProcess/NetworkProcessCreationParameters.h:
* NetworkProcess/soup/NetworkProcessSoup.cpp:
(WebKit::NetworkProcess::platformInitializeNetworkProcess):
* UIProcess/API/glib/WebKitMemoryPressureSettings.cpp:
* UIProcess/API/glib/WebKitWebsiteDataManager.cpp:
(webkit_website_data_manager_set_memory_pressure_settings):
* UIProcess/API/gtk/WebKitWebsiteDataManager.h:
* UIProcess/API/gtk/docs/webkit2gtk-4.0-sections.txt:
* UIProcess/API/wpe/WebKitWebsiteDataManager.h:
* UIProcess/API/wpe/docs/wpe-1.0-sections.txt:
* UIProcess/Network/NetworkProcessProxy.cpp:
(WebKit::NetworkProcessProxy::didExceedMemoryLimit):
* UIProcess/Network/NetworkProcessProxy.h:
* UIProcess/Network/NetworkProcessProxy.messages.in:
* UIProcess/WebProcessPool.h:
* UIProcess/soup/WebProcessPoolSoup.cpp:
(WebKit::memoryPressureMonitorDisabled):
(WebKit::WebProcessPool::platformInitializeNetworkProcess):
Source/WTF:
Added a new method to MemoryPressureHandler to set the configuration by copying the parameter
instead of moving it.
* wtf/MemoryPressureHandler.h:
(WTF::MemoryPressureHandler::setConfiguration):
Tools:
Added an API test for webkit_website_data_manager_set_memory_pressure_settings().
* TestWebKitAPI/Tests/WebKitGLib/TestWebsiteData.cpp:
(MemoryPressureTest::setup):
(MemoryPressureTest::teardown):
(MemoryPressureTest::loadFailedCallback):
(MemoryPressureTest::waitUntilLoadFailed):
(testMemoryPressureSettings):
(beforeAll):
Canonical link: https://commits.webkit.org/240531@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@281070 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=229013
<rdar://problem/81215696>
Reviewed by Timothy Hatcher.
Source/WebCore:
`NSAttributedString` now uses WK2, which has caused us to discover some inconsistencies (and bugs).
Tests: NSAttributedStringWebKitAdditions.DefaultFontSize
NSAttributedStringWebKitAdditions.MultipleParagraphs
* editing/cocoa/HTMLConverter.mm:
(HTMLConverter::_blockLevelElementForNode):
Check the given node before looking at the parent as it could already be a block. This
allows for sequental `<p>` to each have their own positioning instead of only the first one.
(HTMLConverter::computedAttributesForElement):
Fix typo that used `margin-right` instead of `margin-bottom` when setting `paragraphSpacing`.
Source/WebKit:
`NSAttributedString` now uses WK2, which has caused us to discover some inconsistencies (and bugs).
* UIProcess/API/Cocoa/NSAttributedString.mm:
(+[_WKAttributedStringWebViewCache configuration]):
Change the default font size to 12 to match WK1.
Tools:
* TestWebKitAPI/Tests/WebKitCocoa/NSAttributedStringWebKitAdditions.mm: Added.
(TEST.NSAttributedStringWebKitAdditions.DefaultFontSize):
(TEST.NSAttributedStringWebKitAdditions.MultipleParagraphs):
* TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
Canonical link: https://commits.webkit.org/240477@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280973 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=229032
Reviewed by Michael Catanzaro.
We don't really need to have a different process to test a11y. We can remove AccessibilityTestServer and use the
same test executable. That way we don't need to spawn a process and use DBus for the communication.
* TestWebKitAPI/Tests/WebKitGtk/AccessibilityTestServer.cpp: Removed.
* TestWebKitAPI/Tests/WebKitGtk/TestWebKitAccessibility.cpp:
(AccessibilityTest::findTestApplication): Find the accessible application corresponding to the test executable.
(AccessibilityTest::waitUntilChildrenRemoved): Use the WebViewTest main loop.
(testAtspiBasicHierarchy): Use WebViewTest::loadHtml.
* TestWebKitAPI/glib/PlatformGTK.cmake:
* TestWebKitAPI/glib/WebKitGLib/TestMain.cpp:
(main): Set the program name to the executable name. It helps to a11y test to find the accessible app.
Canonical link: https://commits.webkit.org/240472@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280966 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228754
Reviewed by Alex Christensen.
LayoutTests/imported/w3c:
Rebaseline COEP WPT tests now that we are passing more checks.
* web-platform-tests/html/cross-origin-embedder-policy/blob.https-expected.txt:
* web-platform-tests/html/cross-origin-embedder-policy/coep-frame-javascript.https-expected.txt:
* web-platform-tests/html/cross-origin-embedder-policy/coep-on-response-from-service-worker.https-expected.txt:
* web-platform-tests/html/cross-origin-embedder-policy/credentialless/iframe-coep-require-corp.tentative.https-expected.txt:
* web-platform-tests/html/cross-origin-embedder-policy/cross-origin-isolated-permission.https-expected.txt:
* web-platform-tests/html/cross-origin-embedder-policy/data.https-expected.txt:
* web-platform-tests/html/cross-origin-embedder-policy/dedicated-worker-cache-storage.https-expected.txt:
* web-platform-tests/html/cross-origin-embedder-policy/dedicated-worker.https-expected.txt:
* web-platform-tests/html/cross-origin-embedder-policy/header-parsing.https-expected.txt:
* web-platform-tests/html/cross-origin-embedder-policy/javascript.https-expected.txt:
* web-platform-tests/html/cross-origin-embedder-policy/multi-globals/workers-coep-report.https-expected.txt:
* web-platform-tests/html/cross-origin-embedder-policy/no-secure-context-expected.txt:
* web-platform-tests/html/cross-origin-embedder-policy/none-sw-from-require-corp.https-expected.txt:
* web-platform-tests/html/cross-origin-embedder-policy/none.https-expected.txt:
* web-platform-tests/html/cross-origin-embedder-policy/reporting-to-endpoint.https-expected.txt:
* web-platform-tests/html/cross-origin-embedder-policy/require-corp-about-blank-expected.txt: Removed.
* web-platform-tests/html/cross-origin-embedder-policy/require-corp-about-blank.https-expected.txt:
* web-platform-tests/html/cross-origin-embedder-policy/require-corp-about-srcdoc-expected.txt: Removed.
* web-platform-tests/html/cross-origin-embedder-policy/require-corp-about-srcdoc.https-expected.txt:
* web-platform-tests/html/cross-origin-embedder-policy/require-corp-load-from-cache-storage.https-expected.txt:
* web-platform-tests/html/cross-origin-embedder-policy/require-corp-sw-from-none.https-expected.txt:
* web-platform-tests/html/cross-origin-embedder-policy/require-corp-sw-from-require-corp.https-expected.txt:
* web-platform-tests/html/cross-origin-embedder-policy/require-corp-sw.https-expected.txt:
* web-platform-tests/html/cross-origin-embedder-policy/require-corp.https-expected.txt:
* web-platform-tests/html/cross-origin-embedder-policy/sandbox.https-expected.txt:
* web-platform-tests/html/cross-origin-embedder-policy/service-worker-cache-storage.https-expected.txt:
* web-platform-tests/html/cross-origin-embedder-policy/srcdoc.https-expected.txt:
Source/WebCore:
Add initial support for Cross-Origin-Embedder-Policy (COEP) behind a runtime feature flag, off by default:
- https://html.spec.whatwg.org/multipage/origin.html#coep
The COEP header has the following impacts:
- When a document with `Cross-Origin-Embedder-Policy: require-corp` loads an iframe or a worker script, if the network
response for that iframe doesn't also contain `Cross-Origin-Embedder-Policy: require-corp`, then we fail the load.
- When a document with `Cross-Origin-Embedder-Policy: require-corp` loads cross-origin subresources, then either CORS
must be used or the resource response must be allowed by Cross-Origin-Resource-Policy (CORP) header.
Support is only for WK2 and checks are done in the network process for better security. Support for workers and service
workers (including cache storage) is included.
Most of the Web-Platform-Tests for COEP are passing with this patch. The exceptions are:
- Some tests relying on Blob are failing. Similarly to COOP, Blobs need to inherit COEP from their
creator. This is currently unimplemented as the change will likely be non-trivial. I will follow-up
to fix Blob support for both COOP and COEP.
- Tests in the credentialless/ folder are failing because we do not support `Cross-Origin-Embedder-Policy: credentialless`.
This seems to be a fairly recent extension proposed by Google and it is not part of the HTML specification yet.
- Some tests expect violation reporting and they are failing and we do not implement reporting yet.
Note that `self.crossOriginIsolated` still returns false, even if the pages opts into both COOP & COEP, and APIs such
as SharedArrayBuffer still are not permitted to use. In order to support this, we will have to actually implement process
swapping so that we know a process is not actually shared by several origins.
Test: http/wpt/html/cross-origin-embedder-policy/require-corp.https.html
* Modules/cache/DOMCache.cpp:
(WebCore::DOMCache::queryCache):
* Modules/cache/DOMCacheEngine.cpp:
(WebCore::DOMCacheEngine::convertToException):
* Modules/cache/DOMCacheEngine.h:
* Modules/cache/RetrieveRecordsOptions.h:
(WebCore::RetrieveRecordsOptions::isolatedCopy const):
(WebCore::RetrieveRecordsOptions::encode const):
(WebCore::RetrieveRecordsOptions::decode):
* dom/Document.cpp:
(WebCore::Document::initSecurityContext):
* dom/SecurityContext.h:
(WebCore::SecurityContext::crossOriginEmbedderPolicy const):
(WebCore::SecurityContext::setCrossOriginEmbedderPolicy):
* loader/CrossOriginAccessControl.cpp:
(WebCore::shouldCrossOriginResourcePolicyCancelLoad):
(WebCore::validateCrossOriginResourcePolicy):
* loader/CrossOriginAccessControl.h:
* loader/CrossOriginEmbedderPolicy.cpp:
(WebCore::obtainCrossOriginEmbedderPolicy):
(WebCore::CrossOriginEmbedderPolicy::isolatedCopy const):
* loader/CrossOriginEmbedderPolicy.h:
(WebCore::CrossOriginEmbedderPolicy::encode const):
(WebCore::CrossOriginEmbedderPolicy::decode):
* loader/CrossOriginOpenerPolicy.cpp:
(WebCore::obtainCrossOriginOpenerPolicy):
* loader/DocumentThreadableLoader.cpp:
(WebCore::DocumentThreadableLoader::loadResourceSynchronously):
(WebCore::DocumentThreadableLoader::create):
(WebCore::DocumentThreadableLoader::DocumentThreadableLoader):
(WebCore::DocumentThreadableLoader::crossOriginEmbedderPolicy const):
* loader/DocumentThreadableLoader.h:
* loader/DocumentWriter.cpp:
(WebCore::DocumentWriter::begin):
* loader/FrameLoader.cpp:
(WebCore::FrameLoader::didBeginDocument):
* loader/ResourceLoaderOptions.h:
* loader/WorkerThreadableLoader.cpp:
(WebCore::WorkerThreadableLoader::MainThreadBridge::MainThreadBridge):
* loader/cache/CachedResourceLoader.cpp:
(WebCore::CachedResourceLoader::requestResource):
* page/SecurityOrigin.h:
* platform/network/HTTPParsers.cpp:
(WebCore::parseCrossOriginResourcePolicyHeader):
* platform/network/HTTPParsers.h:
* workers/Worker.cpp:
(WebCore::Worker::notifyFinished):
* workers/WorkerGlobalScope.cpp:
(WebCore::WorkerGlobalScope::WorkerGlobalScope):
* workers/WorkerGlobalScopeProxy.h:
* workers/WorkerMessagingProxy.cpp:
(WebCore::WorkerMessagingProxy::startWorkerGlobalScope):
* workers/WorkerMessagingProxy.h:
* workers/WorkerScriptLoader.cpp:
(WebCore::WorkerScriptLoader::loadSynchronously):
(WebCore::WorkerScriptLoader::loadAsynchronously):
(WebCore::WorkerScriptLoader::didReceiveResponse):
* workers/WorkerScriptLoader.h:
(WebCore::WorkerScriptLoader::crossOriginEmbedderPolicy const):
* workers/WorkerThread.cpp:
(WebCore::WorkerParameters::isolatedCopy const):
* workers/WorkerThread.h:
* workers/service/ServiceWorkerContainer.cpp:
(WebCore::ServiceWorkerContainer::jobFinishedLoadingScript):
* workers/service/ServiceWorkerContainer.h:
* workers/service/ServiceWorkerContextData.cpp:
(WebCore::ServiceWorkerContextData::isolatedCopy const):
* workers/service/ServiceWorkerContextData.h:
(WebCore::ServiceWorkerContextData::encode const):
(WebCore::ServiceWorkerContextData::decode):
* workers/service/ServiceWorkerFetchResult.h:
(WebCore::ServiceWorkerFetchResult::isolatedCopy const):
(WebCore::serviceWorkerFetchError):
(WebCore::ServiceWorkerFetchResult::encode const):
(WebCore::ServiceWorkerFetchResult::decode):
* workers/service/ServiceWorkerJob.cpp:
(WebCore::ServiceWorkerJob::notifyFinished):
* workers/service/ServiceWorkerJobClient.h:
* workers/service/context/ServiceWorkerThread.cpp:
(WebCore::ServiceWorkerThread::ServiceWorkerThread):
* workers/service/server/RegistrationDatabase.cpp:
(WebCore::RegistrationDatabase::doPushChanges):
(WebCore::RegistrationDatabase::importRecords):
* workers/service/server/SWServer.cpp:
(WebCore::SWServer::addRegistrationFromStore):
(WebCore::SWServer::updateWorker):
(WebCore::SWServer::installContextData):
* workers/service/server/SWServer.h:
* workers/service/server/SWServerJobQueue.cpp:
(WebCore::SWServerJobQueue::scriptFetchFinished):
* workers/service/server/SWServerWorker.cpp:
(WebCore::SWServerWorker::SWServerWorker):
(WebCore::SWServerWorker::contextData const):
* workers/service/server/SWServerWorker.h:
Source/WebKit:
As mentioned in the WebCore changelog, we do all the COEP checks in the network process
instead of WebCore for added security. As a result, we need to pass more information
to the network process when doing loads in order to do those checks. The checks are done
in NetworkResourceLoader for navigations & worker script loads (similarly to CSP,
X-FrameOptions) and in NetworkLoadChecker for CORP checks of subresource loads (similarly
to CORS checks).
* NetworkProcess/NetworkLoadChecker.cpp:
(WebKit::NetworkLoadChecker::NetworkLoadChecker):
(WebKit::NetworkLoadChecker::validateResponse):
* NetworkProcess/NetworkLoadChecker.h:
(WebKit::NetworkLoadChecker::setParentCrossOriginEmbedderPolicy):
(WebKit::NetworkLoadChecker::setCrossOriginEmbedderPolicy):
* NetworkProcess/NetworkResourceLoadParameters.cpp:
(WebKit::NetworkResourceLoadParameters::parentOrigin const):
(WebKit::NetworkResourceLoadParameters::encode const):
(WebKit::NetworkResourceLoadParameters::decode):
* NetworkProcess/NetworkResourceLoadParameters.h:
* NetworkProcess/NetworkResourceLoader.cpp:
(WebKit::NetworkResourceLoader::shouldInterruptLoadForCSPFrameAncestorsOrXFrameOptions):
(WebKit::NetworkResourceLoader::shouldInterruptNavigationForCrossOriginEmbedderPolicy):
(WebKit::NetworkResourceLoader::shouldInterruptWorkerLoadForCrossOriginEmbedderPolicy):
(WebKit::NetworkResourceLoader::didReceiveResponse):
(WebKit::NetworkResourceLoader::willSendRedirectedRequest):
* NetworkProcess/NetworkResourceLoader.h:
* NetworkProcess/PingLoad.cpp:
(WebKit::PingLoad::PingLoad):
(WebKit::PingLoad::initialize):
* NetworkProcess/ServiceWorker/ServiceWorkerFetchTask.cpp:
(WebKit::ServiceWorkerFetchTask::didReceiveResponse):
* NetworkProcess/ServiceWorker/ServiceWorkerSoftUpdateLoader.cpp:
(WebKit::ServiceWorkerSoftUpdateLoader::processResponse):
(WebKit::ServiceWorkerSoftUpdateLoader::didFinishLoading):
* NetworkProcess/ServiceWorker/ServiceWorkerSoftUpdateLoader.h:
* NetworkProcess/cache/CacheStorageEngineCache.cpp:
(WebKit::CacheStorage::Cache::retrieveRecords):
* WebProcess/Network/WebLoaderStrategy.cpp:
(WebKit::addParametersShared):
(WebKit::WebLoaderStrategy::scheduleLoadFromNetworkProcess):
Source/WTF:
Add experimental feature flag for Cross-Origin-Embedder-Policy (COEP), off by default.
* Scripts/Preferences/WebPreferencesExperimental.yaml:
LayoutTests:
Update test expectations now that we support COEP on WK2.
* TestExpectations:
* http/wpt/html/cross-origin-embedder-policy/require-corp.https-expected.txt: Added.
* http/wpt/html/cross-origin-embedder-policy/require-corp.https.html: Added.
* http/wpt/html/cross-origin-embedder-policy/require-corp.https.html.headers: Added.
* platform/mac-wk1/TestExpectations:
* platform/win/TestExpectations:
Canonical link: https://commits.webkit.org/240459@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280953 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=227728
<rdar://problem/80237464>
Reviewed by Jer Noble.
Source/WebKit:
After the GPU process crashes, the UI process will clean up the
`SharedRoutingArbitrator`, while a WebContent process might be resuming
the media playback and setup `AudioSessionRoutingArbitrator`.
There is a race condition here. If the WebContent process runs faster,
`SharedRoutingArbitrator` in the UI process will try to begin a duplicated
routing arbitration and lead to an assertion failure.
No new tests. Fixed following two API test failures:
- TestWebKitAPI.WebKit2.CrashGPUProcessWhileCapturing
- TestWebKitAPI.GPUProcess.CrashWhilePlayingAudioViaCreateMediaElementSource
* UIProcess/Media/cocoa/AudioSessionRoutingArbitratorProxyCocoa.mm:
(WebKit::AudioSessionRoutingArbitratorProxy::processDidTerminate):
* WebProcess/GPU/GPUProcessConnection.cpp:
(WebKit::GPUProcessConnection::didClose):
Tools:
* TestWebKitAPI/Tests/WebKitCocoa/GPUProcess.mm:
(TEST):
Canonical link: https://commits.webkit.org/240457@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280951 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228955
Source/WebCore:
Reviewed by Eric Carlson.
In case video element is autoplayable but is paused, we should try to autoplay even if we are not interrupted due to invisible autoplay.
Covered by API test.
* html/HTMLMediaElement.cpp:
(WebCore::HTMLMediaElement::updateShouldAutoplay):
Tools:
rdar://81751653
Reviewed by Eric Carlson.
* TestWebKitAPI/Tests/WebKit/GetUserMedia.mm:
Canonical link: https://commits.webkit.org/240440@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280920 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228939
<rdar://problem/80427578>
Reviewed by Eric Carlson.
Source/WebCore:
Test: VideoControlsManager.VideoControlsManagerDoesNotChangeValuesExposedToJavaScript
* platform/mac/PlaybackSessionInterfaceMac.mm:
(WebCore::PlaybackSessionInterfaceMac::rateChanged):
Make sure to change the `defaultPlaybackRate` before the `rate` as otherwise the former will
override changes made to the latter (see r278850 (and r277203) for details as to why).
* platform/mac/WebPlaybackControlsManager.h:
* platform/mac/WebPlaybackControlsManager.mm:
(-[WebPlaybackControlsManager setDefaultPlaybackRate:]):
(-[WebPlaybackControlsManager setDefaultPlaybackRate:fromJavaScript:]): Added.
(-[WebPlaybackControlsManager setRate:]):
(-[WebPlaybackControlsManager setRate:fromJavaScript:]): Added.
Add a way to distinguish whether the change to the `rate`/`defaultPlaybackRate` came from JS
or some native call (e.g. AVKit). If the former, don't propagate the change to the playback
model (which eventually is the `HTMLMediaElement` in the WebProcess) as that's where the
value came from in the first place. Note that we still want to propagate the `rate` to the
`defaultPlaybackRate` (and vice versa when `isPlaying`) in the UIProcess for the reasons
described in r278850 (and r277203), but we don't want to expose it to JS.
* platform/ios/PlaybackSessionInterfaceAVKit.mm:
(WebCore::PlaybackSessionInterfaceAVKit::rateChanged):
* platform/ios/WebAVPlayerController.h:
* platform/ios/WebAVPlayerController.mm:
(-[WebAVPlayerController setDefaultPlaybackRate:]):
(-[WebAVPlayerController setDefaultPlaybackRate:fromJavaScript:]): Added.
(-[WebAVPlayerController setRate:]):
(-[WebAVPlayerController setRate:fromJavaScript:]): Added.
Drive-by: r278850 was based r277203 (which added the above), so fix that code now too.
Tools:
* TestWebKitAPI/Tests/WebKitCocoa/VideoControlsManager.mm:
(TestWebKitAPI::TEST.VideoControlsManager.VideoControlsManagerDoesNotChangeValuesExposedToJavaScript): Added.
Canonical link: https://commits.webkit.org/240391@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280840 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228848
<rdar://problem/81587448>
Reviewed by Brent Fulgham.
Source/WebKit:
Drive by logging fix.
* UIProcess/WebProcessProxy.cpp:
(WebKit::WebProcessProxy::fetchWebsiteData):
(WebKit::WebProcessProxy::deleteWebsiteData):
Tools:
Update LoadWebArchive.FailNavigation1 to test the case of a webarchive
being loaded with a host for better test coverage.
* TestWebKitAPI/Tests/mac/load-web-archive-1.html:
Canonical link: https://commits.webkit.org/240302@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280706 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228589
Reviewed by Jer Noble.
Source/WebCore:
When "Media in GPU Process" is enabled, `AudioSession[IOS|Mac]` runs in
the GPU process. `HTMLMediaElement`, which is an observer of audio session,
runs in a WebContent process. It cannot get its AudioSession's configuration
directly. We need a mechanism to "push" the latest audio session configuration
from the GPU process to the WebContent process.
This patch replaces the `MutedStateObserver` with an audio session configuration
change observer interface, so that an audio session will notify its observers
after changing its configurations, including buffer size, muted state, sample rate.
Currently, this observer interface is used on macOS only.
No new tests. Fix an API test failure.
* html/HTMLMediaElement.cpp:
(WebCore::HTMLMediaElement::initializeMediaSession):
(WebCore::HTMLMediaElement::~HTMLMediaElement):
(WebCore::HTMLMediaElement::hardwareMutedStateDidChange):
* html/HTMLMediaElement.h:
* platform/audio/AudioSession.cpp:
(WebCore::AudioSession::addConfigurationChangeObserver):
(WebCore::AudioSession::removeConfigurationChangeObserver):
* platform/audio/AudioSession.h:
* platform/audio/ios/AudioSessionIOS.h:
Move `m_interruptionObservers` to this class because only `AudioSessionIOS`
supports interruption observers.
* platform/audio/mac/AudioSessionMac.h:
* platform/audio/mac/AudioSessionMac.mm:
(WebCore::AudioSessionMac::handleSampleRateChange):
(WebCore::AudioSessionMac::handleSampleRateChange const):
(WebCore::AudioSessionMac::handleBufferSizeChange):
(WebCore::AudioSessionMac::handleBufferSizeChange const):
(WebCore::AudioSessionMac::sampleRate const):
(WebCore::AudioSessionMac::setPreferredBufferSize):
(WebCore::AudioSessionMac::handleMutedStateChange):
(WebCore::AudioSessionMac::addConfigurationChangeObserver):
(WebCore::AudioSessionMac::removeConfigurationChangeObserver):
(WebCore::AudioSessionMac::addMutedStateObserver): Deleted.
(WebCore::AudioSessionMac::removeMutedStateObserver): Deleted.
Source/WebKit:
When an audio session's configuration changes, let `RemoteAudioSessionProxy`
in the GPU process send the latest audio session configuration to `RemoteAudioSession`
in the WebContent process through an IPC message (`RemoteAudioSession::ConfigurationChanged`).
* GPUProcess/media/RemoteAudioSessionProxy.cpp:
(WebKit::RemoteAudioSessionProxy::configurationChanged):
* GPUProcess/media/RemoteAudioSessionProxy.h:
* GPUProcess/media/RemoteAudioSessionProxyManager.cpp:
(WebKit::RemoteAudioSessionProxyManager::RemoteAudioSessionProxyManager):
(WebKit::RemoteAudioSessionProxyManager::~RemoteAudioSessionProxyManager):
(WebKit::RemoteAudioSessionProxyManager::beginAudioSessionInterruption):
(WebKit::RemoteAudioSessionProxyManager::endAudioSessionInterruption):
(WebKit::RemoteAudioSessionProxyManager::hardwareMutedStateDidChange):
(WebKit::RemoteAudioSessionProxyManager::bufferSizeDidChange):
(WebKit::RemoteAudioSessionProxyManager::sampleRateDidChange):
(WebKit::RemoteAudioSessionProxyManager::configurationDidChange):
* GPUProcess/media/RemoteAudioSessionProxyManager.h:
* WebProcess/GPU/media/RemoteAudioSession.cpp:
(WebKit::RemoteAudioSession::addConfigurationChangeObserver):
(WebKit::RemoteAudioSession::removeConfigurationChangeObserver):
(WebKit::RemoteAudioSession::configurationChanged):
* WebProcess/GPU/media/RemoteAudioSession.h:
* WebProcess/GPU/media/RemoteAudioSession.messages.in:
Tools:
* TestWebKitAPI/Tests/WebKitCocoa/AudioBufferSize.mm:
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/240270@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280664 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228766
Reviewed by Simon Fraser.
Source/WTF:
Instead of using -[NSArray description], which puts its output on multiple lines,
instead use the same formatting as WTF::Vector, which puts its output on a single line.
We can also use this opportunity to tweak the implementation of operator<<(id) to
allow it to be called with Core Foundation types in raw C++ code.
* wtf/text/TextStream.h:
* wtf/text/cocoa/TextStreamCocoa.mm:
(WTF::TextStream::operator<<):
Tools:
* TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* TestWebKitAPI/Tests/WTF/cocoa/TextStreamCocoa.cpp: Added.
(TEST):
* TestWebKitAPI/Tests/WTF/cocoa/TextStreamCocoa.mm: Added.
(TEST):
Canonical link: https://commits.webkit.org/240262@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280651 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228720
Reviewed by Jer Noble.
Source/WebKit:
`RemoteAudioSession` should update its `preferredBufferSize` in
`setPreferredBufferSize()`. Otherwise, the `preferredBufferSize`
will become inconsistent with the value in the GPU process.
No new tests. Fix API test failures.
* WebProcess/GPU/media/RemoteAudioSession.cpp:
(WebKit::RemoteAudioSession::setPreferredBufferSize):
Tools:
* TestWebKitAPI/Tests/WebKitCocoa/PreferredAudioBufferSize.mm:
(TEST_F):
Canonical link: https://commits.webkit.org/240198@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280576 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228717
<rdar://79909343>
Reviewed by Chris Dumez.
Source/WebKit:
r278737 fixed a compatibility bug from r272469 but introduced a crash when the base URL does not successfully parse.
r279450 fixed that crash but introduced a new behavior change that changes the URL to about:blank. This didn't seem
to change anything because window.location is about:blank with and without the change, but WKWebView.URL did change,
which broke at least one app. This undoes the functionality change from r279450 and keeps the crash fix, which are
both covered by API tests. I also manually verified this fixes the app in the radar.
* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::loadData):
Tools:
* TestWebKitAPI/Tests/WebKitCocoa/LoadAlternateHTMLString.mm:
(TEST):
Canonical link: https://commits.webkit.org/240186@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280562 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=227164
Reviewed by Geoffrey Garen.
Source/WTF:
Like r278344, this patch introduces a new type of smart pointer, CheckedRef,
which lets each object keep track of pointers pointing to the object.
As with CheckedPtr, the purpose of the internal counter for CheckedRef is
to release assert that there is no outstanding pointer at the time of destruction
instead of keeping the object alive when there is one.
This patch also removes makeCheckedPtr in favor of using CheckedPtr with
template argument deduction in C++17.
* WTF.xcodeproj/project.pbxproj:
* wtf/CMakeLists.txt:
* wtf/CheckedPtr.h:
(WTF::CheckedPtr::CheckedPtr): Added variants which take CheckedRef as arguments.
(WTF::makeCheckedPtr): Deleted.
(WTF::CanMakeCheckedPtr): Moved to CheckedRef.h
* wtf/CheckedRef.h: Added.
(WTF::CheckedRef::~CheckedRef): Added.
(WTF::CheckedRef::CheckedRef): Added.
(WTF::CheckedRef::isHashTableDeletedValue const): Added.
(WTF::CheckedRef::isHashTableEmptyValue const): Added.
(WTF::CheckedRef::hashTableEmptyValue): Added.
(WTF::CheckedRef::ptrAllowingHashTableEmptyValue const): Added.
(WTF::CheckedRef::ptrAllowingHashTableEmptyValue): Added.
(WTF::CheckedRef::ptr const): Added.
(WTF::CheckedRef::ptr): Added.
(WTF::CheckedRef::get const): Added.
(WTF::CheckedRef::get): Added.
(WTF::CheckedRef::operator-> const): Added.
(WTF::CheckedRef::operator->): Added.
(WTF::CheckedRef::operator const T& const): Added.
(WTF::CheckedRef::operator T&): Added.
(WTF::CheckedRef::operator! const): Added.
(WTF::CheckedRef::operator=): Added.
(WTF::CheckedRef::releasePtr): Added. Returns m_ptr without calling decrementPtrCount.
This is equivalent of leakPtr in Ref but we don't call this that since CheckedRef or
CheckedPtr is generally not used to manage the object lifetime.
(WTF::CheckedRef::poison): Added.
(WTF::CheckedRef::unpoison): Added.
(WTF::is): Added.
(WTF::CheckedRefHashTraits): Added.
(WTF::CheckedRefHashTraits::emptyValue): Added.
(WTF::CheckedRefHashTraits::constructEmptyValue): Added.
(WTF::CheckedRefHashTraits::isEmptyValue): Added.
(WTF::CheckedRefHashTraits::peek): Added.
(WTF::CheckedRefHashTraits::take): Added.
(WTF::CanMakeCheckedPtr): Moved from CheckedPtr.h
* wtf/Forward.h:
Tools:
Added some unit tests for CheckedRef and updated the unit tests
for CheckedPtr per the removal of makeCheckedPtr.
* TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* TestWebKitAPI/Tests/WTF/CheckedPtr.cpp:
(WTF_CheckedPtr.CheckedRef): Added
* TestWebKitAPI/Tests/WTF/CheckedRef.cpp: Added.
(TestWebKitAPI..CheckedObject): Added.
(TestWebKitAPI..DerivedCheckedObject): Added.
(WTF_CheckedRef.Basic): Added.
(WTF_CheckedRef.DerivedClass): Added.
(WTF_CheckedRef.HashSet): Added.
Canonical link: https://commits.webkit.org/240183@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280559 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228695
Reviewed by Michael Catanzaro.
r278456 introduced a CORS allow list test that tries to fetch a
resource using the fetch() function, which returns a promise. This is
working on GTK but in WPE the test fails as the promise is not yet
resolved by the time the test variable is checked.
This commit changes the test to actually report the promise failure
through catch() and wait for its resolution before checking the values.
* TestWebKitAPI/Tests/WebKitGLib/TestWebKitWebView.cpp:
(testWebViewCORSAllowlist):
Canonical link: https://commits.webkit.org/240160@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280528 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228566
Patch by Michael Catanzaro <mcatanzaro@gnome.org> on 2021-07-29
Reviewed by Adrian Perez de Castro.
Source/WebCore:
Our MIMETypeRegistry::preferredExtensionForMIMEType returns "asc" for text/plain, possibly
because "asc" sorts alphabetically ahead of all other possible file extensions for
text/plain, and we just pick the first one. So if the text file does not contain any file
extension, we give it a file extension for a GPG signature. Ouch.
I don't know how to fix it, but we don't need to, because we don't really want to append any
file extension for text/plain anyway. That's just annoying. If I download a file named
"backtrace" then I don't want it renamed to "backtrace.txt". That would be expected on
Windows, but certainly not from WebKitGTK. So I think it's reasonable to have a special case
for text/plain.
* platform/xdg/MIMETypeRegistryXdg.cpp:
(WebCore::MIMETypeRegistry::preferredExtensionForMIMEType):
Tools:
* TestWebKitAPI/Tests/WebKitGLib/TestDownloads.cpp:
(serverCallback):
(testDownloadTextPlainMIMEType):
(beforeAll):
* TestWebKitAPI/Tests/WebKitGLib/resources/text: Added.
Canonical link: https://commits.webkit.org/240062@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280422 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228329
Patch by Alex Christensen <achristensen@webkit.org> on 2021-07-28
Reviewed by Youenn Fablet.
Source/WebKit:
Our NSURLSession WebSocket implementation had two bugs:
1. It was sending 1005 as the close code if none was specified.
It now sends no close code, which matches Chrome and Firefox.
2. It was not sending a close code before the close reason when a WebSocket is closed due to navigation.
It now sends the close code in 2 bytes before the reason, which matches Chrome and Firefox.
Side note: our CFReadStream/CFWriteStream implementation sent neither the code nor the reason
in this case, which matches no other browser.
Covered by an API test.
* NetworkProcess/cocoa/WebSocketTaskCocoa.mm:
(WebKit::WebSocketTask::close):
* WebProcess/Network/WebSocketChannel.cpp:
(WebKit::WebSocketChannel::fail):
(WebKit::WebSocketChannel::disconnect):
Tools:
* TestWebKitAPI/Tests/WebKitCocoa/WebSocket.mm:
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/240028@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280385 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228300
rdar://77558672
Reviewed by Tim Horton.
Source/WebCore/PAL:
Add a new SPI declaration on NSMenu. See WebKit and WebKitLegacy changes for more information.
* pal/spi/mac/NSMenuSPI.h:
Source/WebKit:
In macOS Monterey, the system-wide Fn+E key command presents the Emoji & Symbols UI as a popover. However, this
new key command currently does not work in editable contexts in both WebKit1 and WebKit2 views on macOS, where
we end up just inserting the character "e".
This is because, on both ports, we attempt to interpret NSEvents by calling back into AppKit to handle the
event, recording the selectors that *would've* been performed, and then using this information to build up a
list of WebCore::KeyCommand for the event (which are later converted into editing commands). In WebKit2, we
call into `-[NSTextInputContext handleEventByKeyboardLayout:]` to handle the event, and capture the resulting
calls back into `WKWebView` by storing entries in `m_collectedKeypressCommands` (something similar happens in
WebKit1). In the case of these new Fn commands, they are handled by the system before entering
NSTextInputContext, so NSTextInputContext ends up handling them as regular text insertion.
As an aside, the reason the meta (⌘) key doesn't encounter this problem is because meta, option, control and
shift are considered valid key bindings in NSKeyBindingManager, whereas the function key mask is specifically
excluded from this list for compability reasons. NSTextInputContext consults NSKeyBindingManager in order to
check whether the given NSEvent is a known key binding in `-handleEventByKeyboardLayout:`, so it fails to
acknowledge Fn+E as a key binding.
To work around this, we adopt new AppKit SPI added in rdar://81123724 to determine whether an NSEvent maps to
any main menu items and avoid handling "Fn-*" key events as text insertion if they already map to items in the
main menu.
Test: KeyboardEventTests.FunctionKeyCommand
* UIProcess/Cocoa/WebViewImpl.mm:
(WebKit::WebViewImpl::collectKeyboardLayoutCommandsForEvent):
Source/WebKitLegacy/mac:
Apply a similar fix, this time for WebKit1 on macOS.
* WebView/WebHTMLView.mm:
(-[WebHTMLView insertText:]):
Only append "insertText:" for a corresponding NSEvent with the Function key held down if it doesn't also map
to a item in the main menu.
Tools:
Add a new API test that simulates a keypress for "Fn+E" with a main menu that contains a system menu item for
that key binding; the test then verifies that text was not inserted into the page as a result.
* TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* TestWebKitAPI/Tests/mac/KeyboardEventTests.mm: Added.
(-[KeyboardTestMenu _containsItemMatchingEvent:includingDisabledItems:]):
(TestWebKitAPI::TEST):
* TestWebKitAPI/cocoa/TestWKWebView.h:
* TestWebKitAPI/cocoa/TestWKWebView.mm:
(-[TestWKWebView typeCharacter:]):
(-[TestWKWebView typeCharacter:modifiers:]):
Canonical link: https://commits.webkit.org/239983@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280336 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=227524
<rdar://problem/80264108>
Reviewed by Youenn Fablet.
Source/WebCore:
We should only check the app-bound domain list when registering a new
worker. Unregistering or updating an existing registration is fine because
we know that every registration has already gone through this check.
* workers/service/server/SWServer.cpp:
(WebCore::SWServer::addRegistrationFromStore):
(WebCore::SWServer::validateRegistrationDomain):
(WebCore::SWServer::scheduleJob):
* workers/service/server/SWServer.h:
Tools:
API test coverage. Drive-by fix to remove unnecessary WKWebView
configuration flags from tests that don't need them.
Note this will also fix https://bugs.webkit.org/show_bug.cgi?id=227531
where updating an existing worker fails after registering 3 domains,
but writing a test for that would require registering service workers
on 3 domains that are not localhost or a loopback IP address, which
we currently do not have infrastructure for.
Testing unregister was only possible because the script URL passed in
during the unregister job is null, so it does not get caught in the
localhost/loopback IP address check, unlike the update case.
* TestWebKitAPI/Tests/WebKitCocoa/InAppBrowserPrivacy.mm:
(TEST):
(-[SWInAppBrowserPrivacyMessageHandler userContentController:didReceiveScriptMessage:]):
Canonical link: https://commits.webkit.org/239967@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280319 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228259
<rdar://problem/80116822>
Reviewed by Tim Horton.
Source/WebKit:
If an application overrides the `-underPageBackgroundColor` with a dark color on a page that
has a light background color, the scroll bar will appear light to match the overridden value
of `-underPageBackgroundColor` instead of dark to match the page's background color.
Test: WKWebViewUnderPageBackgroundColor.MatchesScrollView
* UIProcess/API/ios/WKWebViewIOS.mm:
(baseScrollViewBackgroundColor):
(scrollViewBackgroundColor):
(-[WKWebView _updateScrollViewBackground]):
Add a flag to indicate whether the `underPageBackgroundColor` (which can be overridden by
API) or `pageExtendedBackgroundColor` should be used when calculating the value provided to
`-[UIScrollView setBackgroundColor:]` and `-[UIScrollView setIndicatorStyle:]`. The former
uses the `underPageBackgroundColor` since that is why that API exists and the latter uses
the ``pageExtendedBackgroundColor` since it is based on what is shown in the page, which is
what the scroll bar is drawn on top of.
Tools:
* TestWebKitAPI/Tests/WebKitCocoa/WKWebViewUnderPageBackgroundColor.mm:
(TEST.WKWebViewUnderPageBackgroundColor.MatchesScrollView):
Canonical link: https://commits.webkit.org/239941@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280283 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228253
Source/WebKit:
<rdar://81038849>
Patch by Alex Christensen <achristensen@webkit.org> on 2021-07-23
Reviewed by Brian Weinstein.
We have an unfortunate situation where an old framework is calling code in a new framework that is giving it a WKContentRuleListStore
where it expects a _WKUserContentExtensionStore. As one of several mitigations for this problem, make the selectors able to be called.
Luckily it doesn't do much with the results. It just checks if they're null or not, and it passes any errors along. I added tests that do this.
* UIProcess/API/Cocoa/WKContentRuleListStore.mm:
(-[WKContentRuleListStore compileContentExtensionForIdentifier:encodedContentExtension:completionHandler:]):
(-[WKContentRuleListStore lookupContentExtensionForIdentifier:completionHandler:]):
(-[WKContentRuleListStore removeContentExtensionForIdentifier:completionHandler:]):
Tools:
Patch by Alex Christensen <achristensen@webkit.org> on 2021-07-23
Reviewed by Brian Weinstein.
* TestWebKitAPI/Tests/WebKitCocoa/WKContentExtensionStore.mm:
(TEST_F):
Canonical link: https://commits.webkit.org/239936@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280274 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228142
Reviewed by Simon Fraser.
Source/WebCore:
No behavior change.
This patch does some micro optimizations revealed by the profiler when running some of Speedometer2 tests which intensively use innerHTML.
This offers improvement in jQuery-TodoMVC and Vanilla-ES2015-Babel-Webpack-TodoMVC since both are super innerHTML heavy benchmarks.
----------------------------------------------------------------------------------------------------------------------------------
| subtest | ms | ms | b / a | pValue (significance using False Discovery Rate) |
----------------------------------------------------------------------------------------------------------------------------------
| Elm-TodoMVC |126.862500 |126.687500 |0.998621 | 0.673462 |
| VueJS-TodoMVC |27.775000 |27.645833 |0.995350 | 0.741588 |
| EmberJS-TodoMVC |129.350000 |129.129167 |0.998293 | 0.624196 |
| BackboneJS-TodoMVC |51.129167 |51.204167 |1.001467 | 0.716622 |
| Preact-TodoMVC |21.870833 |21.337500 |0.975614 | 0.217771 |
| AngularJS-TodoMVC |139.854167 |140.266667 |1.002950 | 0.489838 |
| Vanilla-ES2015-TodoMVC |69.229167 |68.895833 |0.995185 | 0.238772 |
| Inferno-TodoMVC |68.391667 |68.266667 |0.998172 | 0.762281 |
| Flight-TodoMVC |77.979167 |78.166667 |1.002404 | 0.710324 |
| Angular2-TypeScript-TodoMVC |39.741667 |39.966667 |1.005662 | 0.524123 |
| VanillaJS-TodoMVC |55.416667 |55.512500 |1.001729 | 0.781447 |
| jQuery-TodoMVC |268.812500 |266.966667 |0.993133 | 0.003384 (significant) |
| EmberJS-Debug-TodoMVC |345.383333 |345.662500 |1.000808 | 0.695259 |
| React-TodoMVC |90.679167 |90.179167 |0.994486 | 0.067477 |
| React-Redux-TodoMVC |152.691667 |152.687500 |0.999973 | 0.991207 |
| Vanilla-ES2015-Babel-Webpack-TodoMVC |66.487500 |65.729167 |0.988594 | 0.000118 (significant) |
----------------------------------------------------------------------------------------------------------------------------------
a mean = 242.12319
b mean = 242.80485
pValue = 0.1992654128
(Bigger means are better.)
1.003 times better
Results ARE NOT significant
* html/parser/HTMLConstructionSite.cpp:
(WebCore::HTMLConstructionSite::insertTextNode):
* html/parser/HTMLConstructionSite.h:
* html/parser/HTMLDocumentParser.cpp:
(WebCore::HTMLDocumentParser::pumpTokenizerLoop): We do not need to call `shrinkToBestFit` in fragment parsing case since
we will discard HTMLToken soon.
* html/parser/HTMLMetaCharsetParser.cpp:
(WebCore::HTMLMetaCharsetParser::checkForMetaCharset):
* html/parser/HTMLPreloadScanner.cpp:
(WebCore::HTMLPreloadScanner::scan):
* html/parser/HTMLToken.h:
(WebCore::HTMLToken::clear): We found that these `clear` calls cause performance problem according to the Instruments: we
repeatedly use this Vector, and we repeatedly allocate and deallocate this Vector unnecessarily. We use `resize(0)` instead
to avoid this allocation and deallocation.
(WebCore::HTMLToken::shrinkToBestFit): But HTMLToken is kept so long, so at some point, we would like to make backing storage
small. So, we add shrinkToBestFit and we call it only after finishing batching of HTMLToken processing.
(WebCore::HTMLToken::beginStartTag):
(WebCore::HTMLToken::beginEndTag):
* html/parser/HTMLTokenizer.h:
(WebCore::HTMLTokenizer::shrinkToBestFit):
* html/parser/HTMLTreeBuilder.cpp:
(WebCore::HTMLTreeBuilder::ExternalCharacterTokenBuffer::characterPredicate):
(WebCore::HTMLTreeBuilder::insertPhoneNumberLink):
(WebCore::HTMLTreeBuilder::linkifyPhoneNumbers):
(WebCore::HTMLTreeBuilder::processCharacterBuffer):
(WebCore::HTMLTreeBuilder::processCharacterBufferForInBody):
(WebCore::HTMLTreeBuilder::defaultForInTableText):
(WebCore::HTMLTreeBuilder::processTokenInForeignContent):
(WebCore::HTMLTreeBuilder::processFakeCharacters): Deleted. It is dead code before this patch.
* html/parser/HTMLTreeBuilder.h:
Source/WTF:
* wtf/Vector.h:
(WTF::Malloc>::shrinkToBestFit): This shrinks the backing storage to "appropriate for the living Vector".
* wtf/text/AtomStringImpl.cpp:
(WTF::UCharBufferTranslator::equal): WTF::equal for String does not check hash. This is because computing hash is expensive
and we would like to avoid that if it is not necessary. But when inserting string into AtomStringTable, we can use hash value
since they must be already computed because of HashMap's requirement. So let's use it before calling WTF::equal.
(WTF::LCharBufferTranslator::equal):
(WTF::BufferFromStaticDataTranslator::equal):
* wtf/text/StringView.h:
(WTF::StringView::stripLeadingMatchedCharacters): Add this and use it in HTMLTreeBuilder.
Tools:
* TestWebKitAPI/Tests/WTF/StringView.cpp:
(TestWebKitAPI::TEST):
* TestWebKitAPI/Tests/WTF/Vector.cpp:
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/239881@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280193 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=223974
Patch by Frédéric Wang <fwang@igalia.com> on 2021-07-22
Reviewed by Darin Adler.
Source/WebCore:
WebCore::documentOrder does not handle well elements like <summary> that contains a
shadow substree. This is causing assertion failures in debug build when setting start/end
selection and nullptr crashes in release build when trying to browse selection between these
start and end nodes. This patch fixes that issue by switching to shadow including tree order
for these particular cases. It introduces a generic treeOrder<TreeType>(a, b) function that
can be used for TreeType = ShadowIncludingTree as well as by WebCore::documentOrder.
* dom/Node.cpp: Explicitly instantiate commonInclusiveAncestor<ShadowIncludingTree> so that it can be used
by WebCore::treeOrder.
* dom/Position.cpp: Explicitly instantiate templates.
(WebCore::treeOrder): Convert documentOrder to a template parametrized by TreeType.
(WebCore::documentOrder): Implement it with treeOrder<ComposedTree>.
* dom/Position.h: Delcare new template.
* editing/ApplyStyleCommand.cpp:
(WebCore::ApplyStyleCommand::updateStartEnd): Use treeOrder<ShadowIncludingTree>.
(WebCore::ApplyStyleCommand::removeInlineStyle): Ditto.
* editing/VisiblePosition.cpp:
(WebCore::documentOrder): Use treeOrder<ShadowIncludingTree>.
* editing/VisibleSelection.cpp:
(WebCore::VisibleSelection::setBaseAndExtentToDeepEquivalents): Use treeOrder<ShadowIncludingTree>.
(WebCore::VisibleSelection::setWithoutValidation): Ditto.
Tools:
* TestWebKitAPI/Tests/WebCore/DocumentOrder.cpp: Update FIXME.
Canonical link: https://commits.webkit.org/239869@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280174 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=227902
Reviewed by Carlos Garcia Campos.
Source/WebKit:
Introduce new GLib API (and corresponding GObject properties):
webkit_web_view_get_camera_capture_state
webkit_web_view_get_microphone_capture_state
webkit_web_view_set_camera_capture_state
webkit_web_view_set_microphone_capture_state
webkit_web_view_get_display_capture_state
webkit_web_view_set_display_capture_state
webkit_user_media_permission_is_for_display_device
This can be useful in Web browsers willing to indicate the status of the capture devices
currently in use by the WebView.
Covered by API tests.
* UIProcess/API/glib/WebKitUIClient.cpp:
* UIProcess/API/glib/WebKitUserMediaPermissionRequest.cpp:
(webkit_user_media_permission_is_for_display_device):
* UIProcess/API/glib/WebKitWebView.cpp:
(webkitWebViewMediaCaptureStateDidChange):
(webkitWebViewSetProperty):
(webkitWebViewGetProperty):
(webkit_web_view_class_init):
(webkitWebViewConfigureMediaCapture):
(webkit_web_view_get_camera_capture_state):
(webkit_web_view_set_camera_capture_state):
(webkit_web_view_get_microphone_capture_state):
(webkit_web_view_set_microphone_capture_state):
(webkit_web_view_get_display_capture_state):
(webkit_web_view_set_display_capture_state):
* UIProcess/API/glib/WebKitWebViewPrivate.h:
* UIProcess/API/gtk/WebKitUserMediaPermissionRequest.h:
* UIProcess/API/gtk/WebKitWebView.h:
* UIProcess/API/gtk/docs/webkit2gtk-4.0-sections.txt:
* UIProcess/API/wpe/WebKitUserMediaPermissionRequest.h:
* UIProcess/API/wpe/WebKitWebView.h:
* UIProcess/API/wpe/docs/wpe-1.0-sections.txt:
Tools:
The GTK MiniBrowser is now able to show media capture indicators, through the URI entry. A
new API test was added, checking support for getDisplayMedia().
* MiniBrowser/gtk/BrowserTab.c:
(decidePermissionRequest):
* MiniBrowser/gtk/BrowserWindow.c:
(webViewMediaCaptureStateChanged):
(webViewUriEntryIconPressed):
(browserWindowSwitchTab):
* TestWebKitAPI/Tests/WebKitGLib/TestUIClient.cpp:
(testWebViewUserMediaPermissionRequests):
(testWebViewAudioOnlyUserMediaPermissionRequests):
(testWebViewDisplayUserMediaPermissionRequests):
(beforeAll):
* TestWebKitAPI/glib/WebKitGLib/WebViewTest.cpp:
(displayCaptureChanged):
(WebViewTest::waitUntilDisplayCaptureStateChangedTo):
(microphoneCaptureChanged):
(WebViewTest::waitUntilMicrophoneCaptureStateChangedTo):
(cameraCaptureChanged):
(WebViewTest::waitUntilCameraCaptureStateChangedTo):
* TestWebKitAPI/glib/WebKitGLib/WebViewTest.h:
* flatpak/flatpakutils.py:
(WebkitFlatpak.run_in_sandbox):
Canonical link: https://commits.webkit.org/239867@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280172 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Adrien Destugues