Haiku_newservicekit: Bump to Webkit 612.1.6 #2

kenmays · 2021-02-24T19:38:05Z

This PR is to bump the Haiku_newservicekit project to the current Webkit 612.1.6 snapshot as of 2021-02-24.

…e Apple Pay sheet https://bugs.webkit.org/show_bug.cgi?id=222298 <rdar://problem/74557943> Reviewed by Wenson Hsieh. * Platform/cocoa/PaymentAuthorizationPresenter.mm: (WebKit::toNSErrors): Don't use `adoptNS` with `+[NSMutableArray array]` since that returns an autoreleased object. Use the helper `createNSArray` instead (as was previously done before r273143). Canonical link: https://commits.webkit.org/234457@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273297 268f45cc-cd09-0410-ab3c-d52691b4dbfc

…setSelectionWithoutUpdatingAppearance https://bugs.webkit.org/show_bug.cgi?id=222219 <rdar://problem/74548257> Reviewed by Wenson Hsieh. The assertion failure was caused by confirmCompositionAndNotifyClient called in commitProvisionalLoad committing the composition even though the composition node had been removed from the document. Fixed the bug by canceling the composition if the composition node had been removed or the selection had been moved away from it in confirmCompositionAndNotifyClient. Test: editing/input/select-all-clear-input-method.html * editing/Editor.cpp: (WebCore::Editor::confirmOrCancelCompositionAndNotifyClient): Renamed from confirmCompositionAndNotifyClient. * editing/Editor.h: * loader/FrameLoader.cpp: (WebCore::FrameLoader::commitProvisionalLoad): Canonical link: https://commits.webkit.org/234458@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273298 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=222303 Unreviewed non-unified build fixes. Source/JavaScriptCore: * API/JSAPIValueWrapper.cpp: * bytecode/SetPrivateBrandVariant.h: * heap/HeapAnalyzer.h: * heap/HeapProfiler.cpp: * parser/ParserTokens.h: * runtime/DOMAttributeGetterSetter.cpp: * runtime/GlobalExecutable.cpp: * runtime/JSScriptFetchParameters.cpp: Source/WebCore: * bindings/js/ScriptModuleLoader.cpp: * layout/integration/LayoutIntegrationInlineContentBuilder.cpp: * layout/integration/LayoutIntegrationInlineContentBuilder.h: * workers/WorkerGlobalScopeProxy.h: * workers/WorkerMessagingProxy.cpp: * workers/WorkerOrWorkletScriptController.cpp: * workers/WorkerOrWorkletScriptController.h: * workers/service/ServiceWorkerJob.cpp: Source/WebKit: * GPUProcess/graphics/RemoteRenderingBackend.cpp: * WebProcess/GPU/graphics/RemoteRenderingBackendProxy.cpp: Canonical link: https://commits.webkit.org/234459@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273299 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=221390 Reviewed by Antti Koivisto. Use EventLoop instead of RunLoop::main() to be thread safe in iOS WebKit1. * page/Page.cpp: (WebCore::Page::didFinishLoadingImageForElement): Canonical link: https://commits.webkit.org/234460@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273300 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=222101 Patch by Kimmo Kinnunen <kkinnunen@apple.com> on 2021-02-23 Reviewed by Simon Fraser. Source/WebKit: Implement RemoteImageBufferProxy::copyImage and RemoteImageBufferProxy::copyNativeImage. Implement by asking the data from the GPU process. Previously, with AcceleratedImageBufferShareableMappedBackend the HTMLCanvasElement::copiedImage() would construct the copy by copying the CGContext backed by the IOSurface that is accessible by both processes. This would succeed. After a draw to the image, the second copy would not reflect the draw but contain the same image as the first copy. Fix by not using the fact that the IOSurface is accessible by both processes. In the end, IOSurfaces will not be available in Web process. Converts NativeImage to ShareableBitmap with WebCore::CompositeOperator::Copy since the ImageBuffers might have unpremultiplied contents. Also, ShareableBitmap does not have contents, so blending is overhead. No new tests, enables ~150 tests. * GPUProcess/graphics/RemoteGraphicsContextGL.cpp: (WebKit::RemoteGraphicsContextGL::copyTextureFromMedia): * GPUProcess/graphics/RemoteRenderingBackend.cpp: (WebKit::RemoteRenderingBackend::getShareableBitmapForImageBuffer): * GPUProcess/graphics/RemoteRenderingBackend.h: * GPUProcess/graphics/RemoteRenderingBackend.messages.in: * WebProcess/GPU/graphics/RemoteImageBufferProxy.h: * WebProcess/GPU/graphics/RemoteRenderingBackendProxy.cpp: (WebKit::RemoteRenderingBackendProxy::getShareableBitmap): * WebProcess/GPU/graphics/RemoteRenderingBackendProxy.h: LayoutTests: * gpu-process/TestExpectations: Canonical link: https://commits.webkit.org/234461@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273301 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=221650 Patch by Frederic Wang <fwang@igalia.com> on 2021-02-23 Reviewed by Ryosuke Niwa. Source/WebCore: getStartEndListChildren relies on the render tree to move the "end" node to the next sibling, but this does not necessarily correspond to a sibling of the "start" node in the DOM tree. This breaks the assumption of ModifySelectionListLevelCommand::appendSiblingNodeRange that the "start" and "end" nodes are siblings (in that order), causing a null-pointer dereference. This patch fixes the issue by ensuring that getStartEndListChildren does not try to change the "end" node if it is not a sibling of the "start" one. Test: fast/editing/modify-selection-list-level-crash.html * editing/ModifySelectionListLevel.cpp: (WebCore::getStartEndListChildren): Don't change the end node if r->node() is a sibling of startChildList. LayoutTests: * fast/editing/modify-selection-list-level-crash-expected.txt: Added. * fast/editing/modify-selection-list-level-crash.html: Added. Canonical link: https://commits.webkit.org/234462@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273302 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=222273 Patch by Frederic Wang <fwang@igalia.com> on 2021-02-23 Reviewed by Carlos Garcia Campos. * TestWebKitAPI/Tests/WebKitGLib/TestSSL.cpp: (beforeAll): * TestWebKitAPI/glib/WebKitGLib/WebKitTestServer.cpp: (WebKitTestServer::WebKitTestServer): * TestWebKitAPI/glib/WebKitGLib/WebKitTestServer.h: Canonical link: https://commits.webkit.org/234463@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273303 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=222233 Unreviewed, address additional review feedback. Add comment and logging when the WebKit client is setting the user directory suffix. * Shared/mac/AuxiliaryProcessMac.mm: (WebKit::initializeSandboxParameters): Canonical link: https://commits.webkit.org/234464@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273304 268f45cc-cd09-0410-ab3c-d52691b4dbfc

…izers https://bugs.webkit.org/show_bug.cgi?id=222216 Reviewed by Simon Fraser. Add a mechanism to detect and resolve situations where at least one deferring gesture recognizer (`WKDeferringGestureRecognizer`) is stuck in Possible state after ending touches, but the touch event gesture recognizer is unable to be reset (i.e. neither possible or recognizing). This state is indicative of a general class of bugs regarding native gesture deferral, wherein our "gesture gates" never end up being lifted after ending all touches in the view. One such example of this type of bug was fixed in r272584, where all interaction (touch events, scrolling, tapping) due to the touch end deferrers never exiting Possible state after long pressing to present a context menu. To make these kinds of bugs both easier to diagnose and less fatal in the future, we introduce a watchdog timer that dispatches after ending all touches on the content view, and checks the consistency of deferring gesture recognizers in the view; if we detect stuck deferring gestures, we handle this by forcibly resetting the stuck deferring gestures and logging a fault message. I manually verified this change by reverting my fix for the aforementioned bug (r272584), and observing both (1) a system log fault message, and (2) that interactions continued to work even without the fix in r272584, after the watchdog timer fired. See below for more details. * SourcesCocoa.txt: * UIProcess/ios/GestureRecognizerConsistencyEnforcer.h: Copied from Source/WebKit/UIProcess/ios/WKDeferringGestureRecognizer.h. * UIProcess/ios/GestureRecognizerConsistencyEnforcer.mm: Added. (WebKit::GestureRecognizerConsistencyEnforcer::GestureRecognizerConsistencyEnforcer): (WebKit::GestureRecognizerConsistencyEnforcer::beginTracking): (WebKit::GestureRecognizerConsistencyEnforcer::endTracking): (WebKit::GestureRecognizerConsistencyEnforcer::reset): (WebKit::GestureRecognizerConsistencyEnforcer::timerFired): Add a helper class that wraps a `RunLoop::Timer` for the main runloop, and schedules a 1 second timer after all deferring gestures have ended; assuming no new touches begin after this timer is scheduled, we'll perform a consistency check over the content view's gestures and perform a log fault and force deferring gestures to end if needed. * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView setUpInteraction]): (-[WKContentView cleanUpInteraction]): Make sure that we reset any extant `GestureRecognizerConsistencyEnforcer` if the web process crashes. (-[WKContentView _removeDefaultGestureRecognizers]): (-[WKContentView _addDefaultGestureRecognizers]): (-[WKContentView _webTouchEventsRecognized:]): Adjust a few compile-time guards so that deferring gesture recognizers exist on the view, even if `ENABLE_IOS_TOUCH_EVENTS` is off. This makes some of the gesture deferral code throughout this file easier to reason about in non-internal iOS builds, since we don't need to sprinkle as many `ENABLE(IOS_TOUCH_EVENTS)` checks throughout this class. (-[WKContentView touchEventGestureRecognizer]): (-[WKContentView gestureRecognizerConsistencyEnforcer]): (-[WKContentView deferringGestures]): (-[WKContentView gestureRecognizer:shouldRecognizeSimultaneouslyWithGestureRecognizer:]): (-[WKContentView deferringGestureRecognizer:willBeginTouchesWithEvent:]): Refactor `-deferringGestureRecognizer:shouldDeferGesturesAfterBeginningTouchesWithEvent:` so that it returns an enum flag indicating whether the given gesture should be allowed to begin deferring native gestures; by making this `-deferringGestureRecognizer:willBeginTouchesWithEvent:`, we can now put state management logic here that's responsible for updating the `GestureRecognizerConsistencyEnforcer`. (-[WKContentView deferringGestureRecognizer:didTransitionToState:]): (-[WKContentView deferringGestureRecognizer:didEndTouchesWithEvent:]): (-[WKContentView _deferringGestures]): Deleted. Rename this to `-deferringGestures` and expose it as a readonly property, for use by the `GestureRecognizerConsistencyEnforcer`. (-[WKContentView deferringGestureRecognizer:shouldDeferGesturesAfterBeginningTouchesWithEvent:]): Deleted. * UIProcess/ios/WKDeferringGestureRecognizer.h: * UIProcess/ios/WKDeferringGestureRecognizer.mm: (-[WKDeferringGestureRecognizer touchesBegan:withEvent:]): (-[WKDeferringGestureRecognizer setState:]): Add a delegate hook to inform `WKContentView` when the gesture recognizer state changes. (-[WKDeferringGestureRecognizer deferringGestureDelegate]): Deleted. * UIProcess/mac/WKPrintingView.h: Fix a missing include that results in a build failure due to changed unified sources. * WebKit.xcodeproj/project.pbxproj: Canonical link: https://commits.webkit.org/234465@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273305 268f45cc-cd09-0410-ab3c-d52691b4dbfc

