https://bugs.webkit.org/show_bug.cgi?id=228672
rdar://81348960
Reviewed by Simon Fraser.
On rare occasion, this test times out when the synthesized swipe gesture fails to cause the scrollable overflow
container to scroll past an arbitrary scroll position threshold (previously 400px). Mitigate this by rewriting
the test, such that we'll swipe _until_ we scroll past the threshold (which has also been lowered to just
100px).
Additionally, rewrite parts of this test to be generally easier to follow; for example, remove the scroll event
listener and instead just synthesize swipe gestures until `scroller.scrollTop` crosses 100px.
* fast/scrolling/ios/click-events-during-momentum-scroll-in-overflow-after-tap-on-body-expected.txt:
* fast/scrolling/ios/click-events-during-momentum-scroll-in-overflow-after-tap-on-body.html:
* platform/ios-wk2/TestExpectations: Remove the failing test expectation.
Canonical link: https://commits.webkit.org/240454@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280937 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228966
Reviewed by Eric Carlson.
Add an IPC message `RemoteAudioSessionProxy::SetIsPlayingToBluetoothOverride`
for testing purpose, so that the test `AudioRoutingArbitration.Updating` will
work as expected when "Media in GPU Process" is enabled.
No new tests. Fix an API test failure.
* GPUProcess/media/RemoteAudioSessionProxy.cpp:
(WebKit::RemoteAudioSessionProxy::setCategory):
(WebKit::RemoteAudioSessionProxy::setIsPlayingToBluetoothOverride):
* GPUProcess/media/RemoteAudioSessionProxy.h:
* GPUProcess/media/RemoteAudioSessionProxy.messages.in:
* WebProcess/GPU/media/RemoteAudioSession.cpp:
(WebKit::RemoteAudioSession::setCategory):
(WebKit::RemoteAudioSession::setIsPlayingToBluetoothOverride):
* WebProcess/GPU/media/RemoteAudioSession.h:
Canonical link: https://commits.webkit.org/240453@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280936 268f45cc-cd09-0410-ab3c-d52691b4dbfc
<https://webkit.org/b/229003>
<rdar://problem/81795626>
Reviewed by Chris Dumez.
Covered by 3245 layout tests running with TSan including:
http/wpt/service-workers/file-upload.html
* NetworkProcess/cache/NetworkCacheIOChannel.h:
(WebKit::NetworkCache::IOChannel::open):
- Update to use #pragma once.
- Make an isolatedCopy() for m_path.
(WebKit::NetworkCache::IOChannel::IOChannel):
- Switch to using an rvalue reference.
* NetworkProcess/cache/NetworkCacheIOChannelCocoa.mm:
(WebKit::NetworkCache::IOChannel::IOChannel): Ditto.
* NetworkProcess/cache/NetworkCacheIOChannelCurl.cpp:
(WebKit::NetworkCache::IOChannel::IOChannel): Ditto.
* NetworkProcess/cache/NetworkCacheIOChannelGLib.cpp:
(WebKit::NetworkCache::IOChannel::IOChannel): Ditto.
- Switch to use m_path instead of filePath to prevent
use-after-move.
Canonical link: https://commits.webkit.org/240452@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280935 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228748
<rdar://problem/81626714>
Reviewed by Chris Dumez.
Source/WebKit:
When suspending ResourceLoadStatistics and LocalStorage, we dispatched a suspend task, which waits on a
condition, to their WorkQueue. That means the queue will be suspended after completing all tasks scheduled
before the suspend task. These tasks may take a long time to complete and assertion may be timed out.
When network process receives PrepareToSuspend message, we want the queues to suspend as soon as possible. To
achieve that, now we check if the queue needs to be suspended before each task, which ensures the queue
execute as most one task after suspend().
* NetworkProcess/Classifier/ResourceLoadStatisticsDatabaseStore.cpp:
(WebKit::ResourceLoadStatisticsDatabaseStore::ResourceLoadStatisticsDatabaseStore):
* NetworkProcess/Classifier/ResourceLoadStatisticsDatabaseStore.h:
* NetworkProcess/Classifier/ResourceLoadStatisticsMemoryStore.cpp:
(WebKit::ResourceLoadStatisticsMemoryStore::ResourceLoadStatisticsMemoryStore):
* NetworkProcess/Classifier/ResourceLoadStatisticsMemoryStore.h:
* NetworkProcess/Classifier/ResourceLoadStatisticsStore.cpp:
(WebKit::ResourceLoadStatisticsStore::ResourceLoadStatisticsStore):
* NetworkProcess/Classifier/ResourceLoadStatisticsStore.h:
(WebKit::ResourceLoadStatisticsStore::workQueue):
* NetworkProcess/Classifier/WebResourceLoadStatisticsStore.cpp:
(WebKit::sharedStatisticsQueue):
(WebKit::WebResourceLoadStatisticsStore::suspend):
(WebKit::WebResourceLoadStatisticsStore::resume):
(WebKit::WTF_GUARDED_BY_LOCK): Deleted.
* NetworkProcess/Classifier/WebResourceLoadStatisticsStore.h:
* NetworkProcess/WebStorage/LocalStorageDatabase.cpp:
(WebKit::LocalStorageDatabase::create):
(WebKit::LocalStorageDatabase::LocalStorageDatabase):
* NetworkProcess/WebStorage/LocalStorageDatabase.h:
* NetworkProcess/WebStorage/LocalStorageNamespace.cpp:
(WebKit::LocalStorageNamespace::getOrCreateStorageArea):
* NetworkProcess/WebStorage/LocalStorageNamespace.h:
* NetworkProcess/WebStorage/SessionStorageNamespace.cpp:
(WebKit::SessionStorageNamespace::getOrCreateStorageArea):
* NetworkProcess/WebStorage/SessionStorageNamespace.h:
* NetworkProcess/WebStorage/StorageArea.cpp:
(WebKit::StorageArea::StorageArea):
* NetworkProcess/WebStorage/StorageArea.h:
* NetworkProcess/WebStorage/StorageManager.cpp:
(WebKit::StorageManager::createLocalStorageArea):
(WebKit::StorageManager::createTransientLocalStorageArea):
(WebKit::StorageManager::createSessionStorageArea):
* NetworkProcess/WebStorage/StorageManager.h:
* NetworkProcess/WebStorage/StorageManagerSet.cpp:
(WebKit::StorageManagerSet::StorageManagerSet):
(WebKit::StorageManagerSet::suspend):
(WebKit::StorageManagerSet::resume):
* NetworkProcess/WebStorage/StorageManagerSet.h:
(WebKit::StorageManagerSet::WTF_GUARDED_BY_LOCK): Deleted.
* NetworkProcess/WebStorage/TransientLocalStorageNamespace.cpp:
(WebKit::TransientLocalStorageNamespace::getOrCreateStorageArea):
* NetworkProcess/WebStorage/TransientLocalStorageNamespace.h:
Source/WTF:
Add SuspendableWorkQueue that would perform suspend check before each task.
* WTF.xcodeproj/project.pbxproj:
* wtf/CMakeLists.txt:
* wtf/Forward.h:
* wtf/SuspendableWorkQueue.cpp: Added.
(WTF::SuspendableWorkQueue::create):
(WTF::SuspendableWorkQueue::SuspendableWorkQueue):
(WTF::SuspendableWorkQueue::suspend):
(WTF::SuspendableWorkQueue::resume):
(WTF::SuspendableWorkQueue::dispatch):
(WTF::SuspendableWorkQueue::dispatchAfter):
(WTF::SuspendableWorkQueue::dispatchSync):
(WTF::SuspendableWorkQueue::invokeAllSuspensionCompletionHandlers):
(WTF::SuspendableWorkQueue::suspendIfNeeded):
* wtf/SuspendableWorkQueue.h: Added.
* wtf/WorkQueue.h:
(): Deleted.
Canonical link: https://commits.webkit.org/240451@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280934 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=229011
Reviewed by Alex Christensen.
LayoutTests/imported/w3c:
Rebaseline WPT tests that are now passing.
* web-platform-tests/html/semantics/links/links-created-by-a-and-area-elements/target_blank_implicit_noopener-expected.txt:
* web-platform-tests/html/semantics/links/links-created-by-a-and-area-elements/target_blank_implicit_noopener_base-expected.txt:
Source/WebCore:
<a rel="opener noopener" target="_blank"> should create a window without opener, as per:
- https://html.spec.whatwg.org/#get-an-element's-noopener (noopener is checked *before* opener).
Firefox and Chrome match the specification.
No new tests, rebaselined existing tests.
* html/HTMLAnchorElement.cpp:
(WebCore::HTMLAnchorElement::handleClick):
Canonical link: https://commits.webkit.org/240450@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280933 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=229006
<rdar://80343834>
Reviewed by Alex Christensen.
* http/tests/xmlhttprequest/interactive-state-expected.txt:
Rebaseline test as the output is a bit different now.
* http/tests/xmlhttprequest/interactive-state.cgi:
Use sleep instead of writing a lot of data to make sure that
the data is processed in chunks.
* http/tests/xmlhttprequest/interactive-state.html:
Modernize test a bit.
* platform/mac-wk1/TestExpectations:
Unskip test as it should no longer be flaky.
Canonical link: https://commits.webkit.org/240449@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280932 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=229008
<rdar://79960877>
Patch by Alex Christensen <achristensen@webkit.org> on 2021-08-11
Reviewed by Chris Dumez.
Source/WebCore:
Test: http/tests/performance/performance-measure-fetch-start.html
PerformanceTiming::fetchStart is returning 0 when we get a main resource from the cache sometimes.
This is causing PerformanceUserTiming::convertMarkToTimestamp to throw an error, which it should.
Like PerformanceResourceTiming::fetchStart we need to fall back to ResourceLoadTiming::startTime
if the NetworkLoadMetrics doesn't have any useful data for us.
* page/PerformanceTiming.cpp:
(WebCore::PerformanceTiming::fetchStart const):
LayoutTests:
* http/tests/performance/performance-measure-fetch-start-expected.txt: Added.
* http/tests/performance/performance-measure-fetch-start.html: Added.
Canonical link: https://commits.webkit.org/240448@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280931 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228156
Patch by Dana Estra <destra@apple.com> on 2021-08-11
Reviewed by Tim Horton.
Source/WebCore:
UIProcess now no longer handles scrollPageUp and scrollPageDown events. They return to eventHandler as
unhandled and the keyboard scroll animation is started.
Tests: fast/scrolling/keyboard-scrolling-distance-downArrow.html
fast/scrolling/keyboard-scrolling-distance-pageDown.html
* page/EventHandler.cpp:
(WebCore::EventHandler::defaultKeyboardEventHandler):
* platform/KeyboardScrollingAnimator.cpp:
(WebCore::KeyboardScrollingAnimator::keyboardScrollForKeyboardEvent const):
Source/WebKit:
UIProcess now no longer handles scrollPageUp and scrollPageDown events. They return
to eventHandler as unhandled and the keyboard scroll animation is started.
* UIProcess/API/mac/WKWebViewMac.mm:
(-[WKWebView scrollPageDown:]):
(-[WKWebView scrollPageUp:]):
LayoutTests:
Tests check that at least 2 scroll events occur when the downArrow key or pageDown key is pressed, and
that with each event, the page's offset from its original position increases.
* fast/scrolling/keyboard-scrolling-distance-downArrow-expected.txt: Added.
* fast/scrolling/keyboard-scrolling-distance-downArrow.html: Added.
* fast/scrolling/keyboard-scrolling-distance-pageDown-expected.txt: Added.
* fast/scrolling/keyboard-scrolling-distance-pageDown.html: Added.
Canonical link: https://commits.webkit.org/240446@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280928 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228970
rdar://81546781
Reviewed by Wenson Hsieh.
Source/WebCore:
r273072 made it so that flex items with an intrinsic size will honor
their aspect ratio when computing their content size. Prior to the
change, in taller password fields, the flex item representing the caps
lock indicator would be tall and narrow. The height would stretch to
fill the container, but the width would maintain its intrinsic width of
17px. Now that aspect ratio is accounted for, the width increases to
match the height, resulting in a much larger indicator in taller password
fields.
However, while r273072 regressed the appearance of the caps lock
indicator, it merely exposed an issue with the styling of the indicator.
Consider the following test case, which is a reduced version how the
caps lock indicator is styled:
<div style="display: flex; height: 100px">
<div style="content: url(17_x_17_blue_square.svg); align-self: stretch;"></div>
</div>
Prior to r273072, this displayed a 17x17 blue square (inside a 17x100
flex item). However, in Chrome, Firefox, and WebKit after r273072, this
shows a 100x100 blue square (inside a 100x100 flex item). This is the
expected behavior now that aspect ratio is accounted for.
Consequently, to fix the issue, the width of the indicator must be
limited to a maximum value. 17px was chosen to be the max-width, as the
indicator's width would not exceed 17px prior to r273072.
Test: fast/forms/caps-lock-indicator-width.html
* css/html.css:
(input::-webkit-caps-lock-indicator):
LayoutTests:
Added a layout test to verify that the width of the caps lock indicator
adapts to the height of the password field, but does not exceed a
maximum width.
The added test is skipped on WK1, since DumpRenderTree does not support
toggling caps lock state. Implementing the testing hook in DRT is made
difficult by the fact that, in WK1, the caps lock state is queried
directly from the OS, using GetCurrentKeyModifiers.
* fast/forms/caps-lock-indicator-width-expected.txt: Added.
* fast/forms/caps-lock-indicator-width.html: Added.
* platform/ios-wk1/TestExpectations:
* platform/mac-wk1/TestExpectations:
Canonical link: https://commits.webkit.org/240445@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280927 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228978
<rdar://79224824>
Reviewed by Kenneth Russell.
In cases where the MTLCommandBuffer is not a valid metal object,
we can end up in an infinite recursive loop during draw call setup. Refactor setupDraw to take no more than two attempts through the setup function.
Testing: Ran WebGL tests, use case samples. Set up synthetic
repro forcing bail out path, saw WebGL content fail to render
instead of a web process crash.
* src/libANGLE/renderer/metal/ContextMtl.h:
* src/libANGLE/renderer/metal/ContextMtl.mm:
(rx::ContextMtl::setupDraw):
(rx::ContextMtl::setupDrawImpl):
Canonical link: https://commits.webkit.org/240444@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280926 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=202714
<rdar://problem/56208425>
Reviewed by Geoffrey Garen.
LayoutTests/imported/w3c:
Rebaseline WPT tests now that more checks are passing. Note that these checks were already passing in both Firefox and Chrome.
* web-platform-tests/html/semantics/scripting-1/the-script-element/moving-between-documents/after-prepare-iframe-fetch-error-external-classic-expected.txt:
* web-platform-tests/html/semantics/scripting-1/the-script-element/moving-between-documents/after-prepare-iframe-fetch-error-external-module-expected.txt:
* web-platform-tests/html/semantics/scripting-1/the-script-element/moving-between-documents/after-prepare-iframe-parse-error-external-classic-expected.txt:
* web-platform-tests/html/semantics/scripting-1/the-script-element/moving-between-documents/after-prepare-iframe-parse-error-external-module-expected.txt:
* web-platform-tests/html/semantics/scripting-1/the-script-element/moving-between-documents/after-prepare-iframe-parse-error-inline-classic-expected.txt:
* web-platform-tests/html/semantics/scripting-1/the-script-element/moving-between-documents/after-prepare-iframe-success-external-classic-expected.txt:
* web-platform-tests/html/semantics/scripting-1/the-script-element/moving-between-documents/after-prepare-iframe-success-external-module-expected.txt:
* web-platform-tests/html/semantics/scripting-1/the-script-element/moving-between-documents/after-prepare-iframe-success-inline-classic-expected.txt:
* web-platform-tests/html/semantics/scripting-1/the-script-element/moving-between-documents/move-back-iframe-fetch-error-external-classic-expected.txt:
* web-platform-tests/html/semantics/scripting-1/the-script-element/moving-between-documents/move-back-iframe-fetch-error-external-module-expected.txt:
* web-platform-tests/html/semantics/scripting-1/the-script-element/moving-between-documents/move-back-iframe-parse-error-external-classic-expected.txt:
* web-platform-tests/html/semantics/scripting-1/the-script-element/moving-between-documents/move-back-iframe-parse-error-external-module-expected.txt:
* web-platform-tests/html/semantics/scripting-1/the-script-element/moving-between-documents/move-back-iframe-parse-error-inline-classic-expected.txt:
* web-platform-tests/html/semantics/scripting-1/the-script-element/moving-between-documents/move-back-iframe-success-external-classic-expected.txt:
* web-platform-tests/html/semantics/scripting-1/the-script-element/moving-between-documents/move-back-iframe-success-external-module-expected.txt:
* web-platform-tests/html/semantics/scripting-1/the-script-element/moving-between-documents/move-back-iframe-success-inline-classic-expected.txt:
Source/WebCore:
Stop evaluating <script>s moved between Documents during fetching:
- https://github.com/whatwg/html/issues/2469
- https://github.com/whatwg/html/pull/2673
Both Firefox and Chrome already behave this way.
No new tests, rebaselined existing tests.
* dom/ScriptElement.cpp:
(WebCore::ScriptElement::prepareScript):
Set the element's preparation-time document to its node document, as per:
- https://html.spec.whatwg.org/multipage/scripting.html#prepare-a-script (step 11)
(WebCore::ScriptElement::executePendingScript):
If scriptElement's preparation-time document is not equal to scriptElement's node document, then return, as per:
- https://html.spec.whatwg.org/multipage/scripting.html#execute-the-script-block (step 2)
* dom/ScriptElement.h:
Canonical link: https://commits.webkit.org/240442@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280924 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=228977
Reviewed by Antti Koivisto.
LayoutTests/imported/w3c:
Rebaseline WPT test that is now passing.
* web-platform-tests/html/semantics/document-metadata/the-style-element/style_non_matching_media-expected.txt:
Source/WebCore:
HTMLStyleElement should create its style sheet even if its media attribute is invalid.
WebKit currently didn't and this was causing us to fail the following WPT test:
- html/semantics/document-metadata/the-style-element/style_non_matching_media.html
This WPT test is passing in both Firefox and Chrome.
No new tests, rebaselined existing tests.
* dom/InlineStyleSheetOwner.cpp:
(WebCore::InlineStyleSheetOwner::createSheet):
Canonical link: https://commits.webkit.org/240432@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280910 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228980
Reviewed by Antti Koivisto.
LayoutTests/imported/w3c:
Rebaseline WPT test that is now passing.
* web-platform-tests/html/semantics/document-metadata/the-style-element/style_type_change-expected.txt:
Source/WebCore:
Dynamically changing HTMLStyleElement.type should change the rendering accordingly.
This is causing the following WPT test to fail in WebKit:
- html/semantics/document-metadata/the-style-element/style_type_change.html
This test is passing in both Firefox and Chrome.
No new tests, rebaselined existing test.
* html/HTMLStyleElement.cpp:
(WebCore::HTMLStyleElement::parseAttribute):
Canonical link: https://commits.webkit.org/240431@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280909 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228951
Patch by Kimmo Kinnunen <kkinnunen@apple.com> on 2021-08-11
Reviewed by Kenneth Russell.
Source/ThirdParty/ANGLE:
Cherry-pick ANGLE commit: b4fd46288aa65d61dc9c7140c7d1cdba3f4cdf9a
From: Kenneth Russell <kbr@chromium.org>
Date: Wed, 27 Jan 2021 15:56:58 -0800
Revise WebGL's shaderSource validation.
Per discussion in the WebGL working group, shaderSource no longer
generates INVALID_VALUE for sources containing characters outside the
ESSL character set. Compilation and/or linking is still specified to
fail when illegal constructs are used.
With this change, https://github.com/KhronosGroup/WebGL/pull/3206
passes with the passthrough command decoder.
Revise WebGL compatibility tests to follow the new rules.
* src/libANGLE/validationES2.cpp:
(gl::ValidateShaderSource):
* src/tests/gl_tests/WebGLCompatibilityTest.cpp:
LayoutTests:
Fixes tests:
webgl/1.0.x/conformance/misc/invalid-passed-params.html
webgl/1.0.x/conformance/glsl/bugs/character-set.html
webgl/2.0.y/conformance/misc/invalid-passed-params.html
webgl/2.0.y/conformance/glsl/bugs/character-set.html
* TestExpectations:
Canonical link: https://commits.webkit.org/240428@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280904 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228872
Reviewed by Antti Koivisto.
Source/WebCore:
The image get stretched because constrainLogicalHeightByMinMax uses the intrinsic height for the minimum height.
According to [1], the automatic minimum size in the ratio-dependent axis of a box is its min-content size,
not the intrinsic size. To fix this, the ratio-dependent minimum height of a box should be computed from aspect-ratio
if it doesn't have any child, otherwise, then it should consider the intrinsic height.
[1] https://www.w3.org/TR/css-sizing-4/#aspect-ratio-minimum
* rendering/RenderBox.cpp:
(WebCore::RenderBox::constrainLogicalHeightByMinMax const): The minimum height is computed from aspect-ratio if it doesn't have any child.
LayoutTests:
* TestExpectations:
Canonical link: https://commits.webkit.org/240426@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280889 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228974
<rdar://problem/81749547>
Reviewed by Stephanie Lewis.
* Scripts/webkitpy/xcode/simulated_device.py:
(SimulatedDeviceManager):
(SimulatedDeviceManager.populate_available_devices): Device state check is now shared between simulators.
(SimulatedDeviceManager._disambiguate_device_type): Only extract hardware family and type from candidate.
(SimulatedDevice.__init__): Device state check is now shared between simulators.
(SimulatedDevice.state): Use 'xcrun simctl list' instead of device.plist.
* Scripts/webkitpy/xcode/simulated_device_unittest.py:
(SimulatedDeviceTest.change_state_to): Deleted.
(SimulatedDeviceTest.test_swapping_devices): Deleted.
Canonical link: https://commits.webkit.org/240419@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280882 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228924
Reviewed by Alex Christensen.
LayoutTests/imported/w3c:
Rebaseline WPT test that is now passing.
* web-platform-tests/html/cross-origin-opener-policy/blob-popup.https-expected.txt:
Source/WebCore:
Pass ScriptExecutionContext's cross-origin-opener-policy when registering a public
Blob URL and store it in the blob registry alongside the blob data. As a result,
we are able to service the right COOP headers on the blob response later on when
doing a load of this blob. In the future, we'll pass the cross-origin-embedder-policy
as well, once we support it.
No new tests, rebaselined existing test.
* Modules/fetch/FetchLoader.cpp:
(WebCore::FetchLoader::startLoadingBlobURL):
* dom/Document.h:
* dom/ScriptExecutionContext.cpp:
(WebCore::ScriptExecutionContext::crossOriginOpenerPolicy const):
* dom/ScriptExecutionContext.h:
* fileapi/Blob.cpp:
(WebCore::BlobURLRegistry::registerURL):
(WebCore::Blob::Blob):
* fileapi/FileReaderLoader.cpp:
(WebCore::FileReaderLoader::start):
* fileapi/ThreadableBlobRegistry.cpp:
(WebCore::ThreadableBlobRegistry::registerBlobURL):
* fileapi/ThreadableBlobRegistry.h:
* html/HTMLMediaElement.cpp:
(WebCore::HTMLMediaElement::loadResource):
* loader/CrossOriginEmbedderPolicy.cpp:
(WebCore::obtainCrossOriginEmbedderPolicy):
For WebKit1, the initial empty document seems to have an empty URL instead of
"about:blank" so I had to extend the check so that COEP properly gets enabled.
* loader/CrossOriginOpenerPolicy.cpp:
(WebCore::obtainCrossOriginOpenerPolicy):
For WebKit1, the initial empty document seems to have an empty URL instead of
"about:blank" so I had to extend the check so that COOP properly gets enabled.
(WebCore::crossOriginOpenerPolicyToString):
(WebCore::CrossOriginOpenerPolicy::isolatedCopy const):
(WebCore::addCrossOriginOpenerPolicyHeaders):
* loader/CrossOriginOpenerPolicy.h:
(WebCore::operator==):
(WebCore::CrossOriginOpenerPolicy::encode const):
(WebCore::CrossOriginOpenerPolicy::decode):
* platform/network/BlobData.cpp:
(WebCore::BlobData::clone const):
* platform/network/BlobData.h:
(WebCore::BlobData::crossOriginOpenerPolicy const):
(WebCore::BlobData::setCrossOriginOpenerPolicy):
* platform/network/BlobRegistry.h:
* platform/network/BlobRegistryImpl.cpp:
(WebCore::BlobRegistryImpl::registerBlobURL):
(WebCore::BlobRegistryImpl::registerBlobURLOptionallyFileBacked):
* platform/network/BlobRegistryImpl.h:
* platform/network/BlobResourceHandle.cpp:
(WebCore::BlobResourceHandle::notifyResponseOnSuccess):
Source/WebKit:
* NetworkProcess/NetworkConnectionToWebProcess.cpp:
(WebKit::NetworkConnectionToWebProcess::registerBlobURLFromURL):
(WebKit::NetworkConnectionToWebProcess::registerBlobURLOptionallyFileBacked):
* NetworkProcess/NetworkConnectionToWebProcess.h:
* NetworkProcess/NetworkConnectionToWebProcess.messages.in:
* NetworkProcess/NetworkDataTaskBlob.cpp:
(WebKit::NetworkDataTaskBlob::dispatchDidReceiveResponse):
* NetworkProcess/NetworkProcessPlatformStrategies.cpp:
(WebKit::NetworkProcessPlatformStrategies::createBlobRegistry):
* WebProcess/FileAPI/BlobRegistryProxy.cpp:
(WebKit::BlobRegistryProxy::registerBlobURL):
* WebProcess/FileAPI/BlobRegistryProxy.h:
Source/WebKitLegacy/mac:
* WebCoreSupport/WebPlatformStrategies.mm:
Source/WebKitLegacy/win:
* WebCoreSupport/WebPlatformStrategies.cpp:
Canonical link: https://commits.webkit.org/240418@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280881 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228683
<rdar://78448610>
Patch by Alex Christensen <achristensen@webkit.org> on 2021-08-10
Reviewed by Tim Horton.
To prevent UIKit from deleting our files to upload after 60 seconds, copy them to a temporary directory,
then delete the files when cleaning up the WKContentView.
I manually verified this makes the files able to upload after more than 60 seconds, then deletes them when you close the tab.
* UIProcess/ios/WKContentView.h:
* UIProcess/ios/WKContentView.mm:
(-[WKContentView dealloc]):
(-[WKContentView _removeTemporaryFilesIfNecessary]):
(-[WKContentView _removeTemporaryFilesWhenDeallocated:]):
* UIProcess/ios/WKContentViewInteraction.h.orig: Added.
* UIProcess/ios/WKContentViewInteraction.mm.orig: Added.
* UIProcess/ios/forms/WKFileUploadPanel.mm:
(-[WKFileUploadPanel documentPicker:didPickDocumentsAtURLs:]):
Canonical link: https://commits.webkit.org/240413@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280875 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228967
rdar://80471465
Reviewed by Tim Horton.
When selecting text inside an image element using Live Text, if the text selection contains the very first
character (in DOM order) that appears in the image element's shadow root, the user will be unable to start an
image drag on the same image by clicking another part of the image that does not contain Live Text. This happens
because `DragController::startDrag` to handle the drag as a selection drag rather than an image drag, which (in
turn) happens because `DragController::draggableElement` computes a drag source type of
`DragSourceAction::Selection`.
This occurs because `FrameSelection::contains(const LayoutPoint&)` returns `true` for any point inside the
shadow root of an image element with Live Text that does NOT hit-test to a text node, because we end up hit-
testing to the image overlay container `div` as our `innerNode`, which means that the DOM position for the given
point is going to be at the first position inside the image overlay container. Since this canonicalizes to the
beginning of the first text node (in DOM order) inside the image overlay, if that first text node happens to be
selected, we'll end up believing that the layout point (which is not over any text inside the image) is inside
the selection.
To avoid this, we make a minor adjustment to the logic in `FrameSelection::contains`, so that we handle text
inside image overlays by mapping the selected text range to absolute quads, and then checking whether the given
point (in absolute coordinates) is contained in any of those quads.
While we could theoretically use this approach for all selections, it's both more expensive than a hit-test and
might result in compatibility issues, so we just limit it to the case where we know (a-prior) that all
selectable text is arbitrarily positioned using transforms.
This change fixes an API test that currently fails on macOS: DragAndDropTests.DragElementWithImageOverlay
* editing/FrameSelection.cpp:
(WebCore::FrameSelection::contains const):
Canonical link: https://commits.webkit.org/240411@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280872 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228313
<rdar://problem/81146417>
Reviewed by Alexey Proskuryakov.
Look up a device's current color profile by checking the default mode
rather than assuming it is "1". The device info dictionary returned
by ColorSyncDeviceCopyDeviceInfo has this shape:
{
CustomProfiles = {
ModeName1 = "file:///path/to/custom/profile.ics";
};
FactoryProfiles = {
DeviceDefaultProfileID = "ModeName1";
ModeName1 = {
DeviceModeDescription = "Mode Name 1";
DeviceProfileURL = "file:///path/to/factory/profile1.ics";
};
ModeName2 = {
DeviceModeDescription = "Mode Name 2";
DeviceProfileURL = "file:///path/to/factory/profile2.ics";
};
};
}
where CustomProfiles is only present if a custom profile has been
selected, and the default mode name is "1". Displays connected over
HDMI don't use the default mode name.
* DumpRenderTree/mac/LayoutTestHelper.m:
(colorProfileURLForDisplay):
Canonical link: https://commits.webkit.org/240410@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280871 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228965
Reviewed by Darin Adler.
LayoutTests/imported/w3c:
Rebaseline WPT tests that are now passing.
* web-platform-tests/html/semantics/document-metadata/the-meta-element/pragma-directives/attr-meta-http-equiv-refresh/allow-scripts-flag-changing-1-expected.txt:
* web-platform-tests/html/semantics/document-metadata/the-meta-element/pragma-directives/attr-meta-http-equiv-refresh/allow-scripts-flag-changing-2-expected.txt:
Source/WebCore:
Meta HTTP refresh should not navigate if document has sandboxed automatic features browsing context flag set:
- https://html.spec.whatwg.org/multipage/semantics.html#shared-declarative-refresh-steps (Step 13)
Firefox and Chrome already behave this way.
No new tests, rebaselined existing tests.
* dom/Document.cpp:
(WebCore::Document::processMetaHttpEquiv):
* dom/Document.h:
* html/HTMLMetaElement.cpp:
(WebCore::HTMLMetaElement::process):
* loader/DocumentLoader.cpp:
(WebCore::DocumentLoader::responseReceived):
* loader/FrameLoader.cpp:
(WebCore::FrameLoader::receivedFirstData):
(WebCore::FrameLoader::scheduleRefreshIfNeeded):
* loader/FrameLoader.h:
* loader/FrameLoaderTypes.h:
* loader/NavigationScheduler.cpp:
(WebCore::ScheduledRedirect::ScheduledRedirect):
(WebCore::NavigationScheduler::scheduleRedirect):
* loader/NavigationScheduler.h:
LayoutTests:
Unskip tests that should no longer be flaky now that they are passing.
* TestExpectations:
Canonical link: https://commits.webkit.org/240409@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280870 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228964
Reviewed by Darin Adler.
* WebKitTestRunner/ios/TestControllerIOS.mm:
(WTR::TestController::platformConfigureViewForTest):
For platforms where we control the size of the window/scene, resize it
to match the chosen default testing iPad size (768x1024), but with the
default testing iPad's status bar subtracted out, and the current platform's
added in, so that the end result is a WKWebView of identical size to
one on the default testing iPad.
Canonical link: https://commits.webkit.org/240407@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280867 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Eric Hutchison