Skip to content

Haiku_newservicekit: Bump to Webkit 612.1.6 #2

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
wants to merge 1,606 commits into from
Closed

Haiku_newservicekit: Bump to Webkit 612.1.6 #2

wants to merge 1,606 commits into from

Conversation

kenmays
Copy link

@kenmays kenmays commented Feb 24, 2021

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

dcrousso and others added 30 commits February 23, 2021 03:34
@dcrousso
[Payment Request] REGRESSION(r273143): crash shortly after showing th…
4fa3540 
…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
@rniwa
REGRESSION (r272928): ASSERT NOT REACHED in WebCore::FrameSelection::…
9e66b40 
…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
@donny-dont
Non-unified build fixes late February 2021 edition
ab7171c 
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
@rniwa
Handle Page::didFinishLoadingImageForElement asynchronously
4c49152 
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
@kkinnunen-apple @webkit-commit-queue
HTMLCanvasElement::copiedImage() contains old image with GPU Process on
ed55694 
https://bugs.webkit.org/show_bug.cgi?id=222101

Patch by Kimmo Kinnunen <[email protected]> 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
Nullptr crash in ModifySelectionListLevelCommand::appendSiblingNodeRange
5a96018 
https://bugs.webkit.org/show_bug.cgi?id=221650

Patch by Frederic Wang <[email protected]> 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
[GTK] Use std::bitset to specify WebKitTestServer's options
ebd5fd3 
https://bugs.webkit.org/show_bug.cgi?id=222273

Patch by Frederic Wang <[email protected]> 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
@pvollan
[macOS] Crash under AuxiliaryProcess::initializeSandbox
3f62ae4 
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
@whsieh
[iOS] Add a watchdog timer to forcibly reset deferring gesture recogn…
f0a32eb 
…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
@dpino
Unreviewed, GTK Ubuntu LTS build fix after r273241
cc3f00c 
* 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
@aoikonomopoulos @webkit-commit-queue
Detect unrecognized options in run-javascriptcore-tests
4d78c26 
https://bugs.webkit.org/show_bug.cgi?id=221186

Patch by Angelos Oikonomopoulos <[email protected]> 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
@cdumez
Use adoptNS() as soon as we [[ObjcClass alloc] init] to avoid leaks i…
6f485d1 
…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
@philn @webkit-commit-queue
[GStreamer] fast/mediastream/captureStream/canvas2d.html is flaky tim…
771abff 
…ing out since GStreamer 1.18 update

https://bugs.webkit.org/show_bug.cgi?id=218580

Patch by Philippe Normand <[email protected]> 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
@donny-dont
Only files in WebCore/testing should be in WebCoreTestSupport
46cd4bf 
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
@calvaris
[GStreamer][EME][Thunder] Initialize decryptor lazily
3b8d65e 
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
@donny-dont
[CMake] Fix JSCOnly build on Windows
cfa7523 
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
@kkinnunen-apple @webkit-commit-queue
REGRESSION(r273204): webkitpy tests fail
c294a4d 
https://bugs.webkit.org/show_bug.cgi?id=222275
<rdar://problem/74614397>

Patch by Kimmo Kinnunen <[email protected]> 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
@rwlbuis @webkit-commit-queue
aspect-ratio shows in computed style when disabled
2ffc057 
https://bugs.webkit.org/show_bug.cgi?id=222286

Patch by Rob Buis <[email protected]> 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
@JonWBedard
show-identifier fails with error: ascii codec can't decode byte 0xc3 …
d003940 
…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
@webkit-commit-queue
Unreviewed, reverting r273307.
967c193 
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
@ryanhaddad
[BigSur] imported/w3c/web-platform-tests/css/css-counter-styles/tibet…
ec6d944 
…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
@webkit-commit-queue
Unreviewed, reverting r273304.
51de385 
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
@rjepstein
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
@fujii
[CoordinatedGraphics] The whole content is unnecessarily repainted by…
56cb90a 
… 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
@fleizach
AX: VoiceOver incorrectly announces groups in ARIA tree instances as …
584f195 
…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
@ntrrgc
Make system console logging synchronous
4834940 
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
Nullptr crash in ReplaceSelectionCommand::removeRedundantStylesAndKee…
5e35b78 
…pStyleSpanInline

https://bugs.webkit.org/show_bug.cgi?id=221651