* rendering/RenderBlockFlow.cpp: (WebCore::RenderBlockFlow::invalidateLineLayoutPath): Function modernLineLayout is only defined if ENABLE(LAYOUT_FORMATING_CONTEXT) Canonical link: https://commits.webkit.org/234466@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273306 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=221186 Patch by Angelos Oikonomopoulos <angelos@igalia.com> on 2021-02-23 Reviewed by Keith Miller. run-javascriptcore-tests saves unrecognized arguments to pass through to build-jsc even when --no-build is used. However, when we're not building, nothing will ever use or look at the extra arguments. This means that those arguments are silently eaten up and, consequently, typos in option names can go undetected. Change the script to fail when --no-build has been passed and there are unrecognized options. * Scripts/run-javascriptcore-tests: Canonical link: https://commits.webkit.org/234467@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273307 268f45cc-cd09-0410-ab3c-d52691b4dbfc

…n Tools/ https://bugs.webkit.org/show_bug.cgi?id=222288 Reviewed by Darin Adler. * DumpRenderTree/ios/PixelDumpSupportIOS.mm: * DumpRenderTree/ios/UIScriptControllerIOS.mm: (WTR::UIScriptControllerIOS::zoomScale const): (WTR::UIScriptControllerIOS::scrollToOffset): (WTR::UIScriptControllerIOS::immediateScrollToOffset): (WTR::UIScriptControllerIOS::minimumZoomScale const): (WTR::UIScriptControllerIOS::maximumZoomScale const): * DumpRenderTree/mac/DumpRenderTree.mm: (fontAllowList): (adjustWebDocumentForFlexibleViewport): (createWebViewAndOffscreenWindow): (allocateGlobalControllers): (releaseGlobalControllers): (resetWebViewToConsistentState): (runTest): * DumpRenderTree/mac/DumpRenderTreeMac.h: * DumpRenderTree/mac/DumpRenderTreePasteboard.mm: (+[DumpRenderTreePasteboard _pasteboardWithName:]): (+[DumpRenderTreePasteboard releaseLocalPasteboards]): * DumpRenderTree/mac/EventSendingController.mm: (drt_WebHTMLView_beginDraggingSessionWithItemsEventSource): (+[EventSendingController initialize]): (-[EventSendingController beginDragWithFiles:]): (-[EventSendingController beginDragWithFilePromises:]): (-[EventSendingController mouseUp:withModifiers:]): (-[EventSendingController mouseMoveToX:Y:]): * DumpRenderTree/mac/FrameLoadDelegate.mm: (-[FrameLoadDelegate didClearWindowObjectInStandardWorldForFrame:]): * DumpRenderTree/mac/TestRunnerMac.mm: (TestRunner::setCustomPolicyDelegate): (TestRunner::waitForPolicyDelegate): (TestRunner::apiTestNewWindowDataLoadBaseURL): * DumpRenderTree/mac/UIDelegate.mm: (-[UIDelegate webView:dragImage:at:offset:event:pasteboard:source:slideBack:forView:]): (-[UIDelegate dealloc]): * TestRunnerShared/cocoa/LayoutTestSpellChecker.mm: (ensureGlobalLayoutTestSpellChecker): * TestWebKitAPI/Tests/WebKit/GetUserMedia.mm: (TestWebKitAPI::TEST): * TestWebKitAPI/Tests/WebKit/GetUserMediaNavigation.mm: (TestWebKitAPI::TEST): * TestWebKitAPI/Tests/WebKit/GetUserMediaReprompt.mm: (TestWebKitAPI::TEST): * TestWebKitAPI/Tests/WebKit/mac/CustomBundleParameter.mm: (TestWebKitAPI::didReceiveMessageFromInjectedBundle): * TestWebKitAPI/Tests/WebKitCocoa/CommandBackForward.mm: (WebKit2_CommandBackForwardTestWKView::SetUp): * TestWebKitAPI/Tests/WebKitCocoa/Download.mm: (TEST): * TestWebKitAPI/Tests/WebKitCocoa/InAppBrowserPrivacy.mm: * TestWebKitAPI/Tests/WebKitCocoa/NowPlayingControlsTests.mm: (TestWebKitAPI::TEST): * TestWebKitAPI/Tests/WebKitCocoa/PasteMixedContent.mm: (TestWebKitAPI::TEST): * TestWebKitAPI/Tests/WebKitCocoa/ReparentWebViewTimeout.mm: (TEST): * TestWebKitAPI/Tests/WebKitCocoa/SchemeRegistry.mm: (TestWebKitAPI::TEST): * TestWebKitAPI/Tests/WebKitCocoa/SystemPreview.mm: (TestWebKitAPI::TEST): * TestWebKitAPI/Tests/WebKitCocoa/TestSOAuthorization.mm: (-[TestSOAuthorizationDelegate webView:createWebViewWithConfiguration:forNavigationAction:windowFeatures:]): * TestWebKitAPI/Tests/WebKitCocoa/UserInitiatedActionInNavigationAction.mm: (UserInitiatedActionTest::URLWithFragment): * TestWebKitAPI/Tests/WebKitCocoa/UserMediaDisabled.mm: (TEST_F): * TestWebKitAPI/Tests/WebKitCocoa/WKHTTPCookieStore.mm: (TEST): * TestWebKitAPI/Tests/WebKitCocoa/WKInspectorDelegate.mm: (-[UIDelegate _webView:configurationForLocalInspector:]): * TestWebKitAPI/Tests/WebKitCocoa/WKPDFView.mm: (TEST): * TestWebKitAPI/Tests/WebKitCocoa/WKWebViewCandidateTests.mm: (+[CandidateTestWebView setUpWithFrame:testPage:]): (TEST): * TestWebKitAPI/Tests/WebKitCocoa/WKWebViewDoesNotLogDuringInitialization.mm: (TEST): * TestWebKitAPI/Tests/WebKitCocoa/WKWebViewEvaluateJavaScript.mm: * TestWebKitAPI/Tests/WebKitCocoa/WebsiteDataStoreCustomPaths.mm: (runWebsiteDataStoreCustomPaths): * TestWebKitAPI/Tests/WebKitCocoa/WebsitePolicies.mm: (-[WebsitePoliciesWebsiteDataStoreDelegate webView:startURLSchemeTask:]): * TestWebKitAPI/Tests/WebKitLegacy/mac/ClosingWebView.mm: (TestWebKitAPI::TEST): * TestWebKitAPI/Tests/WebKitObjC/CustomProtocolsInvalidScheme.mm: (TestWebKitAPI::TEST): * TestWebKitAPI/Tests/WebKitObjC/PreventImageLoadWithAutoResizing.mm: (TestWebKitAPI::TEST): * TestWebKitAPI/Tests/WebKitObjC/UserContentTest.mm: (TEST_F): * TestWebKitAPI/Tests/ios/DragAndDropTestsIOS.mm: (TestWebKitAPI::TEST): * TestWebKitAPI/Tests/ios/KeyboardInputTestsIOS.mm: (+[InputAssistantItemTestingWebView leadingItemsForWebView:]): (+[InputAssistantItemTestingWebView trailingItemsForWebView:]): * TestWebKitAPI/Tests/ios/WKScrollViewDelegate.mm: (TestWebKitAPI::TEST): * TestWebKitAPI/Tests/mac/CandidateTests.mm: (TestWebKitAPI::TEST): * TestWebKitAPI/Tests/mac/MemoryCachePruneWithinResourceLoadDelegate.mm: (TestWebKitAPI::TEST): * TestWebKitAPI/ios/mainIOS.mm: (main): * TestWebKitAPI/mac/TestFontOptions.mm: (+[TestFontOptions sharedInstance]): * TestWebKitAPI/mac/mainMac.mm: (main): * WebKitTestRunner/InjectedBundle/ios/AccessibilityControllerIOS.mm: (WTR::AccessibilityController::addNotificationListener): * WebKitTestRunner/cocoa/TestControllerCocoa.mm: (WTR::globalWebViewConfiguration): (WTR::globalWebsiteDataStoreDelegateClient): (WTR::initializeWebViewConfiguration): (WTR::TestController::platformContext): (WTR::TestController::platformPreferences): (WTR::TestController::platformInitializeDataStore): (WTR::TestController::platformCreateWebView): (WTR::TestController::platformCreateOtherPage): (WTR::TestController::platformAdjustContext): (WTR::TestController::cocoaResetStateToConsistentValues): (WTR::TestController::removeAllSessionCredentials): (WTR::TestController::getAllStorageAccessEntries): (WTR::TestController::loadedSubresourceDomains): (WTR::TestController::clearLoadedSubresourceDomains): (WTR::TestController::injectUserScript): (WTR::TestController::setAllowStorageQuotaIncrease): (WTR::TestController::setAllowsAnySSLCertificate): * WebKitTestRunner/ios/GeneratedTouchesDebugWindow.mm: (+[GeneratedTouchesDebugWindow sharedGeneratedTouchesDebugWindow]): * WebKitTestRunner/ios/HIDEventGenerator.mm: (+[HIDEventGenerator sharedHIDEventGenerator]): * WebKitTestRunner/mac/TestControllerMac.mm: (WTR::TestController::configureContentExtensionForTest): * WebKitTestRunner/mac/WebKitTestRunnerPasteboard.mm: (+[WebKitTestRunnerPasteboard _pasteboardWithName:]): (+[WebKitTestRunnerPasteboard releaseLocalPasteboards]): Canonical link: https://commits.webkit.org/234468@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273308 268f45cc-cd09-0410-ab3c-d52691b4dbfc

…ing out since GStreamer 1.18 update https://bugs.webkit.org/show_bug.cgi?id=218580 Patch by Philippe Normand <pnormand@igalia.com> on 2021-02-23 Reviewed by Xabier Rodriguez-Calvar. Source/WebCore: Live streams start without pre-rolling, that means they can reach PAUSED while sinks still haven't received a sample to render. So we need to notify the media element in such cases only after pre-rolling has completed. Otherwise the media element might emit a play event too early, before pre-rolling has been completed. No new tests, this patch fixes a few layout tests though, most notably removing flakiness from fast/mediastream/captureStream/canvas2d.html. * platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp: (WebCore::MediaPlayerPrivateGStreamer::updateStates): (WebCore::MediaPlayerPrivateGStreamer::triggerRepaint): LayoutTests: * platform/glib/TestExpectations: Unflag no-longer-flaky and now-passing media tests. Canonical link: https://commits.webkit.org/234469@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273309 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=222297 Reviewed by Eric Carlson. After r272721 the non-unified WinCairo build reported error C2859, filename is not the type file that was used when this precompiled header was created. This was because a handful of files were in the WebCore library as well as the WebCoreTestSupport library. Investigating the XCode project it turned out that the files listed in the CMake for WebCoreTestSupport didn't match. The XCode project had all of the mock files within platform in WebCore and WebCoreTestSupport just had files in the testing directory. All mock related files were added to the Sources.txt and the erroneous listing of them in WebCoreTestSupport_SOURCES were removed. During the investigation it turned out some mocks were being compiled in both WebCore and WebCoreTestSupport within the XCode build. This was rectified and an additional WEBCORE_EXPORT in PlatformSpeechSynthesizerMock was added to support this. * CMakeLists.txt: * Sources.txt: * WebCore.xcodeproj/project.pbxproj: * platform/mock/PlatformSpeechSynthesizerMock.h: Canonical link: https://commits.webkit.org/234470@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273310 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=222314 Reviewed by Philippe Normand. In some cases, WebKit can be run before Thunder nano services are up and without PSON, the result can be that you end up with WebKit thinking there is no DRM system available. First thing this patch does it removing the once flag so we keep asking if there are DRM systems available if we are asked about them from JS. Second thing is that if we are queried from JS about the availability of DRM systems and there are some available, we initialize the decryptor. * platform/graphics/gstreamer/GStreamerCommon.cpp: (WebCore::registerWebKitGStreamerElements): * platform/graphics/gstreamer/eme/CDMThunder.cpp: (WebCore::CDMFactoryThunder::supportedKeySystems const): * platform/graphics/gstreamer/eme/WebKitThunderDecryptorGStreamer.cpp: Canonical link: https://commits.webkit.org/234471@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273311 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=222316 Reviewed by Michael Catanzaro. .: Turn off ENABLE_WEBASSEMBLY for Windows on JSCOnly now that its possible to build it without FTL. * Source/cmake/OptionsJSCOnly.cmake: Source/WTF: Update sources for the JSCOnly Windows build. * wtf/PlatformJSCOnly.cmake: Canonical link: https://commits.webkit.org/234472@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273312 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=222275 <rdar://problem/74614397> Patch by Kimmo Kinnunen <kkinnunen@apple.com> on 2021-02-23 Reviewed by Jonathan Bedard. Regenerate the IPC generation test expectations that were not part of r273204. Tested by ./Tools/Scripts/test-webkitpy-python2 -j1 -p Source/WebKit/Scripts/webkit/messages_unittest.py * Scripts/webkit/tests/MessageArgumentDescriptions.cpp: (IPC::jsValueForArguments): (IPC::messageArgumentDescriptions): * Scripts/webkit/tests/MessageNames.cpp: (IPC::description): (IPC::receiverName): (IPC::isValidMessageName): * Scripts/webkit/tests/MessageNames.h: * Scripts/webkit/tests/TestWithSemaphoreMessages.h: * Scripts/webkit/tests/TestWithStreamMessages.h: Canonical link: https://commits.webkit.org/234473@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273313 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=222286 Patch by Rob Buis <rbuis@igalia.com> on 2021-02-23 Reviewed by Simon Fraser. Source/WebCore: Make aspect-ratio invisible from style when disabled. Test: fast/css/aspect-ratio-invalidate-if-disabled.html * css/CSSComputedStyleDeclaration.cpp: (WebCore::ComputedStyleExtractor::valueForPropertyInStyle): * css/CSSProperties.json: Tools: Add support for disabling aspect-ratio in wk1. * DumpRenderTree/TestOptions.cpp: (WTR::TestOptions::defaults): LayoutTests: Add test. * fast/css/aspect-ratio-invalidate-if-disabled-expected.txt: Added. * fast/css/aspect-ratio-invalidate-if-disabled.html: Added. Canonical link: https://commits.webkit.org/234474@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273314 268f45cc-cd09-0410-ab3c-d52691b4dbfc

…in position https://bugs.webkit.org/show_bug.cgi?id=222313 <rdar://problem/74645910> Reviewed by Aakash Jain. * Scripts/libraries/webkitscmpy/setup.py: Bump version. * Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py: Ditto. * Scripts/libraries/webkitscmpy/webkitscmpy/contributor.py: (Contributor.__repr__): Always return unicode for Python 2. * Scripts/libraries/webkitscmpy/webkitscmpy/test/contributor_unittest.py: (TestContributor.test_unicode): Canonical link: https://commits.webkit.org/234475@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273315 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=222320 Need to update CI code for CLoop bot before landing this Reverted changeset: "Detect unrecognized options in run-javascriptcore-tests" https://bugs.webkit.org/show_bug.cgi?id=221186 https://trac.webkit.org/changeset/273307 Canonical link: https://commits.webkit.org/234476@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273316 268f45cc-cd09-0410-ab3c-d52691b4dbfc

…an/css3-counter-styles-156.html is consistently failing https://bugs.webkit.org/show_bug.cgi?id=222118 Unreviewed test gardening. * platform/mac/TestExpectations: This test is an ImageOnlyFailure. Canonical link: https://commits.webkit.org/234477@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273318 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=222324 Introduced test failure Reverted changeset: "[macOS] Crash under AuxiliaryProcess::initializeSandbox" https://bugs.webkit.org/show_bug.cgi?id=222233 https://trac.webkit.org/changeset/273304 Canonical link: https://commits.webkit.org/234478@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273320 268f45cc-cd09-0410-ab3c-d52691b4dbfc

WebKit-7612.1.6 Canonical link: https://commits.webkit.org/234479@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273321 268f45cc-cd09-0410-ab3c-d52691b4dbfc

… animations in non-AC mode pages https://bugs.webkit.org/show_bug.cgi?id=221391 Reviewed by Carlos Garcia Campos. When triggerRenderingUpdate was called back, it added the whole view area into the dirty region to repaint in non-AC mode pages. This caused a problem that the whole content was unnecessarily repainted by animations in non-AC mode pages. Call scheduleDisplay instead of setNeedsDisplay in triggerRenderingUpdate. However, if the dirty region is empty, display() exited early. If triggerRenderingUpdate is called back, DrawingAreaCoordinatedGraphics::display should be called to ensure WebPage::updateRendering() called even if m_dirtyRegion is empty. Added a new flag m_scheduledWhileWaitingForDidUpdate. * WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.cpp: (WebKit::DrawingAreaCoordinatedGraphics::triggerRenderingUpdate): Call scheduleDisplay() instead of setNeedsDisplay(). (WebKit::DrawingAreaCoordinatedGraphics::didUpdate): (WebKit::DrawingAreaCoordinatedGraphics::scheduleDisplay): Don't return early even if m_dirtyRegion is empty. (WebKit::DrawingAreaCoordinatedGraphics::display()): Ditto. (WebKit::DrawingAreaCoordinatedGraphics::display(UpdateInfo&)): Return early if m_dirtyRegion is empty. * WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.h: Added m_scheduledWhileWaitingForDidUpdate. Canonical link: https://commits.webkit.org/234480@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273327 268f45cc-cd09-0410-ab3c-d52691b4dbfc

…empty https://bugs.webkit.org/show_bug.cgi?id=221716 <rdar://problem/74205567> Reviewed by Zalan Bujtas. Source/WebCore: ARIA treeitems are allowed to have a child group that can represent the disclosed rows, which are disclosed through aria-owns. Test: accessibility/mac/treeitem-row-delegation.html * accessibility/AccessibilityObject.cpp: (WebCore::AccessibilityObject::ariaTreeRows): LayoutTests: * accessibility/mac/treeitem-row-delegation-expected.txt: Added. * accessibility/mac/treeitem-row-delegation.html: Added. Canonical link: https://commits.webkit.org/234481@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273328 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=222279 Reviewed by Alex Christensen. Previously, the logging of messages to the system console was done in PageConsoleClient::addMessage(), which was called by Document::addConsoleMessage(). The latter was called in a TaskQueue callback. This had the unfortunate side effect of adding a delay from the time a macro such as ALWAYS_LOG() is called and the text being printed to the console. This is particularly a problem when logging 3rd party libraries that don't use the WebKit logging API to log to stderr, such as GStreamer, since it causes messages logged by WebKit to not be synchronized with messages logged by 3rd party libraries or logging systems. As a consequence the usefulness of WebKit logs is noticeably reduced. This patch fixes the issue by moving the code logging to the system console to the synchronous part of Document::didLogMessage(), while still handling the rest in the m_logMessageTaskQueue callback. * dom/Document.cpp: (WebCore::Document::didLogMessage): * page/PageConsoleClient.cpp: (WebCore::PageConsoleClient::addMessage): Canonical link: https://commits.webkit.org/234482@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273329 268f45cc-cd09-0410-ab3c-d52691b4dbfc

…pStyleSpanInline https://bugs.webkit.org/show_bug.cgi?id=221651 Patch by Frederic Wang <fwang@igalia.com> on 2021-02-23 Reviewed by Ryosuke Niwa. Source/WebCore: There are assumptions in the editing code that new containers have an associated renderer, which is not the case if their style is "display: contents". This patch replaces the strict debug ASSERT in CompositeEditCommand::appendBlockPlaceholder with a failure specified by a nullptr return value, similar to other BlockPlaceholder APIs. That way InsertParagraphSeparatorCommand::doApply can exit early when the block placeholder cannot be inserted. This patch also fixes one nullptr dereference in release build happening when executing Editor::replaceSelectionWithFragment. Test: fast/editing/mutation-with-display-contents-container-crash.html * editing/CompositeEditCommand.cpp: (WebCore::CompositeEditCommand::appendBlockPlaceholder): Return null is the container has no associated renderer. * editing/CompositeEditCommand.h: Return a RefPtr, so it is null in case of failure. * editing/InsertParagraphSeparatorCommand.cpp: (WebCore::InsertParagraphSeparatorCommand::doApply): Abort command if the block placeholder cannot be inserted in the container. LayoutTests: * fast/editing/mutation-with-display-contents-container-crash-expected.txt: Added. * fast/editing/mutation-with-display-contents-container-crash.html: Added. * platform/ios/fast/editing/mutation-with-display-contents-container-crash-expected.txt: Added. Canonical link: https://commits.webkit.org/234483@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273330 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=221109 <rdar://problem/74002781> Reviewed by Jonathan Bedard. On Python 3 when the AutoInstall routine attempted to setup markupsafe-2.0.0 it would fail when compiling native code. When compiling outside of Visual Studio there is a batch file that sets up the environment. This adds a large number of environment variables which could potentially change over time so to be safe the complete environment is passed to the setup.py installation routine for Windows only. * Scripts/libraries/webkitcorepy/webkitcorepy/autoinstall.py: (Package.install): Canonical link: https://commits.webkit.org/234484@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273331 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=222213 <rdar://problem/74542626> Rubber-stamped by Aakash Jain. * Scripts/libraries/webkitscmpy/setup.py: Increment version. * Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py: Ditto. * Scripts/libraries/webkitscmpy/webkitscmpy/mocks/remote/__init__.py: Export mock BitBucket. * Scripts/libraries/webkitscmpy/webkitscmpy/mocks/remote/bitbucket.py: Added. (BitBucket): Mock limited set of BitBucket REST APIs. * Scripts/libraries/webkitscmpy/webkitscmpy/remote/__init__.py: Export BitBucket class. * Scripts/libraries/webkitscmpy/webkitscmpy/remote/bitbucket.py: Added. (BitBucket): Repository object interacting with BitBucket via REST API. (BitBucket.is_webserver): Check if the provided URL is a bitbucket URL. (BitBucket.__init__): (BitBucket.is_git): (BitBucket.request): Combine paginated requests into a single API call. (BitBucket._distance): Preform binary search (BitBucket._branches_for): Return branches for reference. (BitBucket.default_branch): Return the default branch. (BitBucket.branches): Return all branches for repository. (BitBucket.tags): Return all tags for repository. (BitBucket.commit): Convert hash, identifier or git ref to Commit object. (BitBucket.find): Use git to match branches and tags to a hash instead of trying to do it ourselves. * Scripts/libraries/webkitscmpy/webkitscmpy/remote/scm.py: (Scm.from_url): Add BitBucket. * Scripts/libraries/webkitscmpy/webkitscmpy/test/git_unittest.py: (TestGitHub.test_detection): Add bitbucket url. (TestBitBucket): Added. * Scripts/libraries/webkitscmpy/webkitscmpy/test/svn_unittest.py: (TestRemoteSvn.test_detection): Add bitbucket url. Canonical link: https://commits.webkit.org/234485@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273333 268f45cc-cd09-0410-ab3c-d52691b4dbfc

* platform/win/TestExpectations: Canonical link: https://commits.webkit.org/234486@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273334 268f45cc-cd09-0410-ab3c-d52691b4dbfc