Patch by Frederic Wang <[email protected]> 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
@donny-dont
Pass full environment when auto installing a Python module on Windows
cd4a9ec 
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
@JonWBedard
[webkitscmpy] Add remote BitBucket
5fc52de 
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
@ryanhaddad
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 pushed a commit that referenced this pull request Mar 5, 2023
@hortont424
Canvases painted into CG display list image buffers don't ever update
7d40f6d 
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
pulkomandy pushed a commit that referenced this pull request Mar 5, 2023
@Constellation
[JSC] Support wasm frames in btjs
560bfa8 
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
pulkomandy pushed a commit that referenced this pull request Mar 7, 2023
@alanbaradlay
REGRESSION (255598@main): checkbox overlaps Log In button on ally.com
3cf4b31 
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
pulkomandy pushed a commit that referenced this pull request Mar 7, 2023
@tadeuzagallo
[JSC] Merge op_enter, op_get_scope and op_check_traps
2699c11 
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
pulkomandy pushed a commit that referenced this pull request Mar 20, 2024
@kkinnunen-apple @ddkilzer
Update ANGLE to 2024-03-06 (b2773c110f641869afbb1e3b2ae4651dcfd1b1b2)
03a094c 
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
pulkomandy pushed a commit that referenced this pull request May 11, 2024
REGRESSION (274826@main): [ iOS ] imported/w3c/web-platform-tests/xhr…
bcd2464 
…/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
pulkomandy pushed a commit that referenced this pull request May 11, 2024
@robert-jenner
[Gardening] [site-isolation] Attempt #2 of enable more tests to run i…
1cf2718 
…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
pulkomandy pushed a commit that referenced this pull request Sep 4, 2024
@alanbaradlay
Crash under RenderObject::createVisiblePosition() while dragging the …
883886e 
…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
pulkomandy pushed a commit that referenced this pull request Sep 4, 2024
@graouts
[web-animations] animation with a non-invertible matrix should not in…
df87a56 
…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
pulkomandy pushed a commit that referenced this pull request Sep 4, 2024
@alanbaradlay
Fix css/css-flexbox/flex-item-compressible-002.html (#2 and #7)
85dbff9 
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
pulkomandy pushed a commit that referenced this pull request Sep 4, 2024
@vitorroriz
text-autospace: implement ideograph-alpha for complex path within an …
44e62df 
…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
pulkomandy pushed a commit that referenced this pull request Sep 5, 2024
@vitorroriz
text-autospace: implement ideograph-alpha for complex path within an …
9a0477f 
…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
pulkomandy pushed a commit that referenced this pull request Sep 28, 2024
@alanbaradlay
[IFC] Incorrect line breaking when hyphen candidate position is _afte…
09aacb0 
…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
pulkomandy pushed a commit that referenced this pull request Sep 28, 2024
@Constellation
[JSC] ObjectAllocationSinking should not omit phi insertion when poin…
ba44420 
…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
pulkomandy pushed a commit that referenced this pull request Nov 29, 2024
@jyavenard
WebCodec's VideoDecoders don't handle colorspace properly
7171070 
https://bugs.webkit.org/show_bug.cgi?id=282741
rdar://139412312

Reviewed by Youenn Fablet.

Pass colorspace information to the created CVPixelBuffer.
We add utility methods to construct the colorspace data from the vpcC box and VPx bytestream
should the information not be provided on construction.

We prefer colorspace information from this source order given colorspace > description data (vpcC) > inband bytestream.

Added tests verifying that black are pure black, and yellow are almost pure yellow with 601 videos and video range.
Technically they should be exactly pure (255, 255, 0), however, compression artifacts with the source makes it not so.

Fly-by #1: m_isClosed can be accessed concurrently on the decoder's or caller's workqueue. Make it atomic.
Fly-by #2: Make relevant members const and add annotation about where some members can be accessed from.

* LayoutTests/media/content/test-h264-601-videorange.mp4: Added.
* LayoutTests/media/content/test-vp8-601-videorange.webm: Added.
* LayoutTests/media/content/test-vp9-601-videorange.webm: Added.
* LayoutTests/media/media-source/media-source-vp8-hiddenframes.html: We can reduce the fuzz range now that both the VT decoder (mac) will return the same colours as VideoDecoder (ios family)
* LayoutTests/media/media-video-fullrange.html: Wait a maximum of 500ms for the promise to be resolved as the rVFC callback may not always be called.
* LayoutTests/media/media-video-videorange-expected.txt: Added.
* LayoutTests/media/media-video-videorange.html: Added.
* LayoutTests/media/media-vp8-hiddenframes.html: We can reduce the fuzz range now that both the VT decoder (mac) will return the same colours as VideoDecoder (ios family)
* LayoutTests/platform/mac-wk1/TestExpectations:
* LayoutTests/platform/wpe/TestExpectations:
* Source/WebCore/Modules/webcodecs/WebCodecsVideoDecoder.cpp:
(WebCore::createVideoDecoderConfig):
* Source/WebCore/platform/VideoDecoder.h:
* Source/WebCore/platform/graphics/VP9Utilities.cpp:
(WebCore::vPCodecConfigurationRecordFromVPXByteStream):
(WebCore::convertToPlatformVideoColorPrimaries):
(WebCore::convertToPlatformVideoTransferCharacteristics):
(WebCore::convertToPlatformVideoMatrixCoefficients):
(WebCore::colorSpaceFromVPCodecConfigurationRecord):
(WebCore::vpcCFromVPXByteStream): Deleted.
* Source/WebCore/platform/graphics/VP9Utilities.h:
* Source/WebCore/platform/graphics/cocoa/CMUtilities.h:
* Source/WebCore/platform/graphics/cocoa/CMUtilities.mm:
(WebCore::convertToCMTransferFunction): Add transfer value for BT601 (smpte170m) which is the same as 709.2 transfer.
(WebCore::attachColorSpaceToPixelBuffer):
* Source/WebCore/platform/graphics/cocoa/VP9UtilitiesCocoa.mm: Move methods to VP9Utilities.cpp
(WebCore::convertToMatrixCoefficients):
(WebCore::createVideoInfoFromVPCodecConfigurationRecord):
(WebCore::convertToPlatformVideoColorPrimaries): Deleted.
(WebCore::convertToPlatformVideoTransferCharacteristics): Deleted.
(WebCore::convertToPlatformVideoMatrixCoefficients): Deleted.
* Source/WebCore/platform/graphics/cocoa/WebCoreDecompressionSession.h:
* Source/WebCore/platform/graphics/cocoa/WebCoreDecompressionSession.mm:
(WebCore::WebCoreDecompressionSession::decodeSampleInternal): Retrieve colorspace from CMSampleBuffer and give it to the decoder initialization.
(WebCore::WebCoreDecompressionSession::enqueueDecodedSample): Fly-by: the last video frame in a webm doesn't have a duration. A logic
error would have caused to never notify the listener that the frame at currentTime had been decoded, leading to the play() promise to never be resolved (nor rVFC callback to be called)
(WebCore::WebCoreDecompressionSession::initializeVideoDecoder):
* Source/WebCore/platform/libwebrtc/LibWebRTCVPXVideoDecoder.cpp:
(WebCore::LibWebRTCVPXInternalVideoDecoder::decode):
(WebCore::LibWebRTCVPXInternalVideoDecoder::LibWebRTCVPXInternalVideoDecoder):
(WebCore::LibWebRTCVPXInternalVideoDecoder::createPixelBuffer):
(WebCore::LibWebRTCVPXInternalVideoDecoder::Decoded):

Canonical link: https://commits.webkit.org/286474@main
pulkomandy pushed a commit that referenced this pull request Nov 29, 2024
@alanbaradlay
[Cleanup][content-visibility] RenderObject::isSkippedContentRoot has …
0fce63b 
…layout dependent state

https://bugs.webkit.org/show_bug.cgi?id=283395

Reviewed by Antti Koivisto.

There are isSkippedContentRoot functions atm.

1. WebCore::isSkippedContentRoot(style, element)
2. and RenderObject::isSkippedContentRoot

(see ContentVisibilityForceLayoutScope, for cases when we need to look inside c-v subtrees for geometry)
and returns false when we are supposed to ignore content-visibility.
This is always scoped to a layout frame (as opposed to painting, hittesting etc)

The codebase is sprinkled with isSkippedContentRoot() calls, some of which exercise #1
while others call into #2 in a seemingly random fashion (e.g. even painting calls the "let's consult the ignore bit" variant).

This patch replaces these 2 functions with
1. LocalFrameViewLayoutContext::isSkippedContentRootForLayout()
2. WebCore::isSkippedContentRoot(renderer)

Where during layout we call layoutContext().isSkippedContentRootForLayout() (surprisingly small number) and the rest simply calls #2.

(Note, there's a highly specific, 3rd use case in StyleAdjuster, which should be moved out to a place where we could use the WebCore::isSkippedContentRoot(renderer) variant).

* Source/WebCore/dom/Document.cpp:
(WebCore::CallbackForContainIntrinsicSize):
(WebCore::Document::caretPositionFromPoint):
* Source/WebCore/editing/TextIterator.cpp:
(WebCore::TextIterator::advance):
* Source/WebCore/page/LocalFrameViewLayoutContext.cpp:
(WebCore::LocalFrameViewLayoutContext::isSkippedContentForLayout const):
(WebCore::LocalFrameViewLayoutContext::isSkippedContentRootForLayout const):
* Source/WebCore/page/LocalFrameViewLayoutContext.h:
* Source/WebCore/rendering/RenderBlock.cpp:
(WebCore::RenderBlock::simplifiedLayout):
(WebCore::RenderBlock::layoutPositionedObject):
(WebCore::RenderBlock::paintContents):
(WebCore::RenderBlock::adjustBorderBoxRectForPainting):
(WebCore::RenderBlock::paintRectToClipOutFromBorder):
(WebCore::RenderBlock::paintExcludedChildrenInBorder):
* Source/WebCore/rendering/RenderBlockFlow.cpp:
(WebCore::RenderBlockFlow::layoutBlockChildren):
* Source/WebCore/rendering/RenderBox.cpp:
(WebCore::RenderBox::foregroundIsKnownToBeOpaqueInRect const):
(WebCore::RenderBox::explicitIntrinsicInnerWidth const):
(WebCore::RenderBox::explicitIntrinsicInnerHeight const):
* Source/WebCore/rendering/RenderElement.cpp:
(WebCore::RenderElement::styleWillChange):
(WebCore::RenderElement::layoutIfNeeded):
(WebCore::RenderElement::isSkippedContentRoot const): Deleted.
* Source/WebCore/rendering/RenderElement.h:
(WebCore::RenderObject::isSkippedContentRoot const): Deleted.
* Source/WebCore/rendering/RenderElementInlines.h:
(WebCore::RenderElement::shouldApplyInlineSizeContainment const):
(WebCore::RenderElement::shouldApplySizeContainment const):
(WebCore::RenderElement::shouldApplySizeOrInlineSizeContainment const):
(WebCore::isSkippedContentRoot):
* Source/WebCore/rendering/RenderGrid.cpp:
(WebCore::RenderGrid::layoutPositionedObject):
* Source/WebCore/rendering/RenderObject.cpp:
(WebCore::RenderObject::isSkippedContentForLayout const): Deleted.
* Source/WebCore/rendering/RenderObject.h:
* Source/WebCore/rendering/RenderObjectInlines.h:
(WebCore::RenderObject::layoutContext const):
* Source/WebCore/rendering/RenderReplaced.cpp:
(WebCore::RenderReplaced::paint):
* Source/WebCore/rendering/RenderWidget.cpp:
(WebCore::RenderWidget::paint):
* Source/WebCore/rendering/style/RenderStyle.h:
* Source/WebCore/rendering/style/RenderStyleInlines.h:
(WebCore::doesSizeContainmentApplyByStyle):
(WebCore::isSkippedContentRoot): Deleted.
* Source/WebCore/rendering/updating/RenderTreeUpdater.cpp:
(WebCore::RenderTreeUpdater::updateElementRenderer):
* Source/WebCore/style/StyleAdjuster.cpp:
(WebCore::Style::Adjuster::adjust const):

Canonical link: https://commits.webkit.org/286858@main
pulkomandy pushed a commit that referenced this pull request Jan 24, 2025
@alanbaradlay
[ iOS Debug ] 3 imported/w3c/web-platform-tests/css/css-contain/conta…
fcca220 
…in-size-replaced-003*.html tests are constantly crashing.

https://bugs.webkit.org/show_bug.cgi?id=286168#
<rdar://problem/143150963>

Reviewed by Antti Koivisto.

1. when a replaced element's intrinsic size changes we invalidate the associated IFC object
2. setNeedsLayoutIfNeededAfterIntrinsicSizeChange (as the name implies) is supposed to mark the renderer dirty only when its intrinsic size changed
but the logic seems to have evolved to cover no-size-change cases as well.

When other, unrelated changes trigger partial layout on IFC, we may skip this dirty renderer (#2).
(e.g. video is on the first line, while partial layout start at the second line).
Coming back from such partial layouts we may find some renderers still dirty -> ASSERT.

This patch covers cases when base class decides to dirty video renderers.

* LayoutTests/platform/ios/TestExpectations:
* Source/WebCore/rendering/RenderVideo.cpp:
(WebCore::RenderVideo::imageChanged):

Canonical link: https://commits.webkit.org/289342@main
pulkomandy pushed a commit that referenced this pull request Feb 16, 2025
@the-chenergy @JonWBedard
A compromised Web Content process should not be able to start Web Ins…
301bff4 
…pector

rdar://98891055
https://bugs.webkit.org/show_bug.cgi?id=283092

Reviewed by Ryosuke Niwa and BJ Burg.

There currently exists a message
WebInspectorUIProxy::OpenLocalInspectorFrontend, which the web process
sends to the UI process to show Web Inspector for the current web page.
This introduces security risks as a compromised website may find its way
to send arbitrary messages to the UI process, opening Web Inspector and
weakening the web content sandbox.

The reason this message exists is because there are useful ways the web
process needs to open Web Inspector with initiative. Normally, Web
Inspector is opened via one of the Develop menu's items, which is
controlled by the UI process. However, Web Inspector can also be opened
without being prompted by the UI process first, in these places:
   1. In a web page's context menu, the "Inspect Element" option
   2. Inside Web Inspector, if the Debug UI is enabled, on the top right
      corner, a button to open inspector^2
   3. In WebKitTestRunner, via the TestRunner::showWebInspector function

This patch makes it so that web process can no longer send a message to
a UI process to open Web Inspector. This means web process cannot open
Web Inspector at will -- it must be either due to the UI process's
demand, or it's in one of the above three cases. More details below.

I have tested that this change preserves the above three special cases
and does prevent the web page from opening Web Inspector at will.
   - Cases #1 and #2 can be tested from the UI.
   - Case #3 can be tested with a WebKit test involving Web Inspector.
     I ran the test LayoutTests/inspector/console/js-completions.html,
     where I saw the test crashing without special treatment for this
     case.
   - To verify that the web page can't open Web Inspector, I followed
     the reproduction steps from the Radar and saw Web Inspector no
     longer opens, and opening the external URL also failed as expected.

* Source/WebKit/UIProcess/Inspector/WebInspectorUIProxy.messages.in:
* Source/WebKit/UIProcess/Inspector/WebInspectorUIProxy.h:
* Source/WebKit/UIProcess/Inspector/WebInspectorUIProxy.cpp:
(WebKit::WebInspectorUIProxy::connect):
   - If the UI process wants to open Web Inspector, it sends a
     WebInspector::Show command to the web process. This patch makes
     that command take an async reply, so that the anticipated
     WebInspectorUIProxy::OpenLocalInspectorFrontend message from the
     web process can now be delivered through that async reply instead.
     This ensures that OpenLocalInspectorFrontend can only be done
     when initiated from the UI process (due to user interaction).

(WebKit::WebInspectorUIProxy::markAsUnderTest):
(WebKit::WebInspectorUIProxy::openLocalInspectorFrontend):
(WebKit::WebInspectorUIProxy::closeFrontendPageAndWindow):
   - To avoid relying on the web process for potentially sensitive
     parameters, I reworked and removed the canAttach and underTest
     arguments from openLocalInspectorFrontend. These two values
     are now stored and managed in the UI process instead, instead of
     being passed from the web process all the time.

      - For canAttach, I noticed that the
        WebInspectorUIProxyMac::platformCanAttach method already
        implements the same logic as the web process's
        WebInspector::canAttachWindow. I filed https://webkit.org/b/283435
        as a follow-up to clean up the webProcessCanAttach parameter,
        the canAttachWindow function in the web process, and potentially
        the m_attached field too, which all become obsolete due to
        this change.
           - I couldn't figure out what the `if (m_attached)` in
             canAttachWindow check does, and to me it had no effect, as
             this function is not called while inspector is open.

      - For underTest, I'm now letting the test runner directly set
        the flag on the WebInspectorUIProxy, as part of my fix to
        address case #3 from above.

(WebKit::WebInspectorUIProxy::showConsole):
(WebKit::WebInspectorUIProxy::showResources):
(WebKit::WebInspectorUIProxy::showMainResourceForFrame):
(WebKit::WebInspectorUIProxy::togglePageProfiling):
   - As the web process can longer call OpenLocalInspectorFrontend,
     call show/connect/openLocalInspectorFrontend here in the UI process
     instead.

(WebKit::WebInspectorUIProxy::requestOpenLocalInspectorFrontend):
   - To preserve the open inspector^2 button (case #2 from above), we
     still maintain this message, but we ignore it unless it's for
     opening inspector^2, thus renaming the message as a request.
     This is all assuming that the Web Inspector is not a compromised
     web process, so we allow that message from it to come through.

* Source/WebKit/WebProcess/Inspector/WebInspector.messages.in:
* Source/WebKit/WebProcess/Inspector/WebInspector.h:
* Source/WebKit/WebProcess/Inspector/WebInspector.cpp:
(WebKit::WebInspector::show):
   - The Show message now takes an async reply, which is used to replace
     sending WebInspectorUIProxy::OpenLocalInspectorFrontend later.

(WebKit::WebInspector::showConsole):
(WebKit::WebInspector::showResources):
(WebKit::WebInspector::showMainResourceForFrame):
(WebKit::WebInspector::startPageProfiling):
(WebKit::WebInspector::stopPageProfiling):
   - Calling inspectorController()->show() no longer does anything,
     since it's now the UI process's job to show Web Inspector first,
     for these functions to merely switch to the appropriate tabs.

* Source/WebKit/WebProcess/Inspector/WebInspector.cpp:
(WebKit::WebInspector::openLocalInspectorFrontend):
* Source/WebKit/WebProcess/Inspector/WebInspectorClient.cpp:
(WebKit::WebInspectorClient::openLocalFrontend):
   - Adapt to the command's reworked version.
   - This is maintained to allow the opening of inspector^2 from the web
     process (case #2 from above). For opening inspector^1, this message
     will be ignored by the UI process.

* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::contextMenuItemSelected):
   - When the "Inspect Element" context menu item is selected (case #1
     from above), since the web process may not be privileged to open
     Web Inspector, handle the showing of inspector here in UI process.

* Tools/WebKitTestRunner/InjectedBundle/TestRunner.cpp:
(WTR::TestRunner::showWebInspector):
* Tools/WebKitTestRunner/TestInvocation.cpp:
(WTR::TestInvocation::didReceiveMessageFromInjectedBundle):
* Source/WebKit/UIProcess/API/C/WKPagePrivate.h:
* Source/WebKit/UIProcess/API/C/WKPage.cpp:
(WKPageShowWebInspectorForTesting):
   - Preserve letting the WebKitTestRunner open Web Inspector (case #3
     from above).
   - Adapt to the change that we now also let the UI process know about
     the underTest flag for case #3, rather than letting UI process
     rely on the value reported by the web process.

* Source/WebKit/WebProcess/InjectedBundle/API/c/WKBundlePage.h:
* Source/WebKit/WebProcess/InjectedBundle/API/c/WKBundlePage.cpp:
(WKBundlePageShowInspectorForTest): Deleted.
   - No longer used due to my special fix for case #3.

Originally-landed-as: 283286.537@safari-7620-branch (694a9b5). rdar://144667626
Canonical link: https://commits.webkit.org/290260@main
pulkomandy pushed a commit that referenced this pull request Feb 22, 2025
@msaboff
[Yarr] Improve processing of an alternation of strings
12c34ef 
https://bugs.webkit.org/show_bug.cgi?id=288102
rdar://145222010

Reviewed by Yusuke Suzuki.

Added the notion of a string list to a parsed RegExp that is in the form of
  /^(?:break|case|which|do|for)/ with an optional trailing $.
Such a RegExp will not backtrack and therefore we can streamline the code we emit for such a pattern.

This change involves recognizing beginning of string anchored alternations of strings while parsing and
then treating the generation of JIT code differently for these patterns.  This includes changing how
conditional branching works, specifically that instead of the "fall through on match" for each term,
to a "jump on match" for the whole alternation.

The current code generated for the "case" elternative is:
   8:Term PatternCharacter checked-offset:(3) 'c'
               <156> 0x11381430c:    add      w1, w1, #2
               <160> 0x113814310:    cmp      w1, w2
               <164> 0x113814314:    b.hi     0x113814444 -> <468>
  10:Term PatternCharacter checked-offset:(4) 'c'
               <168> 0x113814318:    sub      x17, x0, #4
               <172> 0x11381431c:    ldr      w17, [x17, x1]
               <176> 0x113814320:    movz     w16, #0x6163
               <180> 0x113814324:    movk     w16, #0x6573, lsl #16 -> 0x65736163
               <184> 0x113814328:    cmp      w17, w16
               <188> 0x11381432c:    b.ne     0x113814444 -> <468>
  11:Term PatternCharacter checked-offset:(4) 'a' already handled
  12:Term PatternCharacter checked-offset:(4) 's' already handled
  13:Term PatternCharacter checked-offset:(4) 'e' already handled
  14:NestedAlternativeNext minimum-size:(5),checked-offset:(5)
               <192> 0x113814330:    movz     x16, #0x4444
               <196> 0x113814334:    movk     x16, #0x1381, lsl #16
               <200> 0x113814338:    movk     x16, #0x8001, lsl #32
               <204> 0x11381433c:    movk     x16, #0xc973, lsl #48 -> 0x113814444 JIT PC
               <208> 0x113814340:    stur     x16, [sp, #8]
               <212> 0x113814344:    b        0x113814404 -> <404>
With some additional backtracking code:
   9:NestedAlternativeNext minimum-size:(4),checked-offset:(4)
               <468> 0x113814444:    sub      w1, w1, #2
               <472> 0x113814448:    b        0x113814348 -> <216>

With this change, the processing of "case" becomes:
   9:StringListAlternativeNext minimum-size:(4),checked-offset:(4)
               <132> 0x12a8285c4:    sub      w1, w1, #1
               <136> 0x12a8285c8:    cmp      w1, w2
               <140> 0x12a8285cc:    b.hi     0x12a8285e8 -> <168>
  10:Term PatternCharacter checked-offset:(4) 'c'
               <144> 0x12a8285d0:    sub      x17, x0, #4
               <148> 0x12a8285d4:    ldr      w17, [x17, x1]
               <152> 0x12a8285d8:    movz     w16, #0x6163
               <156> 0x12a8285dc:    movk     w16, #0x6573, lsl #16 -> 0x65736163
               <160> 0x12a8285e0:    cmp      w17, w16
               <164> 0x12a8285e4:    b.eq     0x12a82866c -> <300>
  11:Term PatternCharacter checked-offset:(4) 'a' already handled
  12:Term PatternCharacter checked-offset:(4) 's' already handled
  13:Term PatternCharacter checked-offset:(4) 'e' already handled
  14:StringListAlternativeNext minimum-size:(5),checked-offset:(5)
With no backtracking code.

We are able to eliminate one branch and the saving of the continuation PC for backtracking.
The code size to process these string list RegExp is reduces.  For the example RegExp above,
the prior version created 1940 bytes (485 instructions) of code while the code created with this
1392 bytes (345 instructions) of code, a nearly 30% reduction in code.

This change is a ~18% progression on the new regexp-keyword-parsing microbenchmark:

                                 Baseline               YarrStringList

regexp-keyword-parsing      136.7065+-0.9807     ^    116.0161+-1.1791        ^ definitely 1.1783x faster

<geometric>                 136.7065+-0.9807     ^    116.0161+-1.1791        ^ definitely 1.1783x faster

* JSTests/microbenchmarks/regexp-keyword-parsing.js: Added.
(arrayToString):
(objectToString):
(dumpValue):
(compareArray):
(compareGroups):
(testRegExp):
(testRegExpSyntaxError):
(let.re.break.case.catch.continue.debugger.default.else.finally.if):
(let.re1.break.case.catch.continue.debugger.default.else.finally.if):
* JSTests/stress/regexp-parsing-tokens.js: Added.
(arrayToString):
(objectToString):
(dumpValue):
(compareArray):
(compareGroups):
(testRegExp):
(testRegExpSyntaxError):
* Source/JavaScriptCore/yarr/YarrJIT.cpp:
* Source/JavaScriptCore/yarr/YarrPattern.cpp:
(JSC::Yarr::YarrPatternConstructor::atomParenthesesEnd):
(JSC::Yarr::YarrPatternConstructor::checkForTerminalParentheses):
(JSC::Yarr::PatternAlternative::dump):
(JSC::Yarr::PatternTerm::dump):
* Source/JavaScriptCore/yarr/YarrPattern.h:
(JSC::Yarr::PatternTerm::PatternTerm):
(JSC::Yarr::PatternAlternative::PatternAlternative):

Canonical link: https://commits.webkit.org/290791@main
pulkomandy pushed a commit that referenced this pull request Mar 15, 2025
@msaboff
[Yarr] Improve processing of an alternation of strings
5d4feea 
https://bugs.webkit.org/show_bug.cgi?id=288102
rdar://145222010

Reviewed by Yusuke Suzuki.

Added the notion of a string list to a parsed RegExp that is in the form of
  /^(?:break|case|which|do|for)/ with an optional trailing $.
Such a RegExp will not backtrack and therefore we can streamline the code we emit for such a pattern.

This change involves recognizing beginning of string anchored alternations of strings while parsing and
then treating the generation of JIT code differently for these patterns.  This includes changing how
conditional branching works, specifically that instead of the "fall through on match" for each term,
to a "jump on match" for the whole alternation.

Fixed a bug in the original version where we weren't properly checking the nested alternatives to see
if they only contain fixed single count PatternCharacter terms.

The current code generated for the "case" elternative is:
   8:Term PatternCharacter checked-offset:(3) 'c'
               <156> 0x11381430c:    add      w1, w1, #2
               <160> 0x113814310:    cmp      w1, w2
               <164> 0x113814314:    b.hi     0x113814444 -> <468>
  10:Term PatternCharacter checked-offset:(4) 'c'
               <168> 0x113814318:    sub      x17, x0, #4
               <172> 0x11381431c:    ldr      w17, [x17, x1]
               <176> 0x113814320:    movz     w16, #0x6163
               <180> 0x113814324:    movk     w16, #0x6573, lsl #16 -> 0x65736163
               <184> 0x113814328:    cmp      w17, w16
               <188> 0x11381432c:    b.ne     0x113814444 -> <468>
  11:Term PatternCharacter checked-offset:(4) 'a' already handled
  12:Term PatternCharacter checked-offset:(4) 's' already handled
  13:Term PatternCharacter checked-offset:(4) 'e' already handled
  14:NestedAlternativeNext minimum-size:(5),checked-offset:(5)
               <192> 0x113814330:    movz     x16, #0x4444
               <196> 0x113814334:    movk     x16, #0x1381, lsl #16
               <200> 0x113814338:    movk     x16, #0x8001, lsl #32
               <204> 0x11381433c:    movk     x16, #0xc973, lsl #48 -> 0x113814444 JIT PC
               <208> 0x113814340:    stur     x16, [sp, #8]
               <212> 0x113814344:    b        0x113814404 -> <404>
With some additional backtracking code:
   9:NestedAlternativeNext minimum-size:(4),checked-offset:(4)
               <468> 0x113814444:    sub      w1, w1, #2
               <472> 0x113814448:    b        0x113814348 -> <216>

With this change, the processing of "case" becomes:
   9:StringListAlternativeNext minimum-size:(4),checked-offset:(4)
               <132> 0x12a8285c4:    sub      w1, w1, #1
               <136> 0x12a8285c8:    cmp      w1, w2
               <140> 0x12a8285cc:    b.hi     0x12a8285e8 -> <168>
  10:Term PatternCharacter checked-offset:(4) 'c'
               <144> 0x12a8285d0:    sub      x17, x0, #4
               <148> 0x12a8285d4:    ldr      w17, [x17, x1]
               <152> 0x12a8285d8:    movz     w16, #0x6163
               <156> 0x12a8285dc:    movk     w16, #0x6573, lsl #16 -> 0x65736163
               <160> 0x12a8285e0:    cmp      w17, w16
               <164> 0x12a8285e4:    b.eq     0x12a82866c -> <300>
  11:Term PatternCharacter checked-offset:(4) 'a' already handled
  12:Term PatternCharacter checked-offset:(4) 's' already handled
  13:Term PatternCharacter checked-offset:(4) 'e' already handled
  14:StringListAlternativeNext minimum-size:(5),checked-offset:(5)
With no backtracking code.

We are able to eliminate one branch and the saving of the continuation PC for backtracking.
The code size to process these string list RegExp is reduces.  For the example RegExp above,
the prior version created 1940 bytes (485 instructions) of code while the code created with this
1392 bytes (345 instructions) of code, a nearly 30% reduction in code.

This change is a ~18% progression on the new regexp-keyword-parsing microbenchmark:

                                 Baseline               YarrStringList

regexp-keyword-parsing      136.7065+-0.9807     ^    116.0161+-1.1791        ^ definitely 1.1783x faster

<geometric>                 136.7065+-0.9807     ^    116.0161+-1.1791        ^ definitely 1.1783x faster

* JSTests/microbenchmarks/regexp-keyword-parsing.js: Added.
(arrayToString):
(objectToString):
(dumpValue):
(compareArray):
(compareGroups):
(testRegExp):
(testRegExpSyntaxError):
(let.re.break.case.catch.continue.debugger.default.else.finally.if):
(let.re1.break.case.catch.continue.debugger.default.else.finally.if):
* JSTests/stress/regexp-parsing-tokens.js: Added.
(arrayToString):
(objectToString):
(dumpValue):
(compareArray):
(compareGroups):
(testRegExp):
(testRegExpSyntaxError):
* Source/JavaScriptCore/yarr/YarrJIT.cpp:
* Source/JavaScriptCore/yarr/YarrPattern.cpp:
(JSC::Yarr::YarrPatternConstructor::atomParenthesesEnd):
(JSC::Yarr::YarrPatternConstructor::checkForTerminalParentheses):
(JSC::Yarr::PatternAlternative::dump):
(JSC::Yarr::PatternTerm::dump):
* Source/JavaScriptCore/yarr/YarrPattern.h:
(JSC::Yarr::PatternTerm::PatternTerm):
(JSC::Yarr::PatternAlternative::PatternAlternative):

Canonical link: https://commits.webkit.org/290982@main
pulkomandy pushed a commit that referenced this pull request Mar 15, 2025
@the-chenergy
Web Inspector: Automatically connect Web Inspector to ServiceWorker
a85f489 
https://bugs.webkit.org/show_bug.cgi?id=264576
rdar://114997939

Reviewed by BJ Burg.

(This work was done in collaboration with Razvan and was based on his
draft at WebKit@377f3e1.)

This commit enables automatically inspecting and pausing the
ServiceWorkerDebuggable. The idea is similar to the same functionalities
with the JSContext/JSGlobalObjectDebuggable. The general flow is:
1. When the debuggable is first created, we optionally mark it as
   inspectable.
2. As soon as the debuggable is marked inspectable, its main thread
   (the thread that it was created on) gets blocked.
3. When the auto-launched Web Inspector frontend finishes initializing,
   it notifies the backend.
   - It's important for the debuggable to wait for this signal because
     a genuine auto-inspection must appear attached to the debuggable
     before it begins execution, respecting any breakpoints set early on
     in its script (where auto-pausing is basically a breakpoint
     before line 1).
4. The backend unpauses the blocked debuggable. If auto-pausing was
   requested, tell the debugger agent to pause.

The service worker begins executing script unless its worker thread was
specified to start in the WorkerThreadStartMode::WaitForInspector.
During that waiting period, the worker thread can perform tasks sent
into its debugging run loop, until it's signaled to stop waiting and
continue to execute the script like normal. This commit makes use of
that interface to make the service worker pause (when justified, i.e.
developerExtrasEnabled) before running the above flow resembling
auto-inspecting a JSContext.

* Source/WebCore/workers/service/context/ServiceWorkerThread.cpp:
(WebCore::threadStartModeFromSettings):
(WebCore::ServiceWorkerThread::ServiceWorkerThread):
   - When there is potentially a remote inspector that would like to
     auto-inspect, make it so that the thread waits on start before
     executing its script.

* Source/WebCore/workers/service/context/ServiceWorkerThreadProxy.h:
* Source/WebCore/workers/service/context/ServiceWorkerThreadProxy.cpp:
(WebCore::ServiceWorkerThreadProxy::ServiceWorkerThreadProxy):
(WebCore::ServiceWorkerThreadProxy::threadStartedRunningDebuggerTasks):
   - Setting inspectability is step #1 in the above flow.
   - In step #2, calling `debuggable->setInspectable(true)` might block
     already, but we don't want that until the worker thread is setup
     and have the run loop be in debug mode, so we do that in a callback
     instead.
   - In step #4, when connection to the inspector completes or fails,
     the setInspectable call only returns then, so we unblock
     the worker thread to resume code execution.

* Source/WebCore/inspector/agents/worker/WorkerDebuggerAgent.h:
* Source/WebCore/inspector/WorkerInspectorController.h:
* Source/WebCore/inspector/WorkerInspectorController.cpp:
(WebCore::WorkerInspectorController::frontendInitialized):
(WebCore::WorkerInspectorController::connectFrontend):
(WebCore::WorkerInspectorController::disconnectFrontend):
(WebCore::WorkerInspectorController::createLazyAgents):
(WebCore::WorkerInspectorController::ensureDebuggerAgent):
* Source/WebCore/workers/service/context/ServiceWorkerDebuggable.cpp:
(WebCore::ServiceWorkerDebuggable::connect):
* Source/WebCore/workers/service/context/ServiceWorkerInspectorProxy.h:
* Source/WebCore/workers/service/context/ServiceWorkerInspectorProxy.cpp:
(WebCore::ServiceWorkerInspectorProxy::connectToWorker):
   - Mimic the logic for auto-inspecting a JSContext/JSGlobalObjectDebuggable.

* Source/JavaScriptCore/inspector/protocol/Inspector.json:
   - Step #3 in the above flow, notify the backend when frontend
     completes setting up.

* Source/WebCore/workers/service/context/ServiceWorkerDebuggable.h:
  - Allow service workers to be auto-inspected. (This is checked at https://github.com/rcaliman-apple/WebKit/blob/eng/Web-Inspector-Automatically-connect-Web-Inspector-to-ServiceWorker/Source/JavaScriptCore/inspector/remote/RemoteInspectionTarget.cpp#L95)

* Source/WTF/wtf/PlatformEnableCocoa.h:
   - Add feature flag just in case.

Canonical link: https://commits.webkit.org/291167@main
pulkomandy pushed a commit that referenced this pull request Apr 3, 2025
@alanbaradlay
Block reusing may remove floating object too early
d9617b1 
https://bugs.webkit.org/show_bug.cgi?id=290862
<rdar://147215658>

Reviewed by Antti Koivisto.

"Reusing block" type mutations (see RenderTreeBuilder::Inline::splitFlow) followed by float removal may lead to an unexpected state where we have a float to remove, but we have already destroyed m_floatingObjects, causing us to incorrectly assume that the float no longer belongs here (markSiblingsWithFloatsForLayout) and, therefore, does not need to be removed from sibling blocks (in case it is intrusive).

What happens here is:
1. tree mutation makes an anon block reused (pre block)
2. a float is removed from said anon block's subtree

At #1 we call removeFloatingObjects() which simply clears and destroys m_floatingObjects on the anon block.
Now at #2, when we try to remove this float from sibling block containers by calling RenderBlockFlow::markSiblingsWithFloatsForLayout, and we consult
m_floatingObjects to see if there's any float associated with the block and we early return as we had already cleared this set at #1.

This patch ensures that when markSiblingsWithFloatsForLayout is called with a valid float, we always try to clean up sibling content.

* LayoutTests/fast/block/float-remove-after-block-collapse-crash-expected.txt: Added.
* LayoutTests/fast/block/float-remove-after-block-collapse-crash.html: Added.
* Source/WebCore/rendering/RenderBlockFlow.cpp:
(WebCore::RenderBlockFlow::markSiblingsWithFloatsForLayout):
Change
for (siblings)
  for (set items)

to
for (set items)
  for (siblings)

so that the 'for (siblings)' logic can be moved to a lambda and used when there's a valid incoming float.

Canonical link: https://commits.webkit.org/293094@main
pulkomandy pushed a commit that referenced this pull request Apr 3, 2025
@alanbaradlay
Stale float state caused by 'content visibility' may lead to ASSERT i…
cab087e 
…n addFloatsToNewParent

https://bugs.webkit.org/show_bug.cgi?id=290898
<rdar://143296265>

Reviewed by Antti Koivisto.

In this patch
1. we let m_floatingObjects go stale on the skipped root (we already do that for the skipped subtree by not running layout)
2. we descend into skipped subtrees while cleaning up floats even when m_floatingObjects is stale/empty

Having up-to-date m_floatingObjects on the skipped root, while stale m_floatingObjects on the skipped subtree can lead to issues when
(#1) a previously intrusive float
(#2) becomes non-intrusive and
(#3) eventually gets deleted
prevents us from being able to cleanup m_floatingObjects in skipped subtree(s).

at #1 m_floatingObjects is populated with the intrusive float (both skipped root and renderers in skipped subtree)
and at #2 since we only run layout on the skipped root, m_floatingObjects gets updated by removing this previously intrusive float (skipped subtree becomes stale)
and at #3 we don't descend into the skipped subtree to cleanup m_floatingObjects since the skipped root does not have this float anymore (removed at #2).

* Source/WebCore/rendering/RenderBlockFlow.cpp:
(WebCore::RenderBlockFlow::markSiblingsWithFloatsForLayout):

Canonical link: https://commits.webkit.org/293119@main
pulkomandy pushed a commit that referenced this pull request Apr 29, 2025
@alanbaradlay
Stale float state caused by 'content visibility' may lead to ASSERT i…
68742b8 
…n addFloatsToNewParent

https://bugs.webkit.org/show_bug.cgi?id=290898
<rdar://149579273>

Reviewed by Antti Koivisto.

In this patch
1. we let m_floatingObjects go stale on the skipped root (we already do that for the skipped subtree by not running layout)
2. we descend into skipped subtrees while cleaning up floats even when m_floatingObjects is stale/empty

Having up-to-date m_floatingObjects on the skipped root, while stale m_floatingObjects on the skipped subtree can lead to issues when
(#1) a previously intrusive float
(#2) becomes non-intrusive and
(#3) eventually gets deleted
prevents us from being able to cleanup m_floatingObjects in skipped subtree(s).

at #1 m_floatingObjects is populated with the intrusive float (both skipped root and renderers in skipped subtree)
and at #2 since we only run layout on the skipped root, m_floatingObjects gets updated by removing this previously intrusive float (skipped subtree becomes stale)
and at #3 we don't descend into the skipped subtree to cleanup m_floatingObjects since the skipped root does not have this float anymore (removed at #2).

* Source/WebCore/rendering/RenderBlockFlow.cpp:
(WebCore::RenderBlockFlow::markSiblingsWithFloatsForLayout):

Canonical link: https://commits.webkit.org/293889@main
pulkomandy pushed a commit that referenced this pull request Apr 29, 2025
@the-chenergy
Web Inspector: Resizing a docked Web Inspector does not follow the cu…
fdb9aa7 
…rsor smoothly

rdar://148762897
https://bugs.webkit.org/show_bug.cgi?id=292042

Reviewed by Devin Rousso.

This is a combination of two issues:

1. If the WKInspectorWKWebView has safeAreaInsets set and therefore
   _obscuredContentInsets configured, adjusting its dimensions does not
   take that into account. Assuming there is a left inset configured
   to be X and the new docked inspector width requested by the frontend
   is W, the frontend is not aware of the extra X pixels needed when
   rendering the WKInspectorWKWebView (because the frontend lives inside
   that web view), which then needs to be (W + X) pixels wide instead.

2. The setAttachedWindowHeight/Width commands in the backend take an
   `unsigned int` as the new dimension's type, but the frontend computes
   in floating point (JavaScript's Number), which always gets rounded
   down when the new dimension gets passed in and coerced to an int.
   This makes the new view just slightly smaller than required over
   the course of dragging.

* Source/WebKit/UIProcess/Inspector/mac/WebInspectorUIProxyMac.mm:
(WebKit::WebInspectorUIProxy::platformSetAttachedWindowHeight):
(WebKit::WebInspectorUIProxy::platformSetAttachedWindowWidth):
   - Fix issue #1.

* Source/WebInspectorUI/UserInterface/Base/Main.js:
   - Fix issue #2.
   - Adding the rounding on resulting dimension alone was sufficient to
     fix the "always-shrinking" bug. However, resizing still didn't feel
     completely smooth; the inspector wouldn't shrink by itself, but
     it still felt like having some lag following the moving cursor.
     I took a simpler approach to compute the delta, where we use the
     original dimension as the standard instead of the last frame,
     which turns out to be extremely smooth and exactly what we wanted.

Tested the fix manually on various inspector zoom factors from 60% to
240%, combined with or without an _obscuredContentInsets applied on the
WKInspectorWKWebView.

Canonical link: https://commits.webkit.org/294123@main
kenmays referenced this pull request in kenmays/haikuwebkit May 18, 2025
@robert-jenner
Build Fix attempt #2 for note: forward declaration of 'WebCore::Setti…
d2cde0d 
…ngs'

rdar://151332172

Reviewed by Jonathan Bedard and Ryosuke Niwa.

* Source/WebKit/WebProcess/Model/WebModelPlayerProvider.cpp:

Canonical link: https://commits.webkit.org/294927@main
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.