…erty() are failing https://bugs.webkit.org/show_bug.cgi?id=223134 Reviewed by Yusuke Suzuki. This patch: 1. Simplifies exception check after validateAndApplyPropertyDescriptor() as it conditionally throws on failure. 2. Creates new SymbolTableEntry when global variable is redefined as read-only because setAttributes() performs pack(), which doesn't support fat entries. Due to #2, symbolTableGet() overload is simplified to return fast entry, and setAttributes() is removed as unused. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::defineOwnProperty): * runtime/JSSymbolTableObject.h: (JSC::symbolTableGet): * runtime/SymbolTable.h: (JSC::SymbolTableEntry::getAttributes const): (JSC::SymbolTableEntry::setAttributes): Deleted. Canonical link: https://commits.webkit.org/235273@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@274406 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=228047 Reviewed by Phil Pizlo. Pre-indexed addressing means that the address is the sum of the value in the 64-bit base register and an offset, and the address is then written back to the base register. And post-indexed addressing means that the address is the value in the 64-bit base register, and the sum of the address and the offset is then written back to the base register. They are relatively common for loops to iterate over an array by increasing/decreasing a pointer into the array at each iteration. With such an addressing mode, the instruction selector can merge the increment and access the array. ##################################### ## Pre-Index Address Mode For Load ## ##################################### LDR Wt, [Xn, #imm]! In B3 Reduction Strength, since we have this reduction rule: Turn this: Load(Add(address, offset1), offset = offset2) Into this: Load(address, offset = offset1 + offset2) Then, the equivalent pattern is: address = Add(base, offset) ... memory = Load(base, offset) First, we convert it to the canonical form: address = Add(base, offset) newMemory = Load(base, offset) // move the memory to just after the address ... memory = Identity(newMemory) Next, lower to Air: Move %base, %address Move (%address, prefix(offset)), %newMemory ###################################### ## Post-Index Address Mode For Load ## ###################################### LDR Wt, [Xn], #imm Then, the equivalent pattern is: memory = Load(base, 0) ... address = Add(base, offset) First, we convert it to the canonical form: newOffset = Constant newAddress = Add(base, offset) memory = Load(base, 0) // move the offset and address to just before the memory ... offset = Identity(newOffset) address = Identity(newAddress) Next, lower to Air: Move %base, %newAddress Move (%newAddress, postfix(offset)), %memory ############################# ## Pattern Match Algorithm ## ############################# To detect the pattern for prefix/postfix increment address is tricky due to the structure in B3 IR. The algorithm used in this patch is to collect the first valid values (add/load), then search for any paired value (load/add) to match all of them. In worst case, the runtime complexity is O(n^2) when n is the number of all values. After collecting two sets of candidates, we match the prefix incremental address first since it seems more beneficial to the compiler (shown in the next section). And then, go for the postfix one. ############################################## ## Test for Pre/Post-Increment Address Mode ## ############################################## Given Loop with Pre-Increment: int64_t ldr_pre(int64_t *p) { int64_t res = 0; while (res < 10) res += *++p; return res; } B3 IR: ------------------------------------------------------ BB#0: ; frequency = 1.000000 Int64 b@0 = Const64(0) Int64 b@2 = ArgumentReg(%x0) Void b@20 = Upsilon($0(b@0), ^18, WritesLocalState) Void b@21 = Upsilon(b@2, ^19, WritesLocalState) Void b@4 = Jump(Terminal) Successors: #1 BB#1: ; frequency = 1.000000 Predecessors: #0, #2 Int64 b@18 = Phi(ReadsLocalState) Int64 b@19 = Phi(ReadsLocalState) Int64 b@7 = Const64(10) Int32 b@8 = AboveEqual(b@18, $10(b@7)) Void b@9 = Branch(b@8, Terminal) Successors: Then:#3, Else:#2 BB#2: ; frequency = 1.000000 Predecessors: #1 Int64 b@10 = Const64(8) Int64 b@11 = Add(b@19, $8(b@10)) Int64 b@13 = Load(b@11, ControlDependent|Reads:Top) Int64 b@14 = Add(b@18, b@13) Void b@22 = Upsilon(b@14, ^18, WritesLocalState) Void b@23 = Upsilon(b@11, ^19, WritesLocalState) Void b@16 = Jump(Terminal) Successors: #1 BB#3: ; frequency = 1.000000 Predecessors: #1 Void b@17 = Return(b@18, Terminal) Variables: Int64 var0 Int64 var1 ------------------------------------------------------ W/O Pre-Increment Address Mode: ------------------------------------------------------ ... BB#2: ; frequency = 1.000000 Predecessors: #1 Move $8, %x3, $8(b@12) Add64 $8, %x0, %x1, b@11 Move (%x0,%x3), %x0, b@13 Add64 %x0, %x2, %x2, b@14 Move %x1, %x0, b@23 Jump b@16 Successors: #1 ... ------------------------------------------------------ W/ Pre-Increment Address Mode: ------------------------------------------------------ ... BB#2: ; frequency = 1.000000 Predecessors: #1 MoveWithIncrement64 (%x0,Pre($8)), %x2, b@13 Add64 %x2, %x1, %x1, b@14 Jump b@16 Successors: #1 ... ------------------------------------------------------ Given Loop with Post-Increment: int64_t ldr_pre(int64_t *p) { int64_t res = 0; while (res < 10) res += *p++; return res; } B3 IR: ------------------------------------------------------ BB#0: ; frequency = 1.000000 Int64 b@0 = Const64(0) Int64 b@2 = ArgumentReg(%x0) Void b@20 = Upsilon($0(b@0), ^18, WritesLocalState) Void b@21 = Upsilon(b@2, ^19, WritesLocalState) Void b@4 = Jump(Terminal) Successors: #1 BB#1: ; frequency = 1.000000 Predecessors: #0, #2 Int64 b@18 = Phi(ReadsLocalState) Int64 b@19 = Phi(ReadsLocalState) Int64 b@7 = Const64(10) Int32 b@8 = AboveEqual(b@18, $10(b@7)) Void b@9 = Branch(b@8, Terminal) Successors: Then:#3, Else:#2 BB#2: ; frequency = 1.000000 Predecessors: #1 Int64 b@10 = Load(b@19, ControlDependent|Reads:Top) Int64 b@11 = Add(b@18, b@10) Int64 b@12 = Const64(8) Int64 b@13 = Add(b@19, $8(b@12)) Void b@22 = Upsilon(b@11, ^18, WritesLocalState) Void b@23 = Upsilon(b@13, ^19, WritesLocalState) Void b@16 = Jump(Terminal) Successors: #1 BB#3: ; frequency = 1.000000 Predecessors: #1 Void b@17 = Return(b@18, Terminal) Variables: Int64 var0 Int64 var1 ------------------------------------------------------ W/O Post-Increment Address Mode: ------------------------------------------------------ ... BB#2: ; frequency = 1.000000 Predecessors: #1 Move (%x0), %x2, b@10 Add64 %x2, %x1, %x1, b@11 Add64 $8, %x0, %x0, b@13 Jump b@16 Successors: #1 ... ------------------------------------------------------ W/ Post-Increment Address Mode: ------------------------------------------------------ ... BB#2: ; frequency = 1.000000 Predecessors: #1 MoveWithIncrement64 (%x0,Post($8)), %x2, b@10 Add64 %x2, %x1, %x1, b@11 Jump b@16 Successors: #1 ... ------------------------------------------------------ * Sources.txt: * assembler/AbstractMacroAssembler.h: (JSC::AbstractMacroAssembler::PreIndexAddress::PreIndexAddress): (JSC::AbstractMacroAssembler::PostIndexAddress::PostIndexAddress): * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::load64): (JSC::MacroAssemblerARM64::load32): (JSC::MacroAssemblerARM64::store64): (JSC::MacroAssemblerARM64::store32): * assembler/testmasm.cpp: (JSC::testStorePrePostIndex32): (JSC::testStorePrePostIndex64): (JSC::testLoadPrePostIndex32): (JSC::testLoadPrePostIndex64): * b3/B3CanonicalizePrePostIncrements.cpp: Added. (JSC::B3::canonicalizePrePostIncrements): * b3/B3CanonicalizePrePostIncrements.h: Copied from Source/JavaScriptCore/b3/B3ValueKeyInlines.h. * b3/B3Generate.cpp: (JSC::B3::generateToAir): * b3/B3LowerToAir.cpp: * b3/B3ValueKey.h: * b3/B3ValueKeyInlines.h: (JSC::B3::ValueKey::ValueKey): * b3/air/AirArg.cpp: (JSC::B3::Air::Arg::jsHash const): (JSC::B3::Air::Arg::dump const): (WTF::printInternal): * b3/air/AirArg.h: (JSC::B3::Air::Arg::preIndex): (JSC::B3::Air::Arg::postIndex): (JSC::B3::Air::Arg::isPreIndex const): (JSC::B3::Air::Arg::isPostIndex const): (JSC::B3::Air::Arg::isMemory const): (JSC::B3::Air::Arg::base const): (JSC::B3::Air::Arg::offset const): (JSC::B3::Air::Arg::isGP const): (JSC::B3::Air::Arg::isFP const): (JSC::B3::Air::Arg::isValidPreIndexForm): (JSC::B3::Air::Arg::isValidPostIndexForm): (JSC::B3::Air::Arg::isValidForm const): (JSC::B3::Air::Arg::forEachTmpFast): (JSC::B3::Air::Arg::forEachTmp): (JSC::B3::Air::Arg::asPreIndexAddress const): (JSC::B3::Air::Arg::asPostIndexAddress const): * b3/air/AirOpcode.opcodes: * b3/air/opcode_generator.rb: * b3/testb3.h: * b3/testb3_3.cpp: (testLoadPreIndex32): (testLoadPreIndex64): (testLoadPostIndex32): (testLoadPostIndex64): (addShrTests): * jit/ExecutableAllocator.cpp: (JSC::jitWriteThunkGenerator): Canonical link: https://commits.webkit.org/240125@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280493 268f45cc-cd09-0410-ab3c-d52691b4dbfc

… that are not assignable <https://webkit.org/b/230406> <rdar://problem/83241893> Unreviewed attempt to fix API tests. Source/WTF: * wtf/cocoa/TypeCastsCocoa.h: (WTF::checked_objc_cast): - Rename checked_objc_cast<> to checked_objc_castARC<> when compiling with ARC enabled. - Also mark as `inline` function to allow for optimization. Tools: * TestWebKitAPI/Tests/WTF/cocoa/TypeCastsCocoa.mm: (TestWebKitAPI::TEST): - Revert code back to using objectNS.get() for checked_objc_cast<> tests since it always worked. Canonical link: https://commits.webkit.org/242516@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@283551 268f45cc-cd09-0410-ab3c-d52691b4dbfc

…ks an NSMutableDictionary <https://webkit.org/b/231814> <rdar://problem/84307054> Unreviewed follow-up to address Darin's comment. * UIProcess/WebAuthentication/Cocoa/LocalConnection.mm: (WebKit::LocalConnection::createCredentialPrivateKey const): - Use WTFMove() to avoid ref count churn. Canonical link: https://commits.webkit.org/243218@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@284458 268f45cc-cd09-0410-ab3c-d52691b4dbfc

…onsidered opaque bidi items https://bugs.webkit.org/show_bug.cgi?id=235447 Reviewed by Antti Koivisto. Source/WebCore: We don't normally submit inline boxes with content to ubidi re-ordering since their content drives the visual position unless they are empty. While empty inline boxes do not usually produce visual artifacts (except ones with decoration) they still need to be able to answer "bounding box" type of questions. So in order to have geometry generated for inline boxes, they either 1, need to have some content so that while processing their content, we also compute their geometries 2, have to participate in ubidi's visual re-ordering so that they show up in the visual list (which is the input to the display box create function) This patch treats inline boxes with fully collapsible content empty so that they fall into group #2. * layout/formattingContexts/inline/InlineItemsBuilder.cpp: (WebCore::Layout::InlineItemsBuilder::breakAndComputeBidiLevels): LayoutTests: * TestExpectations: Canonical link: https://commits.webkit.org/246272@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@288371 268f45cc-cd09-0410-ab3c-d52691b4dbfc

…ed underneath -[UIWindow dealloc] https://bugs.webkit.org/show_bug.cgi?id=237505 rdar://85563958 Reviewed by Tim Horton. Source/WebKit: It's currently possible for the web page to get permanently stuck in frozen state, due to the `BackgroundApplication` layer tree freeze reason; this occurs when the web view is unparented from the view hierarchy underneath the scope of UIWindow's `-dealloc` method. During `-[UIWindow dealloc]`, the backpointer underlying the implementation of `-[UIView window]` is set to `nil` immediately before the subclassing method hook `-willMoveToWindow:` is invoked on the view hierarchy. This means that when `-willMoveToWindow:` is invoked, `self.window` will return `nil`. This, in turn, puts `WKApplicationStateTrackingView` in a bad state because we bail early before resetting `_applicationStateTracker` in the early return below, since we (erroneously) believe that we've already been unparented from the view hierarchy, so we don't need to do anything. ``` if (!self._contentView.window || newWindow) return; ``` As a result, if the same web view is eventually moved back into another visible window, `-didMoveToWindow` bails before setting up the `_applicationStateTracker` again, since it already exists from when the previous window was still active. This means `-_applicationWillEnterForeground` is never called when the web view is reintroduced to the view hierarchy, so `LayerTreeFreezeReason::BackgroundApplication` is never lifted. To address this, we simply remove the debug assertion for `_applicationStateTracker`, and instead check whether the application state tracker exists or not for the logic of the early return. Doing so also makes the early return in `-willMoveToWindow:` consistent with the logic in one in `-didMoveToWindow`, which already consults `_applicationStateTracker`: ``` - (void)didMoveToWindow { if (!self._contentView.window || _applicationStateTracker) return; ``` Test: ApplicationStateTracking.WindowDeallocDoesNotPermanentlyFreezeLayerTree * UIProcess/ios/WKApplicationStateTrackingView.mm: (-[WKApplicationStateTrackingView willMoveToWindow:]): See above. Tools: Add an API test to exercise the bug. This API test is comprised of the following series of steps: 1. Create the web view and add it under window #1. 2. Post a "did enter background" notification. 3. Deallocate window #1 (thereby unparenting the web view in the process). 4. Post a "will enter foreground" notification. 5. Add the web view under window #2. 6. Load some HTML content and wait for a presentation update. Before the fix, this test times out because the layer tree is permanently frozen after step (3), due to the `BackgroundApplication` reason, so the presentation update in step (6) never finishes. * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/ios/ApplicationStateTracking.mm: Added. (TestWebKitAPI::TEST): Canonical link: https://commits.webkit.org/248106@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@290875 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=237630 rdar://88690874 Reviewed by Jer Noble. Source/WebCore: Data cues have a start time but not an explicit duration, a data cue ends when the next data cue from the same track starts. This means we don’t know the duration of cue #1 until cue #2 is delivered, so when cue #1 is delivered it is given the end time of the media file’s duration and the actual end time is updated when cue #2 arrives. http://webkit.org/b/229924 refactored text, audio, and video tracks to not depend on HTMLMediaElement. Because InbandDataTextTrack could no longer access the HTMLMediaElement to get its duration, a duration property was added to TextTrackList that InbandDataTextTrack uses to set the duration of temporary cues. TextTrackList.duration is set when it is created and updated when the media player reports a duration change. This means that if the media file’s duration is not known when the text track list is created, and the file's duration never changes, the text track list never has a valid duration and data cues were not added to the temporary list. Fix this by updating TextTrackList.duration when a HTMLMediaElement reaches HAVE_METADATA. Test: http/tests/media/hls/track-in-band-hls-metadata-cue-duration.html * html/HTMLMediaElement.cpp: (WebCore::HTMLMediaElement::durationChanged): Update m_textTracks.duration and post the 'durationchange' event. (WebCore::HTMLMediaElement::setReadyState): Call durationChanged. (WebCore::HTMLMediaElement::mediaPlayerDurationChanged): Ditto. * html/HTMLMediaElement.h: * html/track/InbandDataTextTrack.cpp: (WebCore::InbandDataTextTrack::addDataCue): Add cues to the incomplete cue map even if the track list doesn't have duration. LayoutTests: * http/tests/media/hls/track-in-band-hls-metadata-cue-duration-expected.txt: Added. * http/tests/media/hls/track-in-band-hls-metadata-cue-duration.html: Added. Canonical link: https://commits.webkit.org/248203@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@291029 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=240256 <rdar://problem/92982358> Unreviewed follow-up fix. * Scripts/webkitpy/common/checkout/scm/git.py: (Git.create_patch): Allow caller to exclude commit message, run `git diff` against HEAD by default to include both staged and unstaged changes. * Scripts/webkitpy/common/checkout/scm/scm.py: (SCM.create_patch): Match function signature for git. * Scripts/webkitpy/common/checkout/scm/scm_mock.py: (MockSCM.create_patch): Match function signature for git. * Scripts/webkitpy/common/checkout/scm/svn.py: (SVN.create_patch): Match function signature for git. * Scripts/webkitpy/w3c/test_exporter.py: (WebPlatformTestExporter._wpt_patch): Exclude commit message since we won't be able to classify it's file. * Scripts/webkitpy/w3c/test_exporter_unittest.py: (TestExporterTest.MockGit.create_patch): Match function signature for git. Canonical link: https://commits.webkit.org/250570@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@294212 268f45cc-cd09-0410-ab3c-d52691b4dbfc

…ting layers https://bugs.webkit.org/show_bug.cgi?id=241874 Reviewed by Simon Fraser. addLayers stops (recursive) descending in the render tree soon after it finds a root (R) with layer. It says that if a subtree root (R) has a layer then all layers in this subtree must have already been inserted into the layer tree at an earlier time. (it simply assumes that any layer in the subtree is a child of (R), or some other layers in the subtree) <div id=container> <div id=R> <div id=child> The insertion is bottom to top; we attach 1, (child) to (R) first 2, followed by (R) to (container) addLayers assumes that when (R) is being inserted (#2), we don't have to descend into (R)'s subtree since any renderer's layer that was inserted before (at #1) must have already been parented. However toplayer/backdrop content is an exception where the parent layer may be outside of the subtree but still accessible. In such cases subsequent insertions (and the recursive nature of finding layer parents) could lead to double parenting where we try to insert the same layer into the layer tree multiple times. * Source/WebCore/rendering/RenderElement.cpp: (WebCore::addLayers): (WebCore::RenderElement::insertedIntoTree): (WebCore::RenderElement::addLayers): Deleted. * Source/WebCore/rendering/RenderElement.h: Canonical link: https://commits.webkit.org/251772@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@295767 268f45cc-cd09-0410-ab3c-d52691b4dbfc

…ve horizontal margin when text-align has non-initial value. https://bugs.webkit.org/show_bug.cgi?id=242057 <rdar://problem/96060962> Reviewed by Antti Koivisto. In normal cases (assume initial direction/writing mode) 1. the right edge of the content is to the right of the line start 2. "right edge of the content" - "left edge of the content" == content width (essentially content right == content width). <div><img>this content is to the right of the image and the line start</div> However negative horizontal margin may produce a line where the right edge of the content is to the left of the line. <div><img style="margin-right: -1000px">this content is to the left of the image and the line start</div> In such cases the content width is not #2 anymore i.e. negative margin does not shrink the content width (in the above case, the content width is the img width and not 0 or some negative value). This patch ensures that we use the content edge to align the content. * LayoutTests/fast/inline/negative-margin-with-text-align-expected.html: Added. * LayoutTests/fast/inline/negative-margin-with-text-align.html: Added. * Source/WebCore/layout/formattingContexts/inline/InlineLineBoxBuilder.cpp: (WebCore::Layout::horizontalAlignmentOffset): Canonical link: https://commits.webkit.org/251954@main

…a rejected promise https://bugs.webkit.org/show_bug.cgi?id=247785 rdar://102325201 Reviewed by Yusuke Suzuki. Rest parameter should be caught in async function. So, running this JavaScript program should print "caught". ``` async function f(...[[]]) { } f().catch(e => print("caught")); ``` V8 (used console.log) ``` $ node input.js caught ``` GraalJS ``` $ js input.js caught ``` https://tc39.es/ecma262/#sec-async-function-definitions ... AsyncFunctionDeclaration[Yield, Await, Default] : async [no LineTerminator here] function BindingIdentifier[?Yield, ?Await] ( FormalParameters[~Yield, +Await] ) { AsyncFunctionBody } [+Default] async [no LineTerminator here] function ( FormalParameters[~Yield, +Await] ) { AsyncFunctionBody } AsyncFunctionExpression : async [no LineTerminator here] function BindingIdentifier[~Yield, +Await]opt ( FormalParameters[~Yield, +Await] ) { AsyncFunctionBody } ... According to the spec, it indicates `FormalParameters` is used for Async Function, where `FormalParameters` can be converted to `FunctionRestParameter`. https://tc39.es/ecma262/#sec-parameter-lists ... FormalParameters[Yield, Await] : [empty] FunctionRestParameter[?Yield, ?Await] FormalParameterList[?Yield, ?Await] FormalParameterList[?Yield, ?Await] , FormalParameterList[?Yield, ?Await] , FunctionRestParameter[?Yield, ?Await] ... And based on RS: EvaluateAsyncFunctionBody, it will invoke the promise.reject callback function with abrupt value ([[value]] of non-normal completion record). https://tc39.es/ecma262/#sec-runtime-semantics-evaluateasyncfunctionbody ... 2. Let declResult be Completion(FunctionDeclarationInstantiation(functionObject, argumentsList)). 3. If declResult is an abrupt completion, then a. Perform ! Call(promiseCapability.[[Reject]], undefined, « declResult.[[Value]] »). ... In that case, any non-normal results of evaluating rest parameters should be caught and passed to the reject callback function. To resolve this problem, we should allow the emitted RestParameterNode be wrapped by the catch handler for promise. However, we should remove `m_restParameter` and emit rest parameter byte code in `initializeDefaultParameterValuesAndSetupFunctionScopeStack` if we can prove that change has no side effect. In that case, we can only use one exception handler. Current fix is to add another exception handler. And move the handler byte codes to the bottom of code block in order to make other byte codes as much compact as possible. Input: ``` async function f(arg0, ...[[]]) { } f(); ``` Dumped Byte Codes: ``` ... bb#2 Predecessors: [ #1 ] [ 20] mov dst:loc9, src:<JSValue()>(const0) ... bb#3 Predecessors: [ #2 ] [ 29] get_rest_length dst:loc11, numParametersToSkip:1 ... bb#12 Predecessors: [ #8 #9 #10 ] [ 138] new_func_exp dst:loc10, scope:loc4, functionDecl:0 ... bb#13 Predecessors: [ ] [ 170] catch exception:loc10, thrownValue:loc8 [ 174] jmp targetLabel:8(->182) Successors: [ #15 ] bb#14 Predecessors: [ #7 #11 ] [ 176] catch exception:loc10, thrownValue:loc8 [ 180] jmp targetLabel:2(->182) Successors: [ #15 ] bb#15 Predecessors: [ #13 #14 ] [ 182] mov dst:loc12, src:Undefined(const1) ... Exception Handlers: 1: { start: [ 20] end: [ 29] target: [ 170] } synthesized catch 2: { start: [ 29] end: [ 138] target: [ 176] } synthesized catch ``` * JSTests/stress/catch-rest-parameter.js: Added. (throwError): (shouldThrow): (async f): (throwError.async f): (throwError.async let): (async let): (x.async f): (x): (async shouldThrow): * Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack): * Source/JavaScriptCore/bytecompiler/BytecodeGenerator.h: Canonical link: https://commits.webkit.org/256864@main

https://bugs.webkit.org/show_bug.cgi?id=250196 rdar://98798050 Reviewed by Simon Fraser and Dean Jackson. WebKit has long accidentally depended on the combination of two somewhat unusual behavioral quirks in CGIOSurfaceContext: 1) (Source) If you make a CGImageRef from one CGIOSurfaceContext via CGIOSurfaceContextCreateImage, and mutate the original IOSurface under the hood (or in a different process) in a way that CGIOSurfaceContext does not know, CGIOSurfaceContextCreateImage will return the same CGImageRef when called later. 2) (Destination) If you make a CGImageRef from one CGIOSurfaceContext via CGIOSurfaceContextCreateImage, paint it into a different CGIOSurfaceContext, then mutate the original IOSurface, and paint the same CGImageRef again, the updated IOSurface contents will be used the second time. The second quirk has never worked with unaccelerated CoreGraphics bitmap context destinations. Instead, in the unaccelerated case, the CGImageRef acts as a snapshot of the surface at the time it was created. We've long had code to handle this, forcing CGIOSurfaceContextCreateImage to re-create the CGImageRef each time we paint it (by drawing an empty rect into the CGIOSurfaceContext), working around quirk #1 and thus bypassing quirk #2, if we're painting into an unaccelerated backing store. It turns out our CG display list backing store implementation behaves like a CG bitmap context (without quirk #2), and so currently any IOSurfaces painted into CG display list backing store from a CGImageRef created by CGIOSurfaceContextCreateImage (but not -CreateImageReference) become stale if painted multiple times. To avoid this, extend the workaround to apply to any destination context that claims that it needs the workaround, and use it whenever painting an IOSurface into anything other than a CGIOSurfaceContext. * Source/WebCore/platform/graphics/BifurcatedGraphicsContext.cpp: (WebCore::BifurcatedGraphicsContext::needsCachedNativeImageInvalidationWorkaround): * Source/WebCore/platform/graphics/BifurcatedGraphicsContext.h: Make BifurcatedGraphicsContext assume the more conservative mode of its two children. * Source/WebCore/platform/graphics/GraphicsContext.h: (WebCore::GraphicsContext::needsCachedNativeImageInvalidationWorkaround): Assume that by default, GraphicsContexts need the workaround. * Source/WebCore/platform/graphics/cg/GraphicsContextCG.cpp: (WebCore::GraphicsContextCG::needsCachedNativeImageInvalidationWorkaround): * Source/WebCore/platform/graphics/cg/GraphicsContextCG.h: GraphicsContextCG needs the workaround, except in the IOSurface->IOSurface case. * Source/WebCore/platform/graphics/cg/ImageBufferIOSurfaceBackend.cpp: (WebCore::ImageBufferIOSurfaceBackend::finalizeDrawIntoContext): Confer with the GraphicsContext about its need for the workaround instead of hardcoding the behavior here. * Source/WebKit/Shared/RemoteLayerTree/CGDisplayListImageBufferBackend.mm: CG display list graphics contexts need the workaround. Canonical link: https://commits.webkit.org/258586@main

https://bugs.webkit.org/show_bug.cgi?id=251063 rdar://104585575 Reviewed by Mark Lam and Justin Michaud. This patch enhances CallFrame::dump to support wasm frames in btjs stacktrace. The example is as follows. frame #0: 0x00000001035fca78 JavaScriptCore`JSC::functionBreakpoint(globalObject=0x000000012f410068, callFrame=0x000000016fdfa9d0) at JSDollarVM.cpp:2273:9 [opt] frame #1: 0x000000010ec44204 0x10eccc5dc frame #2: 0x000000010eccc5dc callback#Dwaxn6 [Baseline bc#50](Undefined) frame #3: 0x000000010ec4ca84 wasm-stub [WasmToJS](Wasm::Instance: 0x10d29da40) frame #4: 0x000000010ed0c060 <?>.wasm-function[1] [OMG](Wasm::Instance: 0x10d29da40) frame #5: 0x000000010ed100d0 jsToWasm#CWTx6k [FTL bc#22](Cell[JSModuleEnvironment]: 0x12f524540, Cell[WebAssemblyFunction]: 0x10d06a3a8, 1, 2, 3) frame #6: 0x000000010ec881b0 #D5ymZE [Baseline bc#733](Undefined, Cell[Generator]: 0x12f55c180, 1, Cell[Object]: 0x12f69dfc0, 0, Cell[JSLexicalEnvironment]: 0x12f52cee0) frame #7: 0x000000010ec3c008 asyncFunctionResume#A4ayYg [LLInt bc#49](Undefined, Cell[Generator]: 0x12f55c180, Cell[Object]: 0x12f69dfc0, 0) frame #8: 0x000000010ec3c008 promiseReactionJobWithoutPromise#D0yDF1 [LLInt bc#25](Undefined, Cell[Function]: 0x12f44f3c0, Cell[Object]: 0x12f69dfc0, Cell[Generator]: 0x12f55c180) frame #9: 0x000000010ec80ec0 promiseReactionJob#EdShZz [Baseline bc#74](Undefined, Undefined, Cell[Function]: 0x12f44f3c0, Cell[Object]: 0x12f69dfc0, Cell[Generator]: 0x12f55c180) frame #10: 0x000000010ec3c728 frame #11: 0x0000000103137560 JavaScriptCore`JSC::Interpreter::executeCall(JSC::JSGlobalObject*, JSC::JSObject*, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) [inlined] JSC::JITCode::execute(this=<unavailable>, vm=<unavailable>, protoCallFrame=<unavailable>) at JITCodeInlines.h:42:38 [opt] frame #12: 0x0000000103137524 JavaScriptCore`JSC::Interpreter::executeCall(this=<unavailable>, lexicalGlobalObject=<unavailable>, function=<unavailable>, callData=<unavailable>, thisValue=<unavailable>, args=<unavailable>) at Interpreter.cpp:1093:27 [opt] frame #13: 0x000000010349d6d0 JavaScriptCore`JSC::runJSMicrotask(globalObject=0x000000012f410068, identifier=(m_identifier = 81), job=JSValue @ x22, argument0=JSValue @ x26, argument1=JSValue @ x25, argument2=<unavailable>, argument3=<unavailable>) at JSMicrotask.cpp:98:9 [opt] frame #14: 0x00000001039dfc54 JavaScriptCore`JSC::VM::drainMicrotasks() (.cold.1) at VM.cpp:0:9 [opt] frame #15: 0x00000001035e58a4 JavaScriptCore`JSC::VM::drainMicrotasks() [inlined] JSC::MicrotaskQueue::dequeue(this=<unavailable>) at VM.cpp:0:9 [opt] frame #16: 0x00000001035e5894 JavaScriptCore`JSC::VM::drainMicrotasks(this=0x000000012f000000) at VM.cpp:1255:46 [opt] ... * Source/JavaScriptCore/interpreter/CallFrame.cpp: (JSC::CallFrame::dump const): Canonical link: https://commits.webkit.org/259262@main

https://bugs.webkit.org/show_bug.cgi?id=252379 <rdar://104303475> Reviewed by Antti Koivisto. While display boxes are positioned based on margin boxes, the left/right side of a display box do not include these margins. e.g. [display box #1]<- 100px margin ->[display box #2] width: 50px width: 50px margin-right: 100px; display box #1's right: 50px display box #2's left: 150px This patch makes sure when we place an out-of-flow box next to display box #1, we put it at 150px and not at 50px. * LayoutTests/fast/inline/out-of-flow-inline-with-previous-next-margin-expected.html: Added. * LayoutTests/fast/inline/out-of-flow-inline-with-previous-next-margin.html: Added. * Source/WebCore/layout/formattingContexts/inline/InlineFormattingGeometry.cpp: (WebCore::Layout::InlineFormattingGeometry::staticPositionForOutOfFlowInlineLevelBox const): Canonical link: https://commits.webkit.org/260380@main

https://bugs.webkit.org/show_bug.cgi?id=252824 rdar://105833316 Reviewed by Keith Miller. Every function starts with the same 3 opcodes: ``` op_enter op_get_scope loc4 op_check_traps ``` This patch changes `op_enter` to also get the scope and checks for VM traps. This reduces the prologue overhead by 3 bytes. The one complication is recursive tail calls. Previously we inserted a basic block right after op_enter, and recursive tail calls entered at opcode #2 (op_get_scope). Now, in DFG, we have to enter in the middle of op_enter, which is fine, but we can no longer lazily search for the basic block when we detect a recursive tail call, so we keep track of the target block for recursive tail calls in InlineStackEntry. * Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::allocateScope): (JSC::BytecodeGenerator::allocateAndEmitScope): Deleted. * Source/JavaScriptCore/bytecompiler/BytecodeGenerator.h: * Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleRecursiveTailCall): (JSC::DFG::ByteCodeParser::handleGetScope): (JSC::DFG::ByteCodeParser::handleCheckTraps): (JSC::DFG::ByteCodeParser::parseBlock): * Source/JavaScriptCore/jit/JIT.cpp: (JSC::JIT::privateCompileSlowCases): * Source/JavaScriptCore/jit/JIT.h: * Source/JavaScriptCore/jit/JITOpcodes.cpp: (JSC::JIT::emitGetScope): (JSC::JIT::emitCheckTraps): (JSC::JIT::emit_op_enter): (JSC::JIT::emit_op_get_scope): (JSC::JIT::emit_op_check_traps): (JSC::JIT::emitSlow_op_enter): * Source/JavaScriptCore/llint/LowLevelInterpreter.asm: * Source/JavaScriptCore/llint/LowLevelInterpreter64.asm: * Source/JavaScriptCore/runtime/CommonSlowPaths.cpp: (JSC::JSC_DEFINE_COMMON_SLOW_PATH): Canonical link: https://commits.webkit.org/260787@main

https://bugs.webkit.org/show_bug.cgi?id=270565 rdar://problem/124126629 Reviewed by Antti Koivisto Contains upstream commits: git log --oneline acba61cb3e27f15b56ca781813efa357b9ca0f1f..b2773c110f641869afbb1e3b2ae4651dcfd1b1b2 --pretty=%h %s b2773c110f Vulkan: Bug fix in immutable sampler pipeline layout recreation 3c08d69612 CL: Add DEVICE_NOT_FOUND case for context creation f044aaf821 Vulkan: Create instance/device without access to Display 47cd0529f1 Fix assert invoking #line during macro invocation 27423bffff Metal: Generate names for rewritten inputs 2ad7b23b13 Add a missing #include. 545e3f6e11 Vulkan: Decouple RendererVk from egl::BlobCache 95294b2468 Android: Add Galaxy S22 support (Xclipse) 5678ad09aa Roll Chromium from 43d81add625d to 632158ced47e (570 revisions) 0ad73958dc Deduplicate and fix ConstStrLen implementations 258b751f57 OpenCL/Vulkan: Fix processedOptions whitespace b978974d98 Update frontend support for QCOM foveated extensions 3fa8d578ad Make appendDecimal use the last char of the buffer 39040b0b89 Vulkan: Decouple RendererVk from EGL attributes 4e6fe5e0db Vulkan: Cache ImageLoadContext in context 871a309c72 Fix layout(index=) parse assert on es 100 shaders ec6d628863 egl: Add logic to select preferred display 799997d427 Roll Chromium from 40412b90c691 to 43d81add625d (324 revisions) fc440afa62 Vulkan: Move DS builder class to Vk utils f85b6970a9 OpenCL/Vulkan: Implement program get[Build]Info 0ed0de4f0b OpenCL/Vulkan: Add initial program build support 1c2d2417c9 Bugfix in CreateWithEGLConfig1010102Support test f26c8d0874 Roll VK-GL-CTS from d023c17ac299 to 1918ab4d4806 (13 revisions) 21381f5e1c Roll Chromium from 6b34297e693d to 40412b90c691 (533 revisions) 2ee295b475 Vulkan: Add per-level image update tracker 1ceddbf697 OpenCL/Vulkan: Add createProgram routines f7cd1c5606 Tests: Add Toca Life World trace 56a291e819 Rework external image capture 8142dde7f4 Tests: Add Pokemon Masters Ex trace b45b350ade Add skip for Pokemon Masters Ex validation warning 69f5e9ca60 Roll vulkan-deps from f43c5512f6d7 to 12f9cddb3ff7 (6 revisions) 19e725e49c Roll Chromium from 579e74402476 to 6b34297e693d (578 revisions) 4d36224267 Vulkan: Remove call to angle::GetSystemInfo() cdf6220c28 Reland "Vulkan: Feature addition for QCOM foveated rendering extensions" a971e5b42e Account for zero vector axes in Mat4::Rotate(...) 434a5b0170 Fix #2 upload_results_to_perf_dashboard usage 057db6ef57 Add ANGLE experimental S22 build and test f8dac42e95 Fix upload_results_to_perf_dashboard usage dbbcf33eeb Roll vulkan-deps from 28960bf4a098 to f43c5512f6d7 (13 revisions) d334a6f265 Roll Chromium from cc3c5664ec19 to 579e74402476 (619 revisions) a627dd8976 Revert "Vulkan: Feature addition for QCOM foveated rendering extensions" 6eaaad7c60 Create ImageHelper. 75c8ef1c63 Update cached component type masks on attachment redefinitions 6f2daf0588 Context: Limit max vtx uniform vectors to 256 during capture 2fb425d284 Roll vulkan-deps from dd6c2371c85d to 28960bf4a098 (10 revisions) b0215166ed Roll SwiftShader from 0f69b790c7a4 to bbe6452b420c (1 revision) 9100f2ec79 Roll Chromium from 16b5225bad88 to cc3c5664ec19 (580 revisions) f0af4730d9 Vulkan: Catch misuse of AddToPNextChain 72cf9915f5 Vulkan: Feature addition for QCOM foveated rendering extensions 0afcac60ed Handle count = 0 in DrawElementsIndirect 3c517e457a Vulkan: Process ClearEmulatedChannels update first 38cc4cf099 Vulkan: Update flushStagedUpdate to use switchcase 58c20052bb Fix build error when git history not fully available d354c4dca1 Roll VK-GL-CTS from d15e5faec700 to d023c17ac299 (1 revision) 425be99db6 Roll vulkan-deps from 602ab4120d74 to dd6c2371c85d (8 revisions) 1fe63fecab Roll SwiftShader from eb75201a4e03 to 0f69b790c7a4 (1 revision) 834ca37fa6 Roll Chromium from b54ff9b1d5ed to 16b5225bad88 (644 revisions) Canonical link: https://commits.webkit.org/275754@main

…/setrequestheader-case-insensitive.htm is a constant failure (attempt #2) https://bugs.webkit.org/show_bug.cgi?id=273498 rdar://127299045 Reviewed by Anne van Kesteren and Sam Sneddon. Second attempt. This change modifies the test such that it now only compares the relevant header substrings, instead of matching the entire header content. * LayoutTests/imported/w3c/web-platform-tests/xhr/setrequestheader-case-insensitive-expected.txt: * LayoutTests/imported/w3c/web-platform-tests/xhr/setrequestheader-case-insensitive.htm: Canonical link: https://commits.webkit.org/278282@main

…n site-isolation rdar://127515199 https://bugs.webkit.org/show_bug.cgi?id=273715 Unreviewed test gardening. * LayoutTests/platform/mac-site-isolation/TestExpectations: Canonical link: https://commits.webkit.org/278367@main

…volume scrubber on a video player https://bugs.webkit.org/show_bug.cgi?id=275469 <rdar://129080145> Reviewed by Antti Koivisto. 1. In EventHandler::mouseDragged we dispatch the "mouse move" event 2. JS triggers some mutation which makes the tree dirty 3. later in EventHandler::handleMouseMoveEvent() we call EventHandler::handleMouseDraggedEvent() (tree is dirty) which, through a few layers of functions calls VisiblePosition::canonicalPosition() 4. VisiblePosition::canonicalPosition() needs a clean tree so it calls Document::updateLayout() which is turn destroys some renderers (see #2) 5. In-between EventHandler::handleMouseDraggedEvent() and VisiblePosition::canonicalPosition(), we CheckPtr a renderer which gets destroyed at #4. The fix (what we normally do with cases like this) is to make sure we clean the tree before entering VisiblePosition. * Source/WebCore/page/EventHandler.cpp: (WebCore::EventHandler::handleMouseDraggedEvent): Canonical link: https://commits.webkit.org/280013@main

…terpolate https://bugs.webkit.org/show_bug.cgi?id=275993 rdar://130704075 Reviewed by Matt Woodrow. We had three separate issues that would lead us to visually animate when one of the values in a given interval is a non-invertible matrix: 1. The method that determines whether it's possible to interpolate between two `transform` values would only account for `matrix()` values and not `matrix3d()`. 2. The `transform` property animation wrapper would not implement the `canInterpolate()` method and would thus always indicate that two `transform` values could be interpolated. This caused CSS Transitions to run even when the values would not a discrete interpolation. 3. Even if we correctly determined that two `transform` values should yield discrete interpolation, we would delegate an accelerated animation to Core Animation and that animation's behavior would differ an visibly interpolate. In this patch, we fill all three issues. First, we introduce a new `TransformOperations::containsNonInvertibleMatrix()` method which will check whether a `matrix()` or `matrix3d()` value that is not invertible is contained in the list of transform operations. We now use this function in `TransformOperations::shouldFallBackToDiscreteAnimation()` to address issue #1. Then, we add a `canInterpolate()` implementation to `AcceleratedTransformOperationsPropertyWrapper` which calls in the now-correct `TransformOperations::shouldFallBackToDiscreteAnimation()` to address issue #2. Finally, we add a new flag on `BlendingKeyframes` to determine whether a keyframe contains a `transform` value with a non-invertible matrix and we consult that flag in `KeyframeEffect::canBeAccelerated()` to determine whether an animation should be delegated to Core Animation, addressing issue #3. We add new WPT tests to check the correct interpolation behavior of `transform` when a non-invertible `matrix3d()` value is used, that no CSS Transition can be started with such a value, and finally that no animation is visibly run to catch the Core Animation case. * LayoutTests/imported/w3c/web-platform-tests/css/css-transforms/animation/transform-interpolation-007-expected.txt: Added. * LayoutTests/imported/w3c/web-platform-tests/css/css-transforms/animation/transform-interpolation-007.html: Added. * LayoutTests/imported/w3c/web-platform-tests/css/css-transforms/animation/transform-non-invertible-discrete-interpolation-expected.html: Added. * LayoutTests/imported/w3c/web-platform-tests/css/css-transforms/animation/transform-non-invertible-discrete-interpolation-ref.html: Added. * LayoutTests/imported/w3c/web-platform-tests/css/css-transforms/animation/transform-non-invertible-discrete-interpolation.html: Added. * LayoutTests/imported/w3c/web-platform-tests/css/css-transforms/animation/transform-non-invertible-no-transition-expected.txt: Added. * LayoutTests/imported/w3c/web-platform-tests/css/css-transforms/animation/transform-non-invertible-no-transition.html: Added. * Source/WebCore/animation/BlendingKeyframes.cpp: (WebCore::BlendingKeyframes::analyzeKeyframe): * Source/WebCore/animation/BlendingKeyframes.h: (WebCore::BlendingKeyframes::hasDiscreteTransformInterval const): * Source/WebCore/animation/CSSPropertyAnimation.cpp: * Source/WebCore/animation/KeyframeEffect.cpp: (WebCore::KeyframeEffect::canBeAccelerated const): * Source/WebCore/platform/graphics/transforms/TransformOperations.cpp: (WebCore::TransformOperations::containsNonInvertibleMatrix const): (WebCore::TransformOperations::shouldFallBackToDiscreteAnimation const): * Source/WebCore/platform/graphics/transforms/TransformOperations.h: Canonical link: https://commits.webkit.org/280466@main

https://bugs.webkit.org/show_bug.cgi?id=276288 Reviewed by Antti Koivisto. RenderSlider::computeIntrinsicLogicalWidths should check against _logical_ width value. * LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/flex-item-compressible-002-expected.txt: * Source/WebCore/rendering/RenderSlider.cpp: (WebCore::RenderSlider::computeIntrinsicLogicalWidths const): Canonical link: https://commits.webkit.org/280718@main

…text run https://bugs.webkit.org/show_bug.cgi?id=277716 rdar://133309470 Reviewed by Matthieu Dubet. This patch implements the processing of text-autospace: ideogram-alpha only within an element. We don't yet handle element boundaries here. Although we pass SpacingState context from one ComplexTextController to another, we do that here in a limited way, only for measuring text for layout and for painting. There are other places in code which this will be necessary, for example, for handling element boundaries. 1. During the construction of ComplexTextController, we call ::adjustGlyphsAndAdvances which already iterates through glyphs and adjust spacing for other reasons. Now we process each pair of characters related to these glyphs here, adding the spacing necessary before the "current" character. For that reason, the SpacingState stores information about the previous character of a run. We also save the measured spacing in a new parallel vector m_textAutoSpaceSpacings. At this phase we can only manipulate a glyph advance, however, for adding space "before" a glyph, we need to move the glyph to the logical right, which is done later on ::advance. 2. ComplexTextController::advance is called for both layout and painting, but during painting it has access to a GlyphBuffer and it add glyphs into it. We are introducing a new GlyphBuffer::add function that also takes the glyph's origin, so we can manipulate the origin as necessary by adding the previous calculated spacing. 3. Doing #1 and #2 is already enough for painting the extra spacing between relevant characters according to their classes. Howeverm the width measured during layout would be broken because IFC splits text content into inlineTextItem(s) and measure the width of each item independently. This means that we already have to handle SpacingState passing here, otherwise we are not able to handle spacing between characters on the boundary of different InlineTextItem. * LayoutTests/imported/w3c/web-platform-tests/css/css-text/text-autospace/text-autospace-ideogram-alpha-001-expected.html: Added. * LayoutTests/imported/w3c/web-platform-tests/css/css-text/text-autospace/text-autospace-ideogram-alpha-001-ref.html: Added. * LayoutTests/imported/w3c/web-platform-tests/css/css-text/text-autospace/text-autospace-ideogram-alpha-001.html: Added. * Source/WTF/wtf/text/CharacterProperties.h: (WTF::isPunctuation): (WTF::isOpeningPunctuation): (WTF::isClosingPunctuation): (WTF::isOfScriptType): (WTF::eastAsianWidth): (WTF::isEastAsianFullWidth): (WTF::isCJKSymbolOrPunctuation): * Source/WebCore/Sources.txt: * Source/WebCore/WebCore.xcodeproj/project.pbxproj: * Source/WebCore/layout/formattingContexts/inline/InlineItemsBuilder.cpp: (WebCore::Layout::InlineItemsBuilder::computeInlineTextItemWidths): * Source/WebCore/layout/formattingContexts/inline/text/TextUtil.cpp: (WebCore::Layout::TextUtil::width): * Source/WebCore/layout/formattingContexts/inline/text/TextUtil.h: (WebCore::Layout::TextUtil::width): * Source/WebCore/platform/graphics/ComplexTextController.cpp: (WebCore::ComplexTextController::ComplexTextController): (WebCore::ComplexTextController::advance): (WebCore::ComplexTextController::adjustGlyphsAndAdvances): (WebCore::ComplexTextController::ComplexTextRun::ComplexTextRun): * Source/WebCore/platform/graphics/ComplexTextController.h: (WebCore::ComplexTextController::ComplexTextRun::textAutospaceSize const): * Source/WebCore/platform/graphics/FontCascade.cpp: (WebCore::FontCascade::width const): (WebCore::FontCascade::codePath const): * Source/WebCore/platform/graphics/GlyphBuffer.h: (WebCore::GlyphBuffer::add): * Source/WebCore/platform/graphics/TextRun.cpp: * Source/WebCore/platform/graphics/TextRun.h: * Source/WebCore/platform/graphics/WidthCache.h: (WebCore::WidthCache::add): (WebCore::WidthCache::invalidateCacheForTextSpacing): * Source/WebCore/platform/graphics/harfbuzz/ComplexTextControllerHarfBuzz.cpp: (WebCore::ComplexTextController::ComplexTextRun::ComplexTextRun): * Source/WebCore/platform/graphics/mac/ComplexTextControllerCoreText.mm: (WebCore::ComplexTextController::ComplexTextRun::ComplexTextRun): * Source/WebCore/platform/graphics/skia/ComplexTextControllerSkia.cpp: (WebCore::ComplexTextController::ComplexTextRun::ComplexTextRun): * Source/WebCore/platform/text/TextSpacing.cpp: Added. (WebCore::TextAutospace::shouldApplySpacing const): (WebCore::TextAutospace::textAutospaceSize): (WebCore::TextSpacing::isIdeograph): (WebCore::TextSpacing::isNonIdeographicNumeral): (WebCore::TextSpacing::characterClass): * Source/WebCore/platform/text/TextSpacing.h: (WebCore::TextAutospace::hasIdeographAlpha const): (WebCore::TextAutospace::hasIdeographNumeric const): Canonical link: https://commits.webkit.org/282192@main

…text run https://bugs.webkit.org/show_bug.cgi?id=277716 rdar://133309470 Reviewed by Matthieu Dubet. We are relanding this patch as its first version was reverted due to performance reasons. On the current iteration we are avoiding classifying characters when not needed (text-autospace: no-autospace). We also won't keep the parralel vector for the added spacing in such a case. Original patch description: This patch implements the processing of text-autospace: ideogram-alpha only within an element. We don't yet handle element boundaries here. Although we pass SpacingState context from one ComplexTextController to another, we do that here in a limited way, only for measuring text for layout and for painting. There are other places in code which this will be necessary, for example, for handling element boundaries. 1. During the construction of ComplexTextController, we call ::adjustGlyphsAndAdvances which already iterates through glyphs and adjust spacing for other reasons. Now we process each pair of characters related to these glyphs here, adding the spacing necessary before the "current" character. For that reason, the SpacingState stores information about the previous character of a run. We also save the measured spacing in a new parallel vector m_textAutoSpaceSpacings. At this phase we can only manipulate a glyph advance, however, for adding space "before" a glyph, we need to move the glyph to the logical right, which is done later on ::advance. 2. ComplexTextController::advance is called for both layout and painting, but during painting it has access to a GlyphBuffer and it add glyphs into it. We are introducing a new GlyphBuffer::add function that also takes the glyph's origin, so we can manipulate the origin as necessary by adding the previous calculated spacing. 3. Doing #1 and #2 is already enough for painting the extra spacing between relevant characters according to their classes. Howeverm the width measured during layout would be broken because IFC splits text content into inlineTextItem(s) and measure the width of each item independently. This means that we already have to handle SpacingState passing here, otherwise we are not able to handle spacing between characters on the boundary of different InlineTextItem. * Source/WTF/wtf/text/CharacterProperties.h: (WTF::isPunctuation): (WTF::isOpeningPunctuation): (WTF::isClosingPunctuation): (WTF::isOfScriptType): (WTF::eastAsianWidth): (WTF::isEastAsianFullWidth): (WTF::isCJKSymbolOrPunctuation): * Source/WebCore/Sources.txt: * Source/WebCore/WebCore.xcodeproj/project.pbxproj: * Source/WebCore/layout/formattingContexts/inline/InlineItemsBuilder.cpp: (WebCore::Layout::InlineItemsBuilder::computeInlineTextItemWidths): * Source/WebCore/layout/formattingContexts/inline/text/TextUtil.cpp: (WebCore::Layout::TextUtil::width): * Source/WebCore/layout/formattingContexts/inline/text/TextUtil.h: (WebCore::Layout::TextUtil::width): * Source/WebCore/platform/graphics/ComplexTextController.cpp: (WebCore::ComplexTextController::ComplexTextController): (WebCore::ComplexTextController::advance): (WebCore::ComplexTextController::adjustGlyphsAndAdvances): (WebCore::ComplexTextController::ComplexTextRun::ComplexTextRun): * Source/WebCore/platform/graphics/ComplexTextController.h: (WebCore::ComplexTextController::ComplexTextRun::textAutospaceSize const): * Source/WebCore/platform/graphics/FontCascade.cpp: (WebCore::FontCascade::width const): (WebCore::FontCascade::codePath const): * Source/WebCore/platform/graphics/GlyphBuffer.h: (WebCore::GlyphBuffer::add): * Source/WebCore/platform/graphics/TextRun.cpp: * Source/WebCore/platform/graphics/TextRun.h: * Source/WebCore/platform/graphics/WidthCache.h: (WebCore::WidthCache::add): (WebCore::WidthCache::invalidateCacheForTextSpacing): * Source/WebCore/platform/graphics/coretext/ComplexTextControllerCoreText.mm: (WebCore::ComplexTextController::ComplexTextRun::ComplexTextRun): * Source/WebCore/platform/graphics/harfbuzz/ComplexTextControllerHarfBuzz.cpp: (WebCore::ComplexTextController::ComplexTextRun::ComplexTextRun): * Source/WebCore/platform/graphics/skia/ComplexTextControllerSkia.cpp: (WebCore::ComplexTextController::ComplexTextRun::ComplexTextRun): * Source/WebCore/platform/text/TextSpacing.cpp: Added. (WebCore::TextAutospace::shouldApplySpacing const): (WebCore::TextAutospace::textAutospaceSize): (WebCore::TextSpacing::isIdeograph): (WebCore::TextSpacing::isNonIdeographicNumeral): (WebCore::TextSpacing::characterClass): * Source/WebCore/platform/text/TextSpacing.h: (WebCore::TextAutospace::hasIdeographAlpha const): (WebCore::TextAutospace::hasIdeographNumeric const): Canonical link: https://commits.webkit.org/282511@main

…r_ overflow https://bugs.webkit.org/show_bug.cgi?id=279486 Reviewed by Antti Koivisto. Let's call 1. lastHyphenPosition when we are dealing with the non-overflowing runs (this is when we can't break the overflowing part of the content and try to break runs _before_ the overflowing point). Since these runs are not overflowing, we should simply pick the last hyphenation position. 2. firstHyphenPosition when even the first hyphenation would produce overflowing content (e.g. minimum-content with computation) 3. hyphenPositionBefore when dealing with normal overflowing breaking (neither #1 nor #2) * LayoutTests/fast/inline/overflowing-content-with-hypens-expected.html: Added. * LayoutTests/fast/inline/overflowing-content-with-hypens.html: Added. * Source/WebCore/layout/formattingContexts/inline/InlineContentBreaker.cpp: (WebCore::Layout::firstTextRunIndex): (WebCore::Layout::InlineContentBreaker::processOverflowingContent const): (WebCore::Layout::limitBeforeValue): (WebCore::Layout::limitAfterValue): (WebCore::Layout::hasEnoughContentForHyphenation): (WebCore::Layout::firstHyphenPosition): (WebCore::Layout::lastHyphenPosition): (WebCore::Layout::hyphenPositionBefore): (WebCore::Layout::InlineContentBreaker::tryBreakingTextRun const): (WebCore::Layout::InlineContentBreaker::tryHyphenationAcrossOverflowingInlineTextItems const): (WebCore::Layout::hyphenPosition): Deleted. Canonical link: https://commits.webkit.org/283528@main

@0

…ter follows to the same value https://bugs.webkit.org/show_bug.cgi?id=279570 rdar://135851156 Reviewed by Keith Miller. Let's consider the following FTL graph. BB#0 @0 = NewObject() Jump #1 BB#1 PutByOffset(@0, 0, @x) Jump #2 BB#2 ... @z = ... @1 = GetByOffset(@x, 0) Branch(@1, #3, #4) BB#3 PutByOffset(@0, 0, @z) Jump #5 BB#4 PutByOffset(@0, 0, @z) Jump #5 BB#5 Jump #2 Now, we would like to eliminate @0 object allocation. And we are computing SSA for pointers of fields of the that object which gets eliminated. Consider about @x's fields' SSA. PutByOffset becomes Def and GetByOffset becomes Use. And the same field will get the same SSA variable. So we first puts Defs and compute Phis based on that. In ObjectAllocationSinking phase, we had a fast path when the both SSA variable is following to the same value. Let's see BB#5. Because BB#3 and BB#4 defines Defs, dominance frontier BB#5 will need to introduce Phi. But interestingly, both SSA variable is following to the same @z. As a result, we were not inserting Phi for this case. But this is wrong. Inserted Phi is a Def, and based on that, we will further introduce Phis with that. If we omit inserting Phi in BB#5, we will not insert Phi into BB#2 while BB#2 will merge BB#1's Def And BB#5's Phi's Def. As a result, in BB#2, we think this variable is following to BB#1's Def. But that's wrong and BB#5's Phi exists. This patch removes this fast path to fix the issue. * JSTests/stress/object-allocation-sinking-phi-insertion-for-pointers.js: Added. (Queue): (Queue.prototype.enqueue): (Queue.prototype.dequeue): (i.queue.dequeue): * Source/JavaScriptCore/dfg/DFGObjectAllocationSinkingPhase.cpp: Canonical link: https://commits.webkit.org/283558@main

dcrousso and others added 30 commits February 23, 2021 03:34

Versioning.

788a5c8

WebKit-7612.1.6 Canonical link: https://commits.webkit.org/234479@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273321 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Unreviewed Windows test gardening to speed up EWS.

77e8e79

* platform/win/TestExpectations: Canonical link: https://commits.webkit.org/234486@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273334 268f45cc-cd09-0410-ab3c-d52691b4dbfc

pulkomandy closed this Mar 7, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Haiku_newservicekit: Bump to Webkit 612.1.6 #2

Haiku_newservicekit: Bump to Webkit 612.1.6 #2

kenmays commented Feb 24, 2021

Haiku_newservicekit: Bump to Webkit 612.1.6 #2

Haiku_newservicekit: Bump to Webkit 612.1.6 #2

Conversation

kenmays commented Feb 24, 2021