Move stdint.h import out of __cplusplus guard in ForkExtras.h by DAlperin · Pull Request #2 · oven-sh/WebKit

DAlperin · 2021-09-18T03:19:47Z

Prereq to linux builds

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

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

…with-relative-parent.html is a flaky image failure https://bugs.webkit.org/show_bug.cgi?id=239101 <rdar://problem/91603539> Reviewed by Antti Koivisto. Source/WebCore: 1. Out of flow boxes are laid out independently from each other as the last step of their containing block layout. 2. However their static positions are computed during regular in-flow layout (as if their positions were static). In order to do #1, we maintain a ListHashSet for the out-of-flow boxes and insert them at #2 (and we also have a corresponding HashMap<ContainingBlock, ListHasSet>). Normally this is a very simple list of descendant positioned boxes and since out-of-flow boxes don't interact with each other, their position in the list is not important. e.g. <div id=A style="position: relative"> <div> <div id=B style="position: absolute"></div> <div id=C style="position: absolute"></div> </div> </div> At in-flow layout (#2), we insert B and C to "ListHashSet of A" as we come across them in DOM order and compute their static positions. Later in the layout flow when we get to the "let's layout the out-of-flow boxes" phase (#1) we simply walk the ListHashSet and lay out B and C (but "C and B" order would also work just fine). However the ICB (RenderView) is a special containing block as it can hold different types of out-of-flow boxes (absolute and fixed) and those out-of-flow boxes may have layout dependencies. e.g. <body><div id=A class=absolute><div id=B class=fixed></div></div></body> ICB's ListHasSet has both A and B, but in this case there's (static)layout dependency between these boxes. In order to figure out the static position of B, we have to have A laid out first. In order to lay out A before B, B has to be preceded by A in ICB's ListHasSet. Now full layout always guarantees the correct order. However in case of partial layout since we don't run a full #2, the ListHasSet may end up having an unexpected order. e.g. <body><div id=A class=absolute><div id=B><div id=C class=fixed></div></div></div></body> 1. The initial (full) layout produces the following (correct) order for the ICB's ListHasSet -> AC. 2. A subsequent partial layout (e.g. triggered by A's position change) runs an in-flow layout on the <body> which (re-)appends A to the ListHasSet (CA <- incorrect order). Now at this point we assume that the in-flow layout picks up B which eventually (re-)appends C to the ListHashSet (AC <- correct order). However since B does not need layout, we just stop at <body> which leaves us with an unexpected ListHashSet. 3. As part of the ICB's out-of-flow layout, we pick C as the first box to lay out followed by A. However since C's static position depends on A's position, we end up using stale geometry when computing C's static position. This patch fixes this issue by ensuring the absolute positioned boxes always come first in the ICB's ListHasSet (note that their order is not really important -see above. What's important is that a potential (as-if-static) containing block always comes before the fixed boxes). Test: fast/block/fixed-inside-absolute-positioned.html * rendering/RenderBlock.cpp: (WebCore::PositionedDescendantsMap::addDescendant): (WebCore::RenderBlock::insertPositionedObject): LayoutTests: * fast/block/fixed-inside-absolute-positioned-expected.html: Added. * fast/block/fixed-inside-absolute-positioned.html: Added. * platform/mac-wk1/TestExpectations: Canonical link: https://commits.webkit.org/249597@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@292817 268f45cc-cd09-0410-ab3c-d52691b4dbfc

…with-relative-parent.html is a flaky image failure https://bugs.webkit.org/show_bug.cgi?id=239101 <rdar://problem/91603539> Reviewed by Antti Koivisto. Source/WebCore: 1. Out of flow boxes are laid out independently from each other as the last step of their containing block layout. 2. However their static positions are computed during regular in-flow layout (as if their positions were static). In order to do #1, we maintain a ListHashSet for the out-of-flow boxes and insert them at #2 (and we also have a corresponding HashMap<ContainingBlock, ListHasSet>). Normally this is a very simple list of descendant positioned boxes and since out-of-flow boxes don't interact with each other, their position in the list is not important. e.g. <div id=A style="position: relative"> <div> <div id=B style="position: absolute"></div> <div id=C style="position: absolute"></div> </div> </div> At in-flow layout (#2), we insert B and C to "ListHashSet of A" as we come across them in DOM order and compute their static positions. Later in the layout flow when we get to the "let's layout the out-of-flow boxes" phase (#1) we simply walk the ListHashSet and lay out B and C (but "C and B" order would also work just fine). However the ICB (RenderView) is a special containing block as it can hold different types of out-of-flow boxes (absolute and fixed) and those out-of-flow boxes may have layout dependencies. e.g. <body><div id=A class=absolute><div id=B class=fixed></div></div></body> ICB's ListHasSet has both A and B, but in this case there's (static)layout dependency between these boxes. In order to figure out the static position of B, we have to have A laid out first. In order to lay out A before B, B has to be preceded by A in ICB's ListHasSet. Now full layout always guarantees the correct order. However in case of partial layout since we don't run a full #2, the ListHasSet may end up having an unexpected order. e.g. <body><div id=A class=absolute><div id=B><div id=C class=fixed></div></div></div></body> 1. The initial (full) layout produces the following (correct) order for the ICB's ListHasSet -> AC. 2. A subsequent partial layout (e.g. triggered by A's position change) runs an in-flow layout on the <body> which (re-)appends A to the ListHasSet (CA <- incorrect order). Now at this point we assume that the in-flow layout picks up B which eventually (re-)appends C to the ListHashSet (AC <- correct order). However since B does not need layout, we just stop at <body> which leaves us with an unexpected ListHashSet. 3. As part of the ICB's out-of-flow layout, we pick C as the first box to lay out followed by A. However since C's static position depends on A's position, we end up using stale geometry when computing C's static position. This patch fixes this issue by ensuring the absolute positioned boxes always come first in the ICB's ListHasSet (note that their order is not really important -see above. What's important is that a potential (as-if-static) containing block always comes before the fixed boxes). Test: fast/block/fixed-inside-absolute-positioned.html * rendering/RenderBlock.cpp: (WebCore::PositionedDescendantsMap::addDescendant): (WebCore::RenderBlock::insertPositionedObject): LayoutTests: * fast/block/fixed-inside-absolute-positioned-expected.html: Added. * fast/block/fixed-inside-absolute-positioned.html: Added. * platform/mac-wk1/TestExpectations: Canonical link: https://commits.webkit.org/249626@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@292855 268f45cc-cd09-0410-ab3c-d52691b4dbfc

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

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

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

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

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

https://bugs.webkit.org/show_bug.cgi?id=248506 Reviewed by Antti Koivisto. 1. Do not set "layout bounds" on non-inline boxes (spec agrees here) 2. Make sure hard line breaks still stretch their parent inline boxes when applicable Current behavior: 1. Line break box gets computed layout bounds 2. When the line break box affects the line box, we stretch the line by the computed layout bounds value Patch behavior: 1. Line break box makes the parent inline box "contentful" when applicable (this is the same as #2 at current behavior) 2. The "contentful" inline box (mostly the root inline box) stretches the line box by the computed layout bounds. It makes break box behave like regular "text content", where the content indirectly affects the line box height. This patch is also in preparation for supporting text-edge, where text-edge affects the layout bounds value. * Source/WebCore/layout/formattingContexts/inline/InlineFormattingGeometry.cpp: (WebCore::Layout::InlineFormattingGeometry::inlineLevelBoxAffectsLineBox const): * Source/WebCore/layout/formattingContexts/inline/InlineFormattingGeometry.h: * Source/WebCore/layout/formattingContexts/inline/InlineFormattingQuirks.cpp: (WebCore::Layout::InlineFormattingQuirks::lineBreakBoxAffectsParentInlineBox): (WebCore::Layout::InlineFormattingQuirks::inlineBoxAffectsLineBox const): (WebCore::Layout::InlineFormattingQuirks::inlineLevelBoxAffectsLineBox const): Deleted. * Source/WebCore/layout/formattingContexts/inline/InlineFormattingQuirks.h: * Source/WebCore/layout/formattingContexts/inline/InlineLineBoxBuilder.cpp: (WebCore::Layout::LineBoxBuilder::setVerticalPropertiesForInlineLevelBox const): (WebCore::Layout::LineBoxBuilder::constructInlineLevelBoxes): (WebCore::Layout::LineBoxBuilder::adjustIdeographicBaselineIfApplicable): * Source/WebCore/layout/formattingContexts/inline/InlineLineBoxVerticalAligner.cpp: (WebCore::Layout::LineBoxVerticalAligner::computeLineBoxLogicalHeight const): (WebCore::Layout::LineBoxVerticalAligner::computeRootInlineBoxVerticalPosition const): Canonical link: https://commits.webkit.org/257288@main

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

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

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

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

… when the deleted text spans more than one line https://bugs.webkit.org/show_bug.cgi?id=257043 <rdar://109538333> Reviewed by Antti Koivisto. Normally while editing inline content in a content-editable container e.g "This is some long long long long long text content" and select/delete "long long text" (spanning over line#2 and #3) What happens is RenderText receives a content mutation event pointing to the _beginning_ of "long long text". As a result we damage line #2 and run a partial layout staring from line#2 until after we see no layout change anymore or we hit content end. However some JS based editors call innerHTML instead to mimic editing steps turning the above example to a "range replace" type of mutation where the entire text content is getting replaced with the "new", shortened content. In such cases, instead of receiving the position of the actual damage, we end up with the offset value of 0 since the entire content is being replaced (even though it's just a slight change in the text content) Now we damage line#0 and start running layout from the very first line until we see no layout change...which is the second line since the actual damage is on the third line. Since IFC does not support such mutations yet, in this patch we disable range based bailout which means while we still run partial inline layout, we always go all the way to the bottom of the content. /fast/inline/range-replace-partial-layout-invalidation-expected.html: Added. * LayoutTests/fast/inline/range-replace-partial-layout-invalidation.html: Added. * Source/WebCore/layout/formattingContexts/inline/invalidation/InlineInvalidation.cpp: (WebCore::Layout::InlineInvalidation::textWillBeRemoved): Canonical link: https://commits.webkit.org/264274@main

…pty lines https://bugs.webkit.org/show_bug.cgi?id=257261 <rdar://108742128> Reviewed by Antti Koivisto. When intrusive floats prevent us from placing any content at the current vertical position, the candidate position for the next line is computed by looking at such intrusive floats. e.g. Two float boxes with the inline content of "foobar". _______ _______ | | | | | left | | right | |_______| | | |_______| 1. "foobar" does not fit at y: 0 (overlaps "left"). 2. we find 2 intrusive floats at y: 0 3. vertical position for next line is at the bottom of "left1" This is rather simple, but if float placement bugs produce some vertical gaps between floats e.g. _______ _______ | | | | | left1 | | right | |_______| | | |_______| _______ | | | left2 | |_______| (note that left2 is supposed to be vertically adjacent to left1) Now if we run line layout: 1. "foobar" does not fit at y: 0 -> vertical position for next line is at the bottom of "left1" 2. "foobar" still does not fit (assume it overlaps "right") -> position for next line is at the bottom of "right" 3. now assume that "foobar" is tall and it does not fit between the bottom of the "right" and the top of this incorrectly placed "left2" _______ _______ | | | | | left1 | | right | |_______| | | |_______| ____ | |___ _|_____ | | | | | | |_______| running "let's find the position for next line by avoiding intrusive floats" logic in InlineFormattingGeometry::logicalTopForNextLine() finds no intrusive float at the bottom of the "right" float (that's what #2 computed as candidate position). This is an unexpected state (we assert) and in order not to get stuck on the same vertical position we advance by 1px for the next line hoping we would be able to place "foobar" there. While it helps to avoid forever looping, if the gap between the bottom of the "right" and the top of the "left2" is wide we may end up producing thousands of empty lines until we reach the top of the "left2" float box and finally get out of this unexpected state. In this patch, instead of advancing by 1px, we jump right to the bottom of the "left2" float box (bottom of all the floats in this floating context) and continue from there. * Source/WebCore/layout/formattingContexts/inline/InlineFormattingGeometry.cpp: (WebCore::Layout::InlineFormattingGeometry::logicalTopForNextLine const): move float handling to a helper (intrusiveFloatBottom) and return the max of floatingContext.bottom() and lineLogicalRect.bottom(). Canonical link: https://commits.webkit.org/264579@main

https://bugs.webkit.org/show_bug.cgi?id=245225 <rdar://problem/100278323> Reviewed by Simon Fraser. Non-initial line-height value gets leaked into the inner text control making the associated inline-block inline level box too tall. It causes 2 highly visible bugs with single-line type of text controls. 1, it results in tall line box pushing the rest of the baseline align inline content downward (test case #1) 2, text content inside the input is not visible at all unless the input is active and user starts typing (test case #2) (It's quite bad as focusing the input still produces blank content and the user has to start typing to see existing text in the input). <div>some text<input style="height: 50px; line-height: 1000" placeholder="and more"></div> _______________ | _____________ | <- input || and more || <- "forced positioned" placeholder control ||_____________|| | | <- inner text control | | | | some text | | <- computed baseline position (this is where the input box value ("text content") would end up) | | | | |_____________| Note that this is normal inline-block behavior where the baseline alignment is based off of the inline-block's last line even when this last line overflows the border box (and produces layout overflow). However not only does it look unacceptable for single-line input boxes but also our custom layout and painting logic inside RenderTextControlSingleLine slightly disagrees with this constrained set and produces unexpected content placement. (Current behavior is closer to what happens if the inline-block had "overflow: hidden", -which puts the baseline position at the bottom of the margin box) In this patch we override the inherited line-height value to initial unless the input box's height is auto -in which case it is actually ok to be driven by the content height (i.e. line-height based inflate is ok). This change improves interoperability and makes WebKit match other rendering engines' behavior. * Source/WebCore/html/HTMLInputElement.cpp: (WebCore::HTMLInputElement::createInnerTextStyle): Canonical link: https://commits.webkit.org/264613@main

https://bugs.webkit.org/show_bug.cgi?id=256950 rdar://problem/109498423 Reviewed by Andres Gonzalez. With this patch, any list-type element (ol, ul, dl, role="list", etc) with display:contents will now properly be created as an AccessibilityList instance rather than an AccessibilityNodeObject. The significant effects of this are: 1. The correct subrole is now computed for these elements, which is important because some ATs do change their behavior based on the various list subroles. 2. These elements now use the AccessibilityList::determineAccessibilityRole() "is this an AX list or layout-only list" heuristics. In support of #2, some tests had to be modified to have rendered list items in order to still be considered lists. We implement this by allowing the creation of AccessibilityList with only a node instead of requiring a renderer. The other, more significant change introduced in this patch is that many AccessibilityRenderObject methods are now changed to fallback to the corresponding AccessibilityNodeObject implementation when there is no renderer rather than returning early. This is required because we have many subclasses of AccessibilityRenderObject that also need to support display:contents (AccessibilityList is one of these). Making this change weakens our definition of AccessibilityRenderObject from "should have a renderer" to "should have a renderer or a node". * LayoutTests/platform/wpe/accessibility/aria-visible-element-roles-expected.txt: * LayoutTests/platform/glib/accessibility/aria-visible-element-roles-expected.txt: * LayoutTests/platform/glib/accessibility/display-contents-element-roles-expected.txt: * LayoutTests/platform/ios/accessibility/display-contents-element-roles-expected.txt: * LayoutTests/platform/mac-wk1/accessibility/aria-visible-element-roles-expected.txt: * LayoutTests/accessibility/aria-visible-element-roles.html: * LayoutTests/accessibility/display-contents-element-roles-expected.txt: * LayoutTests/accessibility/display-contents-element-roles.html: * LayoutTests/platform/mac-wk2/accessibility/aria-visible-element-roles-expected.txt: * Source/WebCore/accessibility/AXObjectCache.cpp: (WebCore::shouldCreateAccessibilityList): (WebCore::AXObjectCache::createObjectFromRenderer): (WebCore::createFromNode): (WebCore::AXObjectCache::getOrCreate): * Source/WebCore/accessibility/AccessibilityList.cpp: (WebCore::AccessibilityList::AccessibilityList): (WebCore::AccessibilityList::create): * Source/WebCore/accessibility/AccessibilityList.h: * Source/WebCore/accessibility/AccessibilityNodeObject.cpp: (WebCore::AccessibilityNodeObject::checkboxOrRadioRect const): (WebCore::AccessibilityNodeObject::elementRect const): (WebCore::AccessibilityNodeObject::addChildren): (WebCore::AccessibilityNodeObject::canHaveChildren const): (WebCore::AccessibilityNodeObject::computeAccessibilityIsIgnored const): * Source/WebCore/accessibility/AccessibilityNodeObject.h: * Source/WebCore/accessibility/AccessibilityObject.cpp: (WebCore::AccessibilityObject::convertFrameToSpace const): * Source/WebCore/accessibility/AccessibilityRenderObject.cpp: (WebCore::AccessibilityRenderObject::AccessibilityRenderObject): (WebCore::AccessibilityRenderObject::firstChild const): (WebCore::AccessibilityRenderObject::lastChild const): (WebCore::AccessibilityRenderObject::previousSibling const): (WebCore::AccessibilityRenderObject::nextSibling const): (WebCore::AccessibilityRenderObject::parentObject const): (WebCore::AccessibilityRenderObject::helpText const): (WebCore::AccessibilityRenderObject::textUnderElement const): (WebCore::AccessibilityRenderObject::node const): (WebCore::AccessibilityRenderObject::stringValue const): (WebCore::AccessibilityRenderObject::boundingBoxRect const): (WebCore::AccessibilityRenderObject::defaultObjectInclusion const): (WebCore::AccessibilityRenderObject::computeAccessibilityIsIgnored const): (WebCore::AccessibilityRenderObject::document const): (WebCore::AccessibilityRenderObject::documentFrameView const): (WebCore::AccessibilityRenderObject::addChildren): (WebCore::AccessibilityRenderObject::checkboxOrRadioRect const): Deleted. (WebCore::AccessibilityRenderObject::elementRect const): Deleted. (WebCore::AccessibilityRenderObject::canHaveChildren const): Deleted. * Source/WebCore/accessibility/AccessibilityRenderObject.h: Canonical link: https://commits.webkit.org/264644@main

… on article titles https://bugs.webkit.org/show_bug.cgi?id=257629 <rdar://110018946> Reviewed by Simon Fraser. 1. The "cutoff article titles" is some visible inline content _after_ the clamped line. They are supposed to be clipped off. 2. The reason why they are visible is because we compute incorrect logical height value for the flex container (box with -webkit-line-clamp) 3. This incorrectly computed height value makes the flex container too tall revealing content _after_ the clamped line. The input to the flex container height computation is the flex items' accumulated height (bottom of the last flex item). Normally this is based on the _clamped_ content height (see the end of RenderDeprecatedFlexibleBox::layoutVerticalBox), but apparently 264048@main did not cover all the cases. In 264048@main we started tracking both clamped and unclamped content height on each flex items 1. clamped height is used to compute the flex container's final height 2. unclamped height is used to prevent sibling content from getting overlapped This (#2) was supposed to provide a more reasonable -webkit-line-clamp result; see an example below: <div style="display: flex; -webkit-line-clamp: 1;"> <div flex-item> flex item is clamped here (this line ends with ellipsis) this line is still visible. It is expected unless overflow clipping is applied. </div> <div flex-item> this sibling content is visible and prior to 264048@main it overlapped the lines in the first flex-item as the first flex-item height is set to the clamped content height. </div> </div> Starting from 264048@main, the second flex-item is placed _below_ the first flex item (and not overlap it) This was achieved by letting the flex items keep their unclamped logical height. However some part of the RenderDeprecatedFlexibleBox (flex container) expects the flex items' logical height match their clamped content height (this is also legacy behavior). In this patch we start setting the _clamped_ content height on the flex items. e.g. (assume 20px as line box height) <div flex-container with -webkit-line-clamp: 1> <div flex-item> Flex item is clamped here (this line ends with ellipsis) but this line is still visible which is expected unless overflow is clipping is applied. </div> </div> The used height of the flex-item is now the height of the first line (20px) (as opposed to the bottom of the second line (40px)) * LayoutTests/TestExpectations: * LayoutTests/fast/inline/line-clamp-with-max-height-overflow-expected.html: Added. * LayoutTests/fast/inline/line-clamp-with-max-height-overflow.html: Added. * LayoutTests/platform/ios/fast/overflow/line-clamp-expected.txt: * LayoutTests/platform/mac/fast/overflow/line-clamp-expected.txt: * Source/WebCore/rendering/RenderBlockFlow.cpp: (WebCore::RenderBlockFlow::layoutModernLines): The only functional change here is: setLogicalHeight(borderAndPaddingBefore() + *logicalHeight + borderAndPaddingAfter() + scrollbarLogicalHeight()); where we set the clamped content height as the logical height. Canonical link: https://commits.webkit.org/264828@main

https://bugs.webkit.org/show_bug.cgi?id=258625 <rdar://111454222> Unreviewed build fix #2. The warning is -Wdeprecated-pragma, not -Wdeprecated-declarations, so the previous fix in 265585@main ignored the wrong warning. * Source/WTF/wtf/Compiler.h: (ALLOW_DEPRECATED_PRAGMA_BEGIN): (ALLOW_DEPRECATED_PRAGMA_END): - Add begin/end macros for -Wdeprecated-pragma. * Source/WTF/wtf/text/TextBreakIterator.cpp: - Ignore deprecation warning for ATOMIC_VAR_INIT() macro in future versions of clang. Canonical link: https://commits.webkit.org/265756@main

https://bugs.webkit.org/show_bug.cgi?id=253812 Reviewed by Don Olmstead. We no longer need DLLLauncherMain.cpp since Apple Windows port was removed. It made CMake scripts complicated and the missing required DLL error message useless. There are three ways to do it: 1. Copy all DLL files of WebKitRequirements to the output directory during the build process. This makes the size of a built product archive big. 2. Runner scripts (run-webkit-tests and run-jsc etc) set PATH. Apple ports do the same for DYLD_FRAMEWORK_PATH. 3. Windows port developers manually set PATH to "WebKitLibraries\win\bin64" before running executables. As well as they had to set WEBKIT_LIBRARIES env var so far. This patch takes approach #2. * Source/JavaScriptCore/jsc.cpp: (jscmain): (dllLauncherEntryPoint): Deleted. * Source/JavaScriptCore/shell/DLLLauncherMain.cpp: Removed. * Source/JavaScriptCore/shell/PlatformWin.cmake: * Source/WebDriver/PlatformWin.cmake: * Source/WebDriver/WebDriverMain.cpp: (main): (dllLauncherEntryPoint): Deleted. * Source/cmake/WebKitMacros.cmake: * Tools/ImageDiff/ImageDiff.cpp: (main): (dllLauncherEntryPoint): Deleted. * Tools/ImageDiff/PlatformWin.cmake: * Tools/MiniBrowser/win/CMakeLists.txt: * Tools/MiniBrowser/win/Common.cpp: (DllMain): Deleted. * Tools/MiniBrowser/win/WinMain.cpp: (wWinMain): (dllLauncherEntryPoint): Deleted. * Tools/Scripts/run-javascriptcore-tests: * Tools/Scripts/run-jsc: * Tools/Scripts/webkitdirs.pm: (setupWindowsWebKitEnvironment): * Tools/Scripts/webkitpy/port/win.py: (WinPort.setup_environ_for_server): * Tools/TestWebKitAPI/PlatformWin.cmake: * Tools/TestWebKitAPI/win/main.cpp: (main): (dllLauncherEntryPoint): Deleted. * Tools/WebKitTestRunner/PlatformWin.cmake: * Tools/WebKitTestRunner/win/main.cpp: (main): (dllLauncherEntryPoint): Deleted. * Tools/win/DLLLauncher/DLLLauncherMain.cpp: Removed. Canonical link: https://commits.webkit.org/265819@main

https://bugs.webkit.org/show_bug.cgi?id=261741 <rdar://112494003> Reviewed by Antti Koivisto. 1. we do _not_ construct renderers for “display: none” iframes 2. we do construct render tree for the “display: none” iframe’s content we do #2 because JS may ask for geometry information on content inside a “display: none” iframe. e.g. <div><iframe srcdoc=“text” style="display: none;" id=iframe></iframe></div> where: iframe.contentDocument.body.offsetHeight should return the value of “18px” the markup above triggers the following 2 render trees: Main document: RenderView HTML RenderBlock BODY RenderBody DIV RenderBlock (^^ no renderer here for the “display: none” iframe) iframe document: RenderView HTML RenderBlock BODY RenderBody #text RenderText (^^ this is the content _inside_ the "display: none" iframe) We not only construct a render tree for the invisible iframe content, but also (as part of the tree construction) we schedule an async layout on them This patch drops such async layout requests on the floor and keep the renderers dirty until after either 1. sync layout is triggered (JS -> DOM API) 2. iframe becomes visible (display != none) * LayoutTests/fast/dynamic/display-none-iframe-async-layout-expected.html: Added. * LayoutTests/fast/dynamic/display-none-iframe-async-layout.html: Added. * Source/WebCore/dom/Document.cpp: (WebCore::Document::shouldScheduleLayout const): Canonical link: https://commits.webkit.org/268148@main

https://bugs.webkit.org/show_bug.cgi?id=272023 rdar://problem/125776346 Reviewed by Dan Glastonbury Contains upstream commits: git log --oneline f431641a948660f5e1709aa7cd89b16ccf93f1de..3ed8c5f4314708d3078950620b135722eada60bf --pretty=%h %s 3ed8c5f431 Android: workaround broken run-as due to /data permissions 96f443295f Revert "Remove few redundant ImmutableString to std::string conversions" ee02014d87 Selectively wait for LinkSubTasks 16fef70f84 Vulkan: Refactor imageless framebuffer creation 1bd82319c7 Add RenderTargetWgpu a53bd62a90 Disable MSRTSS on QCOM 33a09305f1 Metal: Remove work texture and work buffer from ContextMtl 0197826bba Revert "Add conversion operator from ImmutableString to std::string" 9ae4a2f4b7 Roll Chromium from babb076716bc to 532d52d6ecb3 (627 revisions) ad013650bb Revert "Rename LinkSubTask -> PostLinkTask" 8899e18dc6 Add skip conditions for a few tests f3a819f1bc Context: Limit max texture size for ANGLE captures 6c37973311 Add more helper methods for textures. a69c56fa88 Pin build until Skia is able to build with ToT abseil. da8fa1b615 Roll Chromium from 42826620a07f to babb076716bc (4096 revisions) 07137f571a Add ImageHelper to TextureWgpu 8c0dae388b Add conversion operator from ImmutableString to std::string ed97adba3d Add more RGB-to-RGBA byte loading functions 00eb6edba0 Rename LinkSubTask -> PostLinkTask 042b430c63 Support the wgpu backend on Windows 96f66089c2 Tests: Update color values for Unsized/Unsigned in texture tests f8b185771b Set the Dawn proc addresses at in DisplayWgpu initialization 7047d8205c win-trace (capture_replay_tests): cleanup after replay 21b5c32113 Pin abseil-cpp until Skia is able to build with ToT abseil. a3dff4ed6e third_party/clspv: Disable the warnings on build efd41bd207 Vulkan: Rename ResourceVk.* to vk_resource.* e3aac00be1 Vulkan: only request OPAQUE compositeAlpha on Android if no alpha 914fe61bc6 Vulkan: Rename RendererVk.* to vk_renderer.* 1fc548c115 Vulkan: enable recordable bit for RGB8 ebb94b807f Remove few redundant ImmutableString to std::string conversions 7cb518bc22 Reset shader images modified during trace 7506a0cdc0 Tests: update QDC expectations after crrev.com/c/5372826 2f934a47e9 libstdc++: replace std::powf with std:pow 6e6d6b2983 Roll vulkan-deps from fa1e68dabb91 to ba66ec69216d (8 revisions) d2cef82a8f Vulkan: Use fragment shading rate access flags 6d5690036a Vulkan: Deduplicate merge to Renderer's pipeline cache 490ff869e9 Always redeclare clip/cull distance built-ins f4ecbe6f13 Use Dawn's abseil build files when wgpu is enabled. afbfebcaaf Reland "Manual roll VK-GL-CTS from 87353392d2d2 to ec9827528085 (9 revisions)" 92b8fc6889 Revert "Manual roll VK-GL-CTS from 87353392d2d2 to ec9827528085 (9 revisions)" f8021cfa91 Manual roll vulkan-deps from 91aab7b7e25f to fa1e68dabb91 (27 revisions) 8080a736f1 Manual roll VK-GL-CTS from 87353392d2d2 to ec9827528085 (9 revisions) 21d124c4bf Vulkan: Remove support for pipeline cache control 553e3c8038 Vulkan: Async compile pipelines with different surface rotations 58065d0766 Vulkan: Add test that destroys view after the image c5f7bbeb11 Make ImmutableString::beginsWith constexpr 21ef298e33 Consider textures without an attached Buffer as incomplete 60aaf4a096 Vulkan: Move renderer to namespace vk b3ab67d32b tests: Remove unnecessary .get() from RAII objects d4d3478145 Multisampling support check: sampleCounts > 1 and createFlags 2dc45de80d Trace tests: check and log zlib crc32 on decompress failure 7220307bb2 Conditionally support EGL_OPENGL_API b5d92511b4 Trace tests: log z_stream on decompress failure c3fdc81189 Raise the WebGL texture size limit on Android >= 14 e5cb7f1f5c Vulkan: Fix access to inactive attributes 533fa5cedc Metal: Update few asserts when resolving FS output 9bae585946 Vulkan: Add blend factors to allow dithering to work 142c05b543 Build OpenCL CTS on ANGLE Linux and Android standalone bots afed1224de CL: Add CTS build to ANGLE cd90294be8 OpenCL/Vulkan: Add initial CL Event creation 66bc9cfa00 OpenCL: Fix mCallback in linkProgram ctor 17facd2b06 Fix CreateDirectory name clash with Windows headers. 18fa02bebf Rewrite exprs using separated decl variables cd220fa9ec Roll vulkan-deps from 6e41ca22e87b to 91aab7b7e25f (5 revisions) 5673346918 Roll Chromium from 63f2e96c7e8a to 42826620a07f (605 revisions) f7de39b6ae Make IntermRebuild available for all backends 065b333cad OpenCL/Vulkan: Add initial CL Buffer routines aea2abc1ad Vulkan: Input attachment requires both texturable and renderable da3baf096b Manual roll VK-GL-CTS from 1918ab4d4806 to 87353392d2d2 (15 revisions) b744ee7f16 Trace tests: extract debug files to (CAS) output 529a2fe904 Roll vulkan-deps from 3b14ca63bd7b to 6e41ca22e87b (21 revisions) 18e00a2989 Roll Chromium from d4320bd12d3a to 63f2e96c7e8a (593 revisions) a339585e1a Vulkan: Add AtomicShared type a55f91b566 Switch Pixel 6 experimental bot to Android U bc633ad708 OpenCL/Vulkan: Implement compile and link routines 99c2157b1d Metal: Add Quyen as OWNER d964482310 Make ANGLE by default built to system partition on Android b9c6cf8ecb Metal: Stop blit encoder after render encoder c9c7c4d74a Trace tests: save debug files when gz decompression fails 9fee915631 OpenCL/Vulkan: Add initial CL Kernel routines 7f3bb2d80f Roll Chromium from 93f3c55ed974 to d4320bd12d3a (756 revisions) f16eea308a Vulkan: Enable QCOM foveated rendering extensions e904e37ba3 Vulkan: Enable imageless framebuffer on Samsung drivers 11a2d27f32 Check array index against unsigned array size 26da3174dd Make 2024-03-05 changes compile with clang 15 pt.2 90ae6cbe39 Avoid assert at main prototype when monomorphizing 0f110098cc Avoid assert with multiple memory qualifiers c55c8ad21c extension XML cleanup 6ba49977d8 CL: Update OpenCL Headers 1452c19542 Android: Add Qualcomm Mobile Reference Device support a40eeaa9e0 Roll Chromium from 15a5ccdeffb7 to 93f3c55ed974 (614 revisions) ecaefce00c Vulkan: Disable optimizeWithLoadOp if there is unresolve 4667201495 Vulkan: Add test for midRenderPass clear for MSRTT aba3705ba7 Vulkan: Completely remove egl::Display from RendererVk 7e065b6f4d Fix SRV and RTV confliction 74af31adca GL: Add ClearsWithGapsNeedFlush workaround 4a5b9307be android_helper: support angle_deqp_egl_tests 49abf72f61 Roll vulkan-deps from 9cd617cb0454 to 3b14ca63bd7b (6 revisions) dcc79a2764 Roll Chromium from 632158ced47e to 15a5ccdeffb7 (1166 revisions) 91ddf851c4 Vulkan: support QCOM foveated rendering extensions 39f29f65c4 Ensure unary math op parse to an node on error c71de8688c Add workaround for ext dynamic state on Win/Intel 4e9fbb36f2 Metal: Remove AccessField(.., ImmutableString) e38cf95a58 Metal: Release prov. vertex buffers on event set 51702d791d Make 2024-03-05 changes compile with clang 15 d76505b8c3 Manual roll vulkan-deps from 12f9cddb3ff7 to 9cd617cb0454 (42 revisions) 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) acba61cb3e Fix Vulkan driver version for Win/Intel c758dc03c4 GL: Adjust disableRenderSnorm condition 6a88437dc1 Roll VK-GL-CTS from cf5313984f57 to d15e5faec700 (1 revision) db88630858 Roll VK-GL-CTS from c402aa4fc1f1 to cf5313984f57 (7 revisions) bd1b918a5a Roll vulkan-deps from 004d9803b30c to 602ab4120d74 (6 revisions) 33a3395599 Roll Chromium from cc824ffe820c to b54ff9b1d5ed (616 revisions) 5a4bfd61fd Metal: Separate struct definition from function return 7f29c70360 Roll vulkan-deps from b040470c0fde to 004d9803b30c (5 revisions) b06dbffd1c Roll Chromium from 5f0b8ba66cd4 to cc824ffe820c (635 revisions) cd63c5d477 Fix build failures targetting iOS 17.4 8c503c1b05 Add skip for 07753 validation error in trace bcf814fda5 Vulkan: Constrain the dependency on ContextVk in BufferHelper f43b9f87cf Roll vulkan-deps from 5fa0abb9413b to b040470c0fde (5 revisions) 0f6386a82e Roll Chromium from 98827507560a to 5f0b8ba66cd4 (624 revisions) f546983cc8 Add test and skip for 07753 validation error 8346addbd0 Contain X11 includes and free usage of common terms 1ee04579b4 Metal: Re-enable asm inejction into loops on MacOS 12+ 21c0d31cd6 OpenCL: Only build clspv for Vk backend b7bacdb746 GL: Generate mipmaps through draw calls on Pixel7/Pixel8. 2b1ef00ad5 Metal: Fix validation for anonymous struct arrays 19e21b1e0b OpenCL/Vulkan: Add initial support for cmdQueue f4d5644c9f Instantiate dawn backend in angle_end2end_tests b7d0a18bb1 Roll vulkan-deps from 13783d616289 to 5fa0abb9413b (10 revisions) 9f16b585cb Roll Chromium from 2905059a5737 to 98827507560a (299 revisions) e17dd5a408 Roll vulkan-deps from 063ea20a64fc to 13783d616289 (25 revisions) e3badd04cc Roll Chromium from 9d4a35b46e1e to 2905059a5737 (725 revisions) e04b7c7392 Vulkan: Expand feature to enable sample usage for all AHBs e08e82b6de CL: On kernel arg validation use right sizes 9d453e579e Fix ASSERT in non-global precise var decls bde26cc4de Roll VK-GL-CTS from b9ec0d4bdf99 to c402aa4fc1f1 (13 revisions) 372876879b Android: support running angle_unittests via android_helper a6616081f2 Add missing include af56ca61bb OpenCL/Vulkan: Initial support for context 298abbc156 Roll Chromium from 29bec8631d2f to 9d4a35b46e1e (1220 revisions) 3ca8befb24 Vulkan: Handle multi-context apps in pipeline cache graphs 6607a2b98d Vulkan: Add support for VK_EXT_vertex_input_dynamic_state bff0b1e43d Change enum value for webgpu to unused value. 6d4706bfb9 WGPU: Add a angle_dawn_dir build override. aa244358af Reland "Vulkan: Get rid of X11 include in DisplayVkXcb.cpp" 6d589ff6a3 Trace perf: support custom thermal throttling for tests ec2603d69f Fix build in absence of SSE support b380ed1f98 Vulkan: Add EGL_ANGLE_global_fence_sync 40dfb3a8bd Fix length() translation for clip/cull distance arrays d6ceac9159 Metal: Add support for binding slices to images 195c142d7e GLSL test for side effects in prune-able loop e8a3493f80 Initialize DisplayWgpu 2cae27c296 Vulkan: Enable the doubleDepthBiasConstantFactor feature on NV 197beb4de8 Metal: Crash if for loop body is optimized away dbc6bd9d4e Reland "Vulkan: Fix alignment issues with SecondaryCommandBuffer" c673c83758 OpenCL/Vulkan: Initial support for platform/device b8e56d5d6d Fix an assert when overwriting TexImage binding 243f8ad99f Revert "Vulkan: Fix alignment issues with SecondaryCommandBuffer" 7490ad4d79 Roll vulkan-deps from 2cedf06e4cdf to 063ea20a64fc (7 revisions) d8340c15c7 Roll Chromium from b650d7fcd665 to 29bec8631d2f (631 revisions) e53270c9ca Vulkan: Fix alignment issues with SecondaryCommandBuffer e45b2fd89d Vulkan: Implement ANGLE_translated_shader_source d9665098a3 Do not use hardcoded ".cr.so" extension for android component builds 9d344b5c82 Uniform block reference in constuctors crash ebc151d514 Roll vulkan-deps from 4985acbd814d to 2cedf06e4cdf (12 revisions) 2cbf6613c1 Roll Chromium from 3009d13b1e1a to b650d7fcd665 (3044 revisions) cb7d3cc206 Treat clip/cull distance built-ins as having side effects e784b1ec82 Manual roll dawn 239e8caa44 Capture/Replay: Disallow concurrent ninja processes. 9fd5167e1f Roll vulkan-deps from 3834da2004ec to 4985acbd814d (77 revisions) eaddd3baa5 Vulkan: use linear chroma filter for ycbcr by default 1d752a10a7 Roll Chromium from c1ca24b91ed5 to 3009d13b1e1a (567 revisions) 275e6f4fc5 D3D: Add multiplanar support to d3d11 glTexSubImage2D e489dac03a Allow BGRA -> RGBA for glCopyTex[Sub]Image 5d9abeca4a Revert "Suppress VUID-VkGraphicsPipelineCreateInfo-dynamicRendering-06576" 56e5fa804b Mark bison deps as not shipped 58ccdab977 Roll VK-GL-CTS from b3344240e7fc to b9ec0d4bdf99 (8 revisions) c3d06480e5 Add dawn to IGNORED_DIRECTORIES. 73fa1b08d0 Use -fno-define-target-os-macros for libpng 3ad163d091 Vulkan: Don't attach format features 2 version of AHB structure 475784f5a6 suppress VUID-VkPipelineVertexInputStateCreateInfo-pNext-pNext c603a4f199 Don't perf warn about ETC1->ETC2 emulation as it is efficient ef78e57015 Revert "Vulkan: disable warmUpPipelineCacheAtLink for Venus" Canonical link: https://commits.webkit.org/276989@main

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

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

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

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

@x

https://bugs.webkit.org/show_bug.cgi?id=293337 rdar://151740794 Reviewed by Yijia Huang and Justin Michaud. The current MovHintRemoval's analysis looks weird. We should just do liveness analysis globally and use this information for MovHint removal. 1. "Use" is a node which may exit. When exit happens, we should keep all use of live locals at this bytecode exit location alive. 2. "Def" is MovHint. We kill the locals here. And doing fixpoint analysis and using this information to remove MovHint. Also, pruning Availability in OSRAvailabilityAnalysisPhase via bytecode liveness is wrong: they need to keep live nodes from DFG for example. 0: PutHint @x, PROP(@y) 1: OSR exit point #1 (here, loc0 is not alive) 2: -- Pruning happens -- 3: MovHint @x, loc0 4: OSR exit point #2 (here, loc0 is alive) In this case pruning point will remove (0)'s heap availability since @x is not alive from bytecode at (1), but this is wrong as we need this in (4). In this patch, we remove pruneByLiveness in DFGOSRAvailabilityAnalysisPhase. This pruning should happen by the user of DFGOSRAvailabilityAnalysisPhase instead, and it is already happening (see FTLLowerToB3's pruneByLiveness in exit site, which is right. And ObjectAllocationSinking is pruning with CombinedLiveness, this is right since it also accounts Node's liveness in addition to bytecode's liveness.). Let's just make availability just compute the availability for all things, and then we prune some of unnecessary ones at each use of this information. * Source/JavaScriptCore/dfg/DFGMovHintRemovalPhase.cpp: * Source/JavaScriptCore/dfg/DFGOSRAvailabilityAnalysisPhase.cpp: (JSC::DFG::OSRAvailabilityAnalysisPhase::run): Canonical link: https://commits.webkit.org/295369@main

https://bugs.webkit.org/show_bug.cgi?id=293456 Reviewed by Antti Koivisto. 1. setPreferredLogicalWidthsDirty was introduced at 17615@main modeled after setNeedsLayout 2. As with setNeedsLayout, setPreferredLogicalWidthsDirty has the ability to only mark the current renderer dirty (as opposed to the default behavior of marking ancestors as well) 3. Initially (17615@main) MarkOnlyThis was passed in only on the RenderView (as it has no parent) 4. Later at 17621@main, MarkOnlyThis was used to fix a specific bug where an absolute positioned box with percent padding had incorrect size after viewport resize. Here is what happened there: RenderView RenderBlockFlow (html) RenderBlockFlow (body) RenderBlockFlow (absolute positioned box with % padding) - absolute positioned box uses shrink-to-fit sizing when width is auto. The final width is the combination of its min/max widths and the available space. - % padding is resolved against the containing block's width. Now with viewport resize, where the absolute positioned box's containing block is the RenderView - min/max _content_ values stay the same but - the viewport's new size affects the padding value so the box's final min/max values do change. Min/max values (aka preferred width) are cached on the renderers and we don't recompute them unless PreferredLogicalWidthsDirty bit is set to true (similar to needsLayout bit). We mark renderers dirty in two distinct places: #1 when content/style changes before layout or #2 during layout as we figure we need to invalidate more content In many cases (e.g. resize) in order to evaluate the extent of the damage up front and mark all affected renderers dirty would require a full tree walk, so instead we rely on layout to mark additional renderers dirty as needed. ...which is how we fixed the viewport resize bug in 17621@main. if (RelayoutChildren::Yes && renderer.preferredWidthDependsOnAvailableSpace()) renderer.setPreferredLogicalWidthsDirty(true, MarkOnlyThis) - check during layout if the current renderer's final width depends on the available space - if it does, mark the preferred widths dirty This ensures that by the time we get to computeLogicalWidth() -where we compute the final size of the renderer- preferredLogicalWidths bit is already dirty. It guarantees that we re-compute our min/max values, allowing the new padding value to be incorporated. Now consider a scenario where this positioned box has fixed width (e.g. width: 100px) - we still mark preferred widths dirty (we have to) but - in computeLogicalWidth(), we will not re-compute them as we simply take the fixed width (instead of running the shrink-to-fit logic) - and preferredWidths stays dirty So just because we have a box with preferredWidthDependsOnAvailableSpace(), it does not necessarily mean we run shrink-to-fit sizing and as a result we may not clear the dirty bit. ...and this is where setPreferredLogicalWidthsDirty differs from setNeedsLayout. Whenever we call setNeedsLayout(MarkOnlyThis), it is always followed by a layoutIfNeeded() call, clearing the needsLayout bit, while preferredWidths may remain dirty. While it is crucial that no needsLayout bit is set as returning from layout, preferredWidths bits can stay dirty throughout the entire lifetime of a renderer if they are never used. The reason why having a stuck dirty bit is problematic though, is because we rely on them when marking ancestor chain dirty. The default behavior of both needsLayout and preferredLogicalWidthsDirty is MarkContainingBlockChain (when a renderer changes it's likely that parent changes too). With MarkContainingBlockChain, we climb the ancestor chain and mark containers dirty, unless we find an already dirty container. This performance optimization helps to avoid to walk the ancestor chain every time a renderer is marked dirty, but it also assumes that if a renderer is dirty all its ancestors are dirty as well. So now JS mutates some style and we try to mark our ancestor chain dirty to let our containers know that at the subsequent layout they need to re-compute their min/max values if their sizing relies on them. ...but in setPreferredLogicalWidthsDirty, we bail out too early when we come across this stuck renderer and never mark the parents dirty. So maybe 17621@main should have picked MarkContainingBlockChain and not MarkOnlyThis to fully invalidate the ancestor chain. Before considering that let's take a look at how min/max values are used. In block layout we first visit the parent, compute its width and descend into the children and pass in the parent width as available space. If the parent's width depends on the size of the children (e.g. width: min-content), we simply ask the children for their min/max widths. There's a special "preferred width" codepath in our block layout implementation. This codepath computes min/max widths and caches them on the renderers. Important to note that this happens _before_ running layout on the child renderers. (this may sound like some form of circular dependency, but CSS spec is clear about how to resolve cases where child min/max widths depend on the final size of the parent width) What it means is by the time we run layout on a renderer, the parent may have already "forced" the renderer to re-compute the stale min/max widths. So now imagine we are in the renderer's layout code now and come across this line if (RelayoutChildren::Yes && renderer.preferredWidthDependsOnAvailableSpace()) renderer.setPreferredLogicalWidthsDirty(true, MarkOnlyThis) This makes us to re-compute the min/max values even if they are clean (and this is the result of not being able to effectively run invalidation up front, before layout) With MarkOnlyThis, the worst case scenario (beside the sticky bit bug) is that we may end up running min/max computation twice; first triggered by our parent followed by this line above. However, with MarkContainingBlockChain, we would keep re-computing valid and clean min/max values at every layout on the ancestors as well. (as ancestors would see their dirty min/max values at the next layout the first time and then they would re-compute them, followed by us marking them dirty again and so on) While MarkContainingBlockChain is normally what we do as changing min/max values on the child may affect the ancestors too, it is too late to use it at layout due to block layout's "preferred width first -> layout second" order. The fundamental issue here is that we can't tell if the renderer's min/max values got cleared in the current layout frame by ancestors running preferred with computation on their subtree. If we could, we would either 1, not call renderer.setPreferredLogicalWidthsDirty(true, MarkOnlyThis) at all i.e. min/max values are really really clear, so let's just reuse them 2, or call it by passing in MarkContainingBlockChain (and go with #1 at subsequent layout if applicable) TLDR; While it's okay for preferredWidths to stay dirty across layouts, when a renderer is dirty all its ancestors have to be dirty. Calling setPreferredLogicalWidthsDirty() with MarkOnlyThis during layout is also fine as long as we managed to clear it before finishing layout. Here let's just fix the sticky bit by making sure ancestor chain is always fully marked. - add a rare bit to indicate if we used MarkOnlyThis on this renderer - adjust the "if this renderer dirty its parent must be dirty" logic by consulting the MarkOnlyThis bit. * LayoutTests/fast/dynamic/percent-padding-with-shrink-to-fit-parent-expected.html: Added. * LayoutTests/fast/dynamic/percent-padding-with-shrink-to-fit-parent.html: Added. * Source/WebCore/rendering/RenderObject.cpp: (WebCore::RenderObject::setPreferredLogicalWidthsDirty): (WebCore::RenderObject::invalidateContainerPreferredLogicalWidths): * Source/WebCore/rendering/RenderObject.h: Canonical link: https://commits.webkit.org/295501@main

…eleted and re-entered into an input https://bugs.webkit.org/show_bug.cgi?id=294558 <rdar://problem/154094432> Reviewed by Antti Koivisto. 1. RenderTextControlSingleLine's inner renderer is vertically centered. 2. RenderTextControlSingleLine's inner renderer provides the baseline position for the input box. 3. The baseline position is passed to inline layout and is used to align other content on the line (when baseline alignment applies). As text is appended to the input box: 1. An empty RenderText is constructed and inserted into the tree. 2. InsertIntoTextNodeCommand::doApply() is called. 3. RenderText is populated by calling setText. In step #2, layout is prematurely run on the content (see passwordEchoEnabled) before it is populated in step #3. This layout generates an empty inline display content with a 0px-tall line box, which gets vertically centered. This "centered line" then becomes the baseline for the rest of the content. In step #3, another layout is run on the input box, this time with populated content, but the layout is limited to the input only, so adjacent content does not get alignment treatment. This is how the offset occurs (result of the premature layout). There are a few issues here: 1. We should not run layout on the empty content before RenderText is populated (webkit.org/b/294880). 2. RenderTextControlSingleLine should not center the inner renderer when it has no content (webkit.org/b/294881). 3. IFC should not report valid line boxes when there’s no content at all (i.e., when no display boxes are generated). This patch addresses issue #3. * LayoutTests/fast/editing/incorrect-baseline-for-input-adjacent-content-expected.html: Added. * LayoutTests/fast/editing/incorrect-baseline-for-input-adjacent-content.html: Added. * Source/WebCore/layout/integration/inline/LayoutIntegrationLineLayout.cpp: (WebCore::LayoutIntegration::LineLayout::firstLineBox const): (WebCore::LayoutIntegration::LineLayout::lastLineBox const): Canonical link: https://commits.webkit.org/296569@main

https://bugs.webkit.org/show_bug.cgi?id=296470 rdar://79416560 Reviewed by Tim Horton. Added support for tooltips on Catalyst. This includes: - Linking UIKitMacHelper - Declaring needed protocols and interfaces - Implementing toolTipChanged The bulk of the functionality is in -[WKContentView _toolTipChanged:], which creates a UIToolTipInteraction if it doesn't exist. If a UIToolTipInteraction exists, we update the UIToolTipInteraction with the tooltip's new string. Notice, _toolTipChanged's has a windowChangedKeyState call and uses a UINSSharedApplicationDelegate. This is for updating the tooltip after the initial creation. Implementing UIToolTipInteractionDelegate's toolTipInteraction:configurationAtPoint: is not enough to update the tooltip because... 1. UIView's addInteraction and removeInteraction are only for separate views. That is, if there are tooltips A and B on the same view, whichever tooltip is triggered first will stay no matter where you hover within the view. The interaction is not removed until you move your mouse to a different view. 2. There is no API to update (text or show/hide) the tooltip while it is displayed. To work around #2, we need to indirectly trigger AppKit's _displayToolTipIfNecessaryIgnoringTime, which is the logic to update the tooltip, but through UIKit. See below for more details. * Source/WTF/wtf/PlatformHave.h: * Source/WebKit/Configurations/WebKit.xcconfig: * Source/WebKit/Platform/spi/ios/UIKitSPI.h: These files above have necessary declarations that are used for working around #2, adding a HAVE macro, and linking UIKitMacHelper. * Source/WebKit/UIProcess/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::toolTipChanged): Calls -[WKContentView _toolTipChanged:], which contains the logic for supporting tooltips. * Source/WebKit/UIProcess/ios/WKContentViewInteraction.h: * Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _toolTipChanged:]): This is where the support is implemented. To circumvent #2, we first use UINSSharedApplicationDelegate, which is a UINSApplicationDelegate, then obtaining a UINSWindow. UINSWindow has a UINSSceneView that has a NSViewDynamicToolTipManager property. The NSViewDynamicToolTipManager can be used to call windowChangedKeyState. We call windowChangedKeyState to trigger a chain of function calls that will eventually trigger the update tooltip function. The chain is as follows: windowChangedKeyState calls _restartMovementTracking which calls _displayToolTipIfNecessaryIgnoringTime, which updates the tooltip. (-[WKContentView toolTipInteraction:configurationAtPoint:]): Canonical link: https://commits.webkit.org/297878@main

https://bugs.webkit.org/show_bug.cgi?id=296902 rdar://157510912 Reviewed by Yusuke Suzuki. Currently, we support both aligned allocations (e.g. bmalloc_allocate_with_alignment) and zeroed allocations (e.g. bmalloc_allocate_zeroed); however, we do not support simultaneously-aligned-and-zeroed allocations (e.g. bmalloc_allocate_zeroed_with_alignment). This patch implements those. The consumer of the API can just zero it themselves, but libpas is careful to optimize out that zeroing operation if it knows it’s not necessary, e.g. if the page was newly mmap’d (c.f. pas_allocation_result_zero). This comes up when allocating wasm memory, as we basically 1. Ask for a huge allocation 2. Mmap over it to ensure it’s zero This is probably not itself a huge performance problem, but it does show up when I tried to switch that #2 over to madvise(MADV_ZERO): normally this would be preferable because this subsequent mmap would fragment the backing vm-objects (and acquire more locks), but in the case that we’re just replacing the entire vm-object anyways the first downside goes away, after which presumably the actual effort of going page-by-page and making sure they’re zeroed begins to dominate. Creating this new bmalloc_allocate_zeroed_with_alignment family of functions will thus allow us to avoid that unnecessary mmap and unblock migrating it to use madvise(MADV_ZERO) instead. Canonical link: https://commits.webkit.org/298428@main

https://bugs.webkit.org/show_bug.cgi?id=297724 rdar://157024791 Reviewed by Antti Koivisto. 1. out-of-flow boxes participate first in in-flow layout as if they were in-flow boxes where we compute their static position. This static position becomes their final position when inset (left, right, top, bottom) is auto. 2. as a second step, as we reach the out-of-flow box's containing block we run layout again and compute the final position (this might just be what we computed at #1 in case of auto inset) Now we mark the out-of-flow box dirty at #1 and expect #2 to clear the box by moving it to its final position. However in case of subtree layout where the layout root has an out-of-flow descendant while the containing block is an ancestor of the layout root, #2 will never happen (we bail out of layout before reaching the containing block). "setNeedsLayout" was added at 254969@main to mimic what legacy line layout did. However starting from 262470@main, we already move the box at #1 meaning that #2 does not need to happen if the box is statically positioned only. (If the out-of-flow box was not-statically positioned, subtree layout would not start "below" its containing block) * LayoutTests/TestExpectations: * Source/WebCore/layout/integration/inline/LayoutIntegrationLineLayout.cpp: (WebCore::LayoutIntegration::LineLayout::updateRenderTreePositions): Canonical link: https://commits.webkit.org/299021@main

@0

https://bugs.webkit.org/show_bug.cgi?id=299504 rdar://161294228 Reviewed by Yijia Huang. Previous one 300327@main worked for the same basic block's load, but it didn't work for the load in dominators. This patch updates CSE rules to make immutable load elimination work with dominators' load. Like, BB#0 @0: Load(@x, immutable) @1: CCall(...) # potentially clobber everything Branch ... #1, #2 BB#1 @2: CCall(...) # potentially clobber everything Jump #3 BB#2 @3: CCall(...) # potentially clobber everything Jump #3 BB#3 @4: Load(@x, immutable) ... Then @4 should be replaced with Identity(@0) as dominator BB#0 is having immutable load @0 matching to @4. Tests: Source/JavaScriptCore/b3/testb3_1.cpp Source/JavaScriptCore/b3/testb3_8.cpp * Source/JavaScriptCore/b3/B3EliminateCommonSubexpressions.cpp: * Source/JavaScriptCore/b3/testb3.h: * Source/JavaScriptCore/b3/testb3_1.cpp: (run): * Source/JavaScriptCore/b3/testb3_8.cpp: (testLoadImmutableDominated): (testLoadImmutableNonDominated): Canonical link: https://commits.webkit.org/300562@main

…on-in-child.html is failing https://bugs.webkit.org/show_bug.cgi?id=299628 rdar://161203486 Reviewed by Basuke Suzuki. Suppose we have a mainframe and an iframe and this series of navigations happens: 1. iframe fragment navigates to "/#a" 2. main frame fragment navigates to "/#1" 3. main frame fragment navigates to "/#2" 4. main frame fragment navigates to "/#3" 5. iframe goes back 6. iframe fragment navigates to "/#b" After Step 5, the UI Process b/f list should be: A) mainframe - URL - ItemID A ** iframe - URL - ItemID A B) mainframe - URL - ItemID B ** iframe - URL/#a - ItemID B C) mainframe - URL/#1 - ItemID C ** iframe - URL/#a - ItemID C D) mainframe - URL/#2 - ItemID D ** iframe - URL/#a - ItemID D E) mainframe - URL/#3 - ItemID E ** iframe - URL/#a - ItemID E The mainframe's Navigation object's m_entries should be: A) mainframe - URL - ItemID A C) mainframe - URL/#1 - ItemID C D) mainframe - URL/#2 - ItemID D E) mainframe - URL/#3 - ItemID E <--- current index The iframe's Navigation object's m_entries should be: A) ** iframe - URL - ItemID A <--- current index E) ** iframe - URL/#a - ItemID E According to this layout test, after Step 6: The mainframe's Navigation object's m_entries should be: A) mainframe - URL - ItemID A <--- current index The iframe's Navigation object's m_entries should be: A) ** iframe - URL - ItemID A F) ** iframe - URL/#b - ItemID F <--- current index So when a subframe has a PUSH same-document navigation and disposes of any forward entries, any parent frame must do the same. This test was failing because the parent frame was not disposing of its forward entries. To fix this, we add a new function to recusively dispose of all forward entries in any parent frames when a subframe has a PUSH same-document navigation. We use the ItemID to determine what entry must stay and then dispose of any entries that come after that one. * LayoutTests/imported/w3c/web-platform-tests/navigation-api/per-entry-events/dispose-for-navigation-in-child-expected.txt: * Source/WebCore/page/LocalDOMWindowProperty.cpp: (WebCore::LocalDOMWindowProperty::protectedFrame const): * Source/WebCore/page/LocalDOMWindowProperty.h: * Source/WebCore/page/Navigation.cpp: (WebCore::Navigation::updateNavigationEntry): (WebCore::Navigation::disposeOfForwardEntriesInParents): Call recursivelyDisposeOfForwardEntriesInParents on the main frame, which will traverse down the frame tree, and for each frame until we reach the subframe that actually navigated, dispose of any forward entries. (WebCore::Navigation::recursivelyDisposeOfForwardEntriesInParents): (WebCore::Navigation::updateForNavigation): This is called for same-document navigations. If it's a PUSH navigation, call disposeOfForwardEntriesInParents. The ItemID that we keep in these parent frames is the current ItemID right before this PUSH operation happens. * Source/WebCore/page/Navigation.h: Canonical link: https://commits.webkit.org/300721@main

…ia-labelledby) https://bugs.webkit.org/show_bug.cgi?id=303969 rdar://74236057 Reviewed by Tyler Wilcock. This patch allows for aria-live announcements to start respecting accessible text. Prior to this patch, we only respected image alt text via the text iterator. But, by switching to `textUnderElement`, and updating shouldIncludeInSnapshot and textForObject, we can properly handle alternative text. The shouldIncludeInSnapshot change is necessary, since alternative text should prevent textual children from being included in an object's text. There are two important changes to `textForObject`: (1) Most text is computed using textUnderElement rather than using text marker ranges. This allows us to use the alternative text handling already built into this method (with one caveat as described in #2). (2) `textUnderElement` only returns alt. text for descendants of its calling node. This means, if the object we want text for has an aria-label, that won't get considered. This is why we return the description (which accounts for alt text, aria-label, etc.) before using textUnderElement. `TextUnderElementMode` has two new options specifically used by live regions: - includeListMarkers: will return list marker text for list marker objects. - descendIntoContainers: allows textUnderElement to scoop up text for table, tree, and list descendants. Lastly, I added a new parameter, `prependNewline`, to appendNameToStringBuilder. This allows textUnderElement to insert newlines when appropriate (for example, after list items). To preserve existing behavior, if we are already inserting a space before an object, we will not also insert a newline. In the future, we should make `textUnderElement` respect the text emission behavior of objects, instead of inserting spaces. Tests: accessibility/mac/live-regions/live-region-aria-label.html accessibility/mac/live-regions/live-region-img-alt.html * LayoutTests/accessibility/mac/live-regions/live-region-aria-label-expected.txt: Added. * LayoutTests/accessibility/mac/live-regions/live-region-aria-label.html: Added. * LayoutTests/accessibility/mac/live-regions/live-region-img-alt-expected.txt: Copied from LayoutTests/accessibility/mac/live-regions/live-region-removals-expected.txt. * LayoutTests/accessibility/mac/live-regions/live-region-img-alt.html: Added. * LayoutTests/accessibility/mac/live-regions/live-region-removals-expected.txt: * LayoutTests/accessibility/mac/live-regions/live-region-with-atomic-expected.txt: * Source/WebCore/accessibility/AXCoreObject.h: * Source/WebCore/accessibility/AXLiveRegionManager.cpp: (WebCore::AXLiveRegionManager::buildLiveRegionSnapshot const): (WebCore::AXLiveRegionManager::shouldIncludeInSnapshot const): (WebCore::AXLiveRegionManager::textForObject const): (WebCore::AXLiveRegionManager::computeAnnouncement const): * Source/WebCore/accessibility/AXLogger.cpp: (WebCore::operator<<): * Source/WebCore/accessibility/AccessibilityNodeObject.cpp: (WebCore::shouldUseAccessibilityObjectInnerText): (WebCore::appendNameToStringBuilder): (WebCore::shouldPrependNewline): (WebCore::AccessibilityNodeObject::textUnderElement const): (WebCore::accessibleNameForNode): * Source/WebCore/accessibility/AccessibilityNodeObject.h: * Source/WebCore/accessibility/AccessibilityRenderObject.cpp: (WebCore::AccessibilityRenderObject::textUnderElement const): Canonical link: https://commits.webkit.org/304318@main

https://bugs.webkit.org/show_bug.cgi?id=310082 rdar://172722059 Reviewed by Dan Hecht. Previously, there were two distinct behaviors for this macro on Darwin. 1. PAS_ASSERT with two or more arguments would store the __LINE__ and subsequent arguments in registers, then properly execute `brk 0xc471` to crash. 2. PAS_ASSERT with one argument would do none of that, and fall through to __builtin_unreachable() on the assumption that it would be implemented as a trap. The actual benefit of #2 seems to be minimal, if anything, while having the downside of obfuscating crash logs (among other things). Barring some horrific unforseen perf regression, this seems like the obvious thing to do. Here's some example asm before/after (in this case, pas_segregated_page_switch_lock_slow) before: ``` JavaScriptCore`pas_segregated_page_switch_lock_slow: 0x104686b70 <+0>: pacibsp 0x104686b74 <+4>: sub sp, sp, #0x30 0x104686b78 <+8>: stp x20, x19, [sp, #0x10] 0x104686b7c <+12>: stp x29, x30, [sp, #0x20] 0x104686b80 <+16>: add x29, sp, #0x20 0x104686b84 <+20>: str x1, [sp, #0x8] 0x104686b88 <+24>: cmp x1, x2 0x104686b8c <+28>: b.eq 0x104686c20 ; <+176> [inlined] pas_assertion_failed at pas_utils.h:248:5 0x104686b90 <+32>: mov x20, x2 0x104686b94 <+36>: mov x19, x0 0x104686b98 <+40>: cbz x1, 0x104686bbc ; <+76> [inlined] os_unfair_lock_trylock_inline at lock_private.h:784:20 0x104686b9c <+44>: mrs x8, TPIDRRO_EL0 ... 0x104686c0c <+156>: ldr x0, [sp, #0x8] 0x104686c10 <+160>: ldp x29, x30, [sp, #0x20] 0x104686c14 <+164>: ldp x20, x19, [sp, #0x10] 0x104686c18 <+168>: add sp, sp, #0x30 0x104686c1c <+172>: retab -> 0x104686c20 <+176>: brk #0x1 ``` after: ``` JavaScriptCore`pas_segregated_page_switch_lock_slow: 0x1045d688c <+0>: pacibsp 0x1045d6890 <+4>: sub sp, sp, #0x30 0x1045d6894 <+8>: stp x20, x19, [sp, #0x10] 0x1045d6898 <+12>: stp x29, x30, [sp, #0x20] 0x1045d689c <+16>: add x29, sp, #0x20 0x1045d68a0 <+20>: str x1, [sp, #0x8] 0x1045d68a4 <+24>: cmp x1, x2 0x1045d68a8 <+28>: b.eq 0x1045d693c ; <+176> [inlined] pas_assertion_failed_noreturn_silencer0 at pas_utils.h:314:5 0x1045d68ac <+32>: mov x20, x2 0x1045d68b0 <+36>: mov x19, x0 0x1045d68b4 <+40>: cbz x1, 0x1045d68d8 ; <+76> [inlined] os_unfair_lock_trylock_inline at lock_private.h:784:20 0x1045d68b8 <+44>: mrs x8, TPIDRRO_EL0 ... 0x1045d6928 <+156>: ldr x0, [sp, #0x8] 0x1045d692c <+160>: ldp x29, x30, [sp, #0x20] 0x1045d6930 <+164>: ldp x20, x19, [sp, #0x10] 0x1045d6934 <+168>: add sp, sp, #0x30 0x1045d6938 <+172>: retab -> 0x1045d693c <+176>: bl 0x104732c60 ; set_up_range.cold.16 at pas_designated_intrinsic_heap.c ``` The only inline impact is that the `brk` is replaced with a `bl` to out-of-line code that handles the actual register fiddling. Unfortunately, this does require obviating some of 309224@main, as these non-inline functions fall afoul of TAPI's checks for symbol-availability, as it'd be libpas.a that contains the symbol and not bmalloc per se. There are ways to get around that but they're pretty disruptive, so for now we'll have to go without __LINE__ information for BAssert. This isn't a regression since BAssert was only wired up to the single-argument PAS_ASSERT, which as we've seen, did not actually implement that desired behavior. Canonical link: https://commits.webkit.org/309669@main

…ning inline boxes https://bugs.webkit.org/show_bug.cgi?id=308696 Reviewed by Antti Koivisto. 1. 303091@main: we started creating empty (inline box) display boxes to be able to provided offsetTop/offsetHeight values for cases like <div> content<br> <span id=empty-inline-box></span> </div> where before the fix, the trailing <span> did not initiate any display boxes (empty line). 2. However after 303091@main, we also started creating empty display boxes for _line_spanning_ inline boxes when we couldn't fit any content on the line due to intrusive floats. <div> content <float><span> this does not fit the line due to the float here</span> </div> and this turned out to be not web-compatible. 3. 307916@main and 308175@main addressed this issue by filtering the display box rects as we collect them in RenderInline's generateLineBoxRects (this is called by functions like offsetHeight etc. Let's fix oven-sh#2 and undo oven-sh#3. * LayoutTests/fast/inline/empty-inline-box-bounding-rect.html: * Source/WebCore/layout/formattingContexts/inline/display/InlineDisplayContentBuilder.cpp: (WebCore::Layout::InlineDisplayContentBuilder::processNonBidiContent): * Source/WebCore/rendering/RenderInline.cpp: (WebCore::RenderInline::generateLineBoxRects const): Canonical link: https://commits.webkit.org/308289@main

…o fit-content https://bugs.webkit.org/show_bug.cgi?id=242837 <rdar://problem/97492632> Reviewed by Antti Koivisto. Given: <div style="position: absolute; inset: 0; height: fit-content"> <div style="height: 100%"> <div style="height: 80px"></div> </div> </div> The out-of-flow container is sized to 0px, while the correct height is 80px. availableLogicalHeightForPercentageComputation has a condition that decides if an out-of-flow element's height is definite for its children's percentage resolution. It has two branches: 1. height is specified (length/percent/calc) -> definite 2. both insets are set -> definite is always definite and can be used to resolve the percent height. However with content-dependent values like fit-content, answering "how tall is the parent?" requires laying out the children first - but the child is asking precisely because it needs that answer to size itself. That's a cyclic dependency, so the answer should be "indefinite" and the percentage falls back to auto. The fix restricts #2 to height:auto. For intrinsic keywords, availableLogicalHeightForPercentageComputation now returns nullopt and the child's percentage falls back to auto. * LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/abspos-intrinsic-height-inset-percentage-child-expected.txt: Added. * LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/abspos-intrinsic-height-inset-percentage-child.html: Added. * Source/WebCore/rendering/RenderBlock.cpp: (WebCore::RenderBlock::availableLogicalHeightForPercentageComputation const): Canonical link: https://commits.webkit.org/311375@main

https://bugs.webkit.org/show_bug.cgi?id=312485 rdar://174932570 Reviewed by Yusuke Suzuki. Use value - trunc(value) == 0.0 for isInteger, which rejects NaN and Infinity without an explicit isFinite check since NaN - NaN and Inf - Inf both produce NaN. Add MacroAssembler::isDoubleInteger helper and use it in the DFG NumberIsInteger path, removing the manual exponent-bit extraction branch. Simplify the FTL NumberIsInteger path similarly using B3 IR. Remove redundant isFinite checks from DFG and FTL NumberIsSafeInteger, since the range check against maxSafeInteger already rejects Infinity. On ARM64 the difference in codegen is roughly: isIntegerOld(double): frintz d1, d0 fmov x8, d0 mov w9, WebKit#2047 ubfx x8, x8, #52, #11 fcmp d1, d0 ccmp x8, x9, #2, eq cset w0, lo ret isIntegerNew(double): frintz d1, d0 fsub d0, d0, d1 fcmp d0, #0.0 cset w0, eq ret No new tests, no behavior change. Covered by existing tests. Canonical link: https://commits.webkit.org/311413@main

…ParentheticalAssertionBegin.bt https://bugs.webkit.org/show_bug.cgi?id=314249 rdar://176255579 Reviewed by Sosuke Suzuki. The following code crashes. /(^(?!(X|Y))c|Zc){2}/.exec("cccccc") The pattern is in this way. RegExp pattern for /(^(?!(X|Y))c|Zc){2}/: callframe size: 9 alternative #0: minimum size: 0,once through,contains ^ < > captured inputPosition 0 subpattern oven-sh#1 {2},frame location 0 alternative list,frame location 4 alternative #0: minimum size: 1,fixed size,starts with ^,contains ^ < > BOL < > inputPosition 0 inverted assertion,frame location 5 minimum size: 1, last alternative < > captured inputPosition 1 subpattern oven-sh#2,frame location 6 alternative list,frame location 8 alternative #0: minimum size: 1,fixed size < > character inputPosition 0 'X' alternative oven-sh#1: minimum size: 1,fixed size, last alternative < > character inputPosition 0 'Y' < > character inputPosition 0 'c' alternative oven-sh#1: minimum size: 2,fixed size, last alternative < > character inputPosition 0 'Z' < > character inputPosition 1 'c' alternative oven-sh#1: minimum size: 0 < > captured inputPosition 0 subpattern oven-sh#1 {2},frame location 0 minimum size: 2,fixed size < > character inputPosition 0 'Z' < > character inputPosition 1 'c' Problematic part is inverted-assertion `(?!(X|Y))`. When you failed to match in the 2nd iteration of `(^(?!(X|Y))c|Zc){2}`, we do backtracking to find a way to fit in the 1st iteration. And backtracking code in `(?!(X|Y))` is generated in this way. ---- NestedAlternativeNext[0].m_contentBacktrackEntryLabel = HERE (P) ---- ParentheticalAssertionEnd backtrack ; (no code emitted for inverted/no-captures) SimpleNestedAlternativeEnd backtrack ; (no code emitted) ParenthesesSubpatternOnceEnd backtrack ; (no code emitted for FixedCount) NestedAlternativeEnd backtrack (inner disjunction): ldr x16, [fp - inner_returnAddressIndex] br x16 But we have never write any continuation jump target inside `(X|Y)` alternatives. The reason is this is negative-assertion: so `(X|Y)` is just failing completely so there is no point to resume backtracking. And that's right because assertion is *atomic*: it is not consuming any characters and it is just look-ahead. This means that any backtracking inside assertion does not change character position, thus it needs to skip the backtracking completely. We enter ParentheticalAssertionEnd.bt only when we once complete the assertion, and in this case, any change in the ParentheticalAssertion have no effect since it does not consume any characters, so the subsequent patterns will not see any state change. Thus, we just immediately propagate the failure to the ParentheticalAssertionBegin.bt. Test: JSTests/stress/regexp-jit-fixedcount-multialt-assertion-end-fallthrough.js * JSTests/stress/regexp-jit-fixedcount-multialt-assertion-end-fallthrough.js: Added. (shouldBe): (i.shouldBe): (i.shouldBe.X.Y.c): (i.shouldBe.d.X.Y.c): * Source/JavaScriptCore/yarr/YarrJIT.cpp: Canonical link: https://commits.webkit.org/312767@main

…ype[@@iterator] https://bugs.webkit.org/show_bug.cgi?id=295660 Reviewed by Yusuke Suzuki. Default derived constructors should not observably access `Array.prototype[@@iterator]` [1], but JSC currently does due to rest/spread-based argument forwarding. This change avoids emitting a `spread` instruction when a `FunctionCallValueNode` representing `super(...args)` originates from a default derived constructor. To implement this, a flag `m_isBuiltinDefaultClassConstructor` is added to `UnlinkedCodeBlock`, and propagated to `BytecodeGenerator`, where it is exposed via `BytecodeGenerator::isBuiltinDefaultClassConstructor()`. sizeof(UnlinkedCodeBlock) is unchanged at 264 bytes so safe. [1]: https://tc39.es/proposal-class-brand-check/#sec-runtime-semantics-classdefinitionevaluation (Last accessed at 2026/4/27) The following shows the bytecode generated for the default derived constructor before and after this change. Before: bb#1 Predecessors: [ ] [ 0] enter [ 1] mov dst:loc5, src:callee [ 4] mov dst:loc6, src:this [ 7] mov dst:this, src:<JSValue()>(const0) [ 10] mov dst:loc7, src:<JSValue()>(const0) [ 13] create_rest dst:loc7, numParametersToSkip:0 [ 16] get_prototype_of dst:loc8, value:callee, valueProfile:1 [ 20] mov dst:loc11, src:loc7 [ 23] spread dst:loc11, argument:loc11 [ 26] mov dst:loc12, src:loc6 [ 29] super_construct_varargs dst:loc8, callee:loc8, thisValue:loc12, arguments:loc11, firstFree:loc13, firstVarArg:0, valueProfile:2 [ 38] is_empty dst:loc13, operand:this [ 41] jtrue condition:loc13, targetLabel:6(->47) Successors: [ oven-sh#3 oven-sh#2 ] After: bb#1 Predecessors: [ ] [ 0] enter [ 1] mov dst:loc5, src:callee [ 4] mov dst:loc6, src:this [ 7] mov dst:this, src:<JSValue()>(const0) [ 10] mov dst:loc7, src:<JSValue()>(const0) [ 13] create_rest dst:loc7, numParametersToSkip:0 [ 16] get_prototype_of dst:loc8, value:callee, valueProfile:1 [ 20] mov dst:loc11, src:loc7 [ 23] mov dst:loc12, src:loc6 [ 26] super_construct_varargs dst:loc8, callee:loc8, thisValue:loc12, arguments:loc11, firstFree:loc13, firstVarArg:0, valueProfile:2 [ 35] is_empty dst:loc13, operand:this [ 38] jtrue condition:loc13, targetLabel:6(->44) Successors: [ oven-sh#3 oven-sh#2 ] Test: JSTests/stress/default-derived-constructor-should-not-observe-array-iterator.js * JSTests/stress/default-derived-constructor-should-not-observe-array-iterator.js: Added. (try.): (try.B): (try.Array.prototype.Symbol.iterator): (catch): * Source/JavaScriptCore/bytecode/ExecutableInfo.h: (JSC::ExecutableInfo::ExecutableInfo): (JSC::ExecutableInfo::isBuiltinDefaultClassConstructor const): * Source/JavaScriptCore/bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): * Source/JavaScriptCore/bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedCodeBlock::isBuiltinDefaultClassConstructor const): * Source/JavaScriptCore/bytecode/UnlinkedFunctionExecutable.cpp: (JSC::generateUnlinkedFunctionCodeBlock): * Source/JavaScriptCore/bytecode/UnlinkedFunctionExecutable.h: * Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::emitConstructImpl): (JSC::BytecodeGenerator::emitConstruct): (JSC::BytecodeGenerator::emitSuperConstruct): * Source/JavaScriptCore/bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::isBuiltinDefaultClassConstructor const): * Source/JavaScriptCore/bytecompiler/NodesCodegen.cpp: (JSC::FunctionCallValueNode::emitBytecode): * Source/JavaScriptCore/runtime/CachedTypes.cpp: (JSC::CachedCodeBlock::isBuiltinDefaultClassConstructor const): (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): (JSC::CachedCodeBlock<CodeBlockType>::encode): Canonical link: https://commits.webkit.org/313130@main

…orks in Chrome https://bugs.webkit.org/show_bug.cgi?id=317742 rdar://180411019 Reviewed by Eric Carlson. Per spec, the `stalled`, `progress`, `suspend` events are controlled by the resource fetch algorithm (oven-sh#1) when the mode is `remote`. The Media Source Extension override the resource fetch algorithm and set the mode as `local` (oven-sh#2) in the resource fetch algorithm. As such those media events can't be fired with MSE. MediaSource spec however do mention that is is possible for an implementation to fire those events (oven-sh#3) in a 10 years old note stating: "An attached MediaSource does not use the remote mode steps in the resource fetch algorithm, so the media element will not fire "suspend" events. Though future versions of this specification will likely remove "progress" and "stalled" events from a media element with an attached MediaSource, user agents conforming to this version of the specification may still fire these two events as these [HTML] references changed after implementations of this specification stabilized." Some media-source web-platform-tests do test that no stalled or progress event are fired (which both Firefox and Chrome pass indicating that they do not fire the `progress` event either). A bug in the MediaPlayerPrivateRemote made it always fire the `progress` event at regular interval as it never checked the MediaPlayerPrivate::supportsProgressMonitoring and so Safari used to fire this event at regular interval when using MSE. When MediaContainment was enabled, supportsProgressMonitoring override became functional again and MediaPlayerPrivateMediaSourceAVFObjC::supportsProgressMonitoring returned false. Unifi.ui.com web player listen to the `progress` event to determine when to call `play()`, as no progress event is fired with MSE, play() wasn't called and so playback never started and only the first video frame was shown. We add a quirk for ui.com that forces the `progress`, `suspend`, `stalled` event to be fired. Note that `stalled` is fired often in this mode as it is fired if nothing has been downloaded for 3s. With MSE it is not uncommon to have the JS player only enqueue new content every 10s or so and media is progressing properly. 1)https://html.spec.whatwg.org/multipage/media.html#concept-media-load-resource 2)https://www.w3.org/TR/media-source-2/#mediasource-attach Manually tested. * Source/WebCore/html/HTMLMediaElement.cpp: (WebCore::HTMLMediaElement::loadResource): * Source/WebCore/page/Quirks.cpp: * Source/WebCore/page/Quirks.h: * Source/WebCore/platform/graphics/MediaPlayer.h: * Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.h: * Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm: (WebCore::MediaPlayerPrivateMediaSourceAVFObjC::supportsProgressMonitoring const): * Source/WebKit/Shared/WebCoreArgumentCodersMedia.serialization.in: Canonical link: https://commits.webkit.org/315774@main

…ScrollbarDoesNotAdaptToDarkMode is flaky failure https://bugs.webkit.org/show_bug.cgi?id=313768 <rdar://problem/175961655> Reviewed by Abrar Rahman Protyasha. Restore pre-312300@main behavior, by only applying the page's dark mode appearance to full-frame PDF scrollbars, not embedded ones. Before 312300@main For full-frame PDFs, the scrollbar appearance follows the system dark mode. For embedded PDFs, it does not - the scrollbar always uses the default appearance. Codeflow before 312300@main: return useDarkAppearance() || scrollbarOverlayStyle() == ScrollbarOverlayStyle::Light; (and with no useDarkAppearance() override on PDFPluginBase -where base class returns false) Full-frame PDF, light mode: 1. useDarkAppearance() -> no override, base class -> false 2. scrollbarOverlayStyle() -> Default (updateScrollbarOverlayStyle() set it to Default since page->useDarkAppearance() was false) 3. Default == Light -> false Result: false Full-frame PDF, dark mode: 1. useDarkAppearance() -> no override, base class -> false 2. scrollbarOverlayStyle() -> Light (updateScrollbarOverlayStyle() set it to Light since page->useDarkAppearance() was true) 3. Light == Light -> true Result: true Embedded PDF, light mode: 1. useDarkAppearance() -> no override, base class -> false 2. scrollbarOverlayStyle() -> Default (updateScrollbarOverlayStyle() at UnifiedPDFPlugin.mm bails out with if (!isFullMainFramePlugin()) return - never sets overlay style) 3. Default == Light -> false Result: false Embedded PDF, dark mode: 1. useDarkAppearance() -> no override, base class -> false 2. scrollbarOverlayStyle() -> Default (same reason as above) 3. Default == Light -> false Result: false Codeflow after this fix: Full-frame PDF, light mode: 1. useDarkAppearance() -> PDFPluginBase override -> page->useDarkAppearance() -> false 2. Falls through to check oven-sh#2 3. scrollbarOverlayStyle() -> Default (updateScrollbarOverlayStyle() set it to Default since page->useDarkAppearance() was false) 4. Default == Light -> false Result: false Full-frame PDF, dark mode: 1. useDarkAppearance() -> PDFPluginBase override -> page->useDarkAppearance() -> true Result: true Embedded PDF, light mode: 1. useDarkAppearance() -> PDFPluginBase override -> base class ScrollableArea::useDarkAppearance() -> false 2. Falls through to check oven-sh#2 3. scrollbarOverlayStyle() -> Default (updateScrollbarOverlayStyle() bails out with if (!isFullMainFramePlugin()) return -- never sets overlay style) 4. Default == Light -> false Result: false Embedded PDF, dark mode: 1. useDarkAppearance() -> PDFPluginBase override -> base class ScrollableArea::useDarkAppearance() -> false 2. Falls through to check oven-sh#2 3. scrollbarOverlayStyle() -> Default (same reason as above) 4. Default == Light -> false Result: false All four cases match the behavior before 312300@main. The only difference is how full-frame dark mode works: before, it went through the overlay style path (scrollbarOverlayStyle was set to Light); now it goes through useDarkAppearance(). * Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.mm: (WebKit::PDFPluginBase::useDarkAppearance const): * Tools/TestWebKitAPI/Tests/WebKit/WKWebView/UnifiedPDFTests.mm: (TestWebKitAPI::UNIFIED_PDF_TEST): Canonical link: https://commits.webkit.org/312409@main

…trying to navigate past a cross-origin iframe https://bugs.webkit.org/show_bug.cgi?id=315356 rdar://177714038 Reviewed by Dominic Mazzoni. This bug occurred because the root scroll area associated with an remote iframe had an AXProperty::RemoteParent (a WKAccessibilityWebPageObject) that itself never had its m_parent set, breaking the accessibility tree and thus preventing VoiceOver from navigating effectively. This was possible due to this sequence: 1. Pre-warmed iframe process is spawned (Safari prewarms some web content processes). 2. platformInitializeAccessibility runs in this iframe process, calling createMockAccessibilityElement() (this creates a WKAccessibilityWebPageObject). Note that its m_parent is nil at this point. 3. An accessibility query reaches the iframe process, triggering AXIsolatedTree::create. The iframe root scrollarea caches an AXProperty::RemoteParent with a pointer to the WKAccessibilityWebPageObject from step 2 (whose m_parent is still nil). 4. The parent web content process creates an AXRemoteFrame representing the iframe web content process. It sends bindRemoteAccessibilityFrames(parentPid, parentToken) through the UI process. 5. Iframe's WebPage::bindRemoteAccessibilityFrames runs as result, and calls registerRemoteFrameAccessibilityTokens. Prior to this commit, this unconditionally replaced m_mockAccessibilityElement (the WKAccessibilityWebPageObject) with a brand new instance, and sets m_parent for the new instance. 6. The iframe's root scroll area still has the old WKAccessibilityWebPageObject cached in its AXProperty::RemoteFrame from step oven-sh#2, with a nil m_parent. This bug is intermittent, critically depending on whether there was a prewarmed process available for the iframe web content. If there was not a prewarmed process available, AXProperty::RemoteParent is set up from the start with the WKAccessibilityWebPageObject that used to be unconditionally created in step 5, and the bug did not manifest. This commit fixes the issue by changing registerRemoteFrameAccessibilityTokens to only create a new m_mockAccessibilityElement if one doesn't already exist, preventing the iframe scroll area from being associated with a stale one that has no parent. Because the bug depends on prewarming behavior, the added layout test passes with and without this commit. I couldn't find a good way to emulate that in our testing environment. Fix manually confirmed in Safari. * LayoutTests/http/tests/site-isolation/accessibility/client/walk-up-from-iframe-content-expected.txt: Added. * LayoutTests/http/tests/site-isolation/accessibility/client/walk-up-from-iframe-content.html: Added. * Source/WebKit/WebProcess/WebPage/mac/WebPageMac.mm: (WebKit::WebPage::registerRemoteFrameAccessibilityTokens): Canonical link: https://commits.webkit.org/313754@main

https://bugs.webkit.org/show_bug.cgi?id=316798 Reviewed by BJ Burg. To improve traceability, this commit adds RELEASE_LOG statements covering the following areas of Source/WebDriver: - Browser startup and lifetime (for glib ports) - HTTP request and response - Driver->Browser Automation.json commands and replies. The added log statements cover mainly data like the request path, body size, response status, and duration. The actual body with payload like field values or JS code to be executed is omitted. For deeper inspection, the existing LOG() statements that inspect the actual payload are kept. We opted for RELEASE_LOG instead of LOG due to the WebDriver-related channels being low-volume in comparison to hotter ones internal to the browser. On top of that, it should be easier for reporters to provide release logs, helping get more useful bug reports. Example output: Started WebSocket BiDi server with host local and port 60782 Started HTTP server with host local and port 60781 HTTP request POST /session (body=303 bytes) Spawning local browser: /sdk/webkit/WebKitBuild/WPE/Release/bin/MiniBrowser with 2 argument(s) Connecting to RemoteInspector at 127.0.0.1:54821 Connected to RemoteInspector at 127.0.0.1:54821 after 1 attempt(s) SEND inspector oven-sh#1: Automation.createBrowsingContext (52 bytes) RECV inspector oven-sh#1: ok HTTP response 200 in 196ms HTTP request POST /session/fbc9c527-945d-4030-852e-50c5f1852557/url (body=43 bytes) SEND inspector oven-sh#2: Automation.resolveBrowsingContext (149 bytes) RECV inspector oven-sh#2: ok SEND inspector oven-sh#3: Automation.waitForNavigationToComplete (207 bytes) RECV inspector oven-sh#3: ok SEND inspector oven-sh#4: Automation.isShowingJavaScriptDialog (135 bytes) RECV inspector oven-sh#4: ok SEND inspector oven-sh#5: Automation.navigateBrowsingContext (212 bytes) RECV inspector oven-sh#5: ok HTTP response 200 in 124ms * Source/WebDriver/SessionHost.cpp: (WebDriver::SessionHost::inspectorDisconnected): (WebDriver::SessionHost::sendCommandToBackend): (WebDriver::SessionHost::dispatchMessage): * Source/WebDriver/WebDriverService.cpp: (WebDriver::printUsageStatement): (WebDriver::WebDriverService::run): (WebDriver::WebDriverService::handleRequest): * Source/WebDriver/glib/SessionHostGlib.cpp: (WebDriver::SessionHost::launchBrowser): (WebDriver::SessionHost::connectToBrowser): (WebDriver::SessionHost::connectionDidClose): (WebDriver::SessionHost::setTargetList): Canonical link: https://commits.webkit.org/316784@main

https://bugs.webkit.org/show_bug.cgi?id=319888 Unreviewed Skia update. % git log --pretty='%h %s' a6d4d199301da96b1d0c85968446d27222597be0..1717654ff51b534411f80c19c356f4aabb8d3721 1717654ff5 Migrate SKGPU_LOG calls to SKIA_LOG fcfe5975c9 Use exclusive mutex in SkFontMgr_android_ndk.cpp e7bff78bf5 [graphite] BufferSubAllocator respects failed mapping on reset 9cddcf3d21 Roll vulkan-deps from a8f28255baa4 to 000daaa61385 (1 revision) 5493e4c144 Avoid underflow on division in loops aaa004023a Update MSVC toolchain to 19.51.36244 and win_clang to 23.0 df142ba637 Manual roll Dawn from 485454223457 to ce586f1e2a62 (8 revisions) 3f20d9676d Roll ANGLE from ac8b6d7128c3 to 9566f50cb827 (9 revisions) 5a3e419299 Roll Skia Infra from aa960afe4aea to 5c22c771f011 (9 revisions) 1ff238ca6e Roll SwiftShader from 9898204d91d6 to bea72feae3cf (4 revisions) 52c2b02385 Roll Dawn from e99fddbdba43 to 485454223457 (5 revisions) a38708fb79 Roll vulkan-deps from 4029144db7a0 to a8f28255baa4 (5 revisions) 32acea7912 Roll recipe dependencies (trivial). 413fad7a0d Add SkLog implementation to SkSLMinify 56c41deecf Roll recipe dependencies (trivial). f1b8ba877c Restrict deserial types further in SkGlyph and SkCustomTypeface dae9ee6987 [bzl] Fix viewer build after Dawn roll bb889fb115 Reland "Replace fatal logging with SK_ABORT macro" 92f9b68b3a Manual roll Dawn from 1d7fa20a24b3 to e99fddbdba43 (10 revisions) 99de9d58dd [Fonts] Add non-PNG CBDT bitmap support to Fontations backend 9da67e212e Remove serialization of drawables from SkCustomTypeface d218592d34 Roll vulkan-deps from a4c1d6546496 to 4029144db7a0 (2 revisions) 57fd361c91 Revert "Replace fatal logging with SK_ABORT macro" 5890b2d65e Manual roll Dawn from e0a2faceeb2a to 1d7fa20a24b3 (10 revisions) f71b8b88a7 Roll ANGLE from a793c75398c7 to ac8b6d7128c3 (13 revisions) 98efa23b05 Roll Skia Infra from 07d34df64e49 to aa960afe4aea (13 revisions) 326cbc3a48 Roll SwiftShader from f9d5d49a3c59 to 9898204d91d6 (1 revision) f8615e838a Roll Dawn from 092efa32cb27 to e0a2faceeb2a (3 revisions) fa944af10f Roll recipe dependencies (trivial). f9db774856 Roll vulkan-deps from ac2608cabd3a to a4c1d6546496 (3 revisions) 5d8b32fae3 Roll recipe dependencies (trivial). a0ce5ee64f Roll recipe dependencies (trivial). e6c23e38d3 [ganesh] Use submitted proc to confirm async reads were issued f704065e96 Add prerequisites for OOPR-specific variant of Android's libskia_renderengine 4453a8598b Replace fatal logging with SK_ABORT macro 1968ca2738 [graphite] enable pilot draws for depth only c8a4fe5e60 Roll recipe dependencies (trivial). a692cbf389 Update Android OWNERS 2e4a568f6f [graphite] Ref count large gradient shaders in FloatStorageManager 5ecba665f5 [graphite] Drop excessively large gradient draws 27a819894f [bzl] Update Dawn files list 69c8afcf9e Manual roll Dawn from 3389b731386e to 092efa32cb27 (5 revisions) d526effe4b Roll vulkan-deps from 1b33de2b81e5 to ac2608cabd3a (1 revision) f1f8aabc45 Roll ANGLE from 3373eb28a246 to a793c75398c7 (5 revisions) c30f3b0f29 Roll Skia Infra from 794dba57f2c1 to 07d34df64e49 (5 revisions) 0442274cc6 Roll Dawn from 9aa45f938d4b to 3389b731386e (16 revisions) bfab35b363 Roll vulkan-deps from 26c4192d920d to 1b33de2b81e5 (1 revision) f4f294bdf9 Roll recipe dependencies (trivial). 9d1adb5f24 Roll ANGLE from 0aa38cb7368f to 3373eb28a246 (1 revision) 4dd78179e6 Roll Skia Infra from 78a5d76ed76a to 794dba57f2c1 (14 revisions) 665a65f28d Roll shaders-base from 33357ebae78c to 9f862803ee5b 789112b20e Roll skottie-base from 4b069fbc5e1a to 867c02555f37 e5420512ac Roll Dawn from 2389260fad26 to 9aa45f938d4b (23 revisions) 1f26101197 Manual roll ANGLE from 9ce3268f4c4b to 0aa38cb7368f (10 revisions) bbe9ccc2bd Roll vulkan-deps from e7a561a5f0b7 to 26c4192d920d (1 revision) 6fdb013d19 [ganesh] Fix direct mask filtering when fSupportBilerpFromGlyphAtlas is true 1220fd63f1 Manual roll Dawn from 910f580897ff to 2389260fad26 (10 revisions) 7a0df4c461 Add DEPS to use shared agents configs 54388cb53d [pathbuilder] Bump inline points/verbs/conics storage size 5e29790e70 Roll recipe dependencies (trivial). dae8778ca4 CanvasKit: Make Fast_SrcRectConstraint the default for DrawImage aae9570518 Roll vulkan-deps from 3f8b7a9b4901 to e7a561a5f0b7 (3 revisions) 004c6272f7 Roll ANGLE from 6a1ec69a8c59 to 9ce3268f4c4b (7 revisions) 58ec79cb7b Roll Skia Infra from c174a0d57010 to 78a5d76ed76a (78 revisions) 544395a5d9 [ganesh] Use & when testing for input attachment self-dep 0e23ccd468 Roll vulkan-deps from 41728e9eef28 to 3f8b7a9b4901 (44 revisions) f7f5e8a95a Remove MSVC+Dawn from CQ bd3d88bbbc Clamp displacement values before offsetting sampling coordinates 125526e0d3 Move generated parts of Android.bp to Android.gen.bp 356185490a Disable fMSAAResolvesAutomatically for Nvidia 7eed8eaafb [graphite] Further enforce time point deltas in timed test 748a86f4f8 Roll skcms from a7a3b15f0635 to 6010f3583977 (1 revision) a353502f42 Manual roll ANGLE from e51bf24dffcc to 6a1ec69a8c59 (5 revisions) 9309dfcfac [rust icc] Harden ICC CLUT grid validation 2ff2095097 Manual roll Dawn from c8ce3ce7a39f to 910f580897ff (8 revisions) f71b040b55 Manual roll Dawn from 3a8f53cbdac5 to c8ce3ce7a39f (11 revisions) c76f71cd4a Manual roll ANGLE from 799ce5794481 to e51bf24dffcc (7 revisions) 1ee3563555 [graphite] ignore crbug_513836996 on protected contexts 898340583f Fix internal build 7f0b622d95 Fix Dawn Bazel build a5be47106a Roll recipe dependencies (trivial). defc3a5a92 Report and handle failure for inlineUpload(...) calls 9938acab39 Revert "[skia] Replace sk_malloc_usable_size with preemptive sk_malloc_good_size" 3a46000222 [ganesh] Add GrUniquelyKeyedProxyRegistry to simplify unique key management 494789feb7 [skia] Replace sk_malloc_usable_size with preemptive sk_malloc_good_size 85b76633d5 [graphite] Add missing nullptr check assembleFunctionCall 9e0f42d0ad [graphite] Fix test cases ported from clipping 43f969a9bc [ganesh] Require glyph padding to use linear sampling d46b9b7ef1 Manual roll Dawn from a4511bd8cfb9 to 3a8f53cbdac5 (49 revisions) 17b4bab488 [graphite] correctly advance index in drawEdgeAAImageSet 7ec8fa468a Manual roll ANGLE from 6f2c0162c12f to 799ce5794481 (9 revisions) 5f4f454b96 Fix for integer wraparound in sksl 9a772306b2 Revert "Reland oven-sh#3 "MiraclePtr: Add raw_ptr definitions"" d45969a575 Reland oven-sh#3 "MiraclePtr: Add raw_ptr definitions" b9b87505e3 Roll recipe dependencies (trivial). 19ad9707e5 Roll recipe dependencies (trivial). 15ae3e3e7a Manual roll ANGLE from aa0d838ac95b to 6f2c0162c12f (6 revisions) ba800574a9 Replace use of SkTDArray in PathWriter 7c9ffcb347 Avoid overflow and timeout in SkPathWriter::assemble 9283514e1a Roll recipe dependencies (trivial). 3431f6ad0e Fix Dawn+Clang+GN build c7d5748715 Add performance enhancements for SkRegion::op 8b96fad679 Manual roll ANGLE from 82be364307a4 to aa0d838ac95b (6 revisions) abf56b5562 deps: Update partition_alloc 3471ebf5af Null out VkShaderModule handles when destroying them. d93793dfc1 [graphite] ensure drawlist resources are cleared on failure 83407f4702 Add deprecated notice to SkTDArray 24ff2fc3a3 Simplify linked list removal in SkOpCoincidence 210555e2e6 infra: Disable partition_alloc on NoDEPS bots f1b406860c Roll jsfiddle-base from 508fbad5adbd to e97ab14ddb65 935afe5232 Roll debugger-app-base from 518c0106b064 to c74d26054770 967ddb1aa5 Roll recipe dependencies (trivial). 33b70be027 Fix pathops bug with linked lists in SkOpCoincidence 37ec3f5610 Roll recipe dependencies (trivial). 5342cac599 Roll recipe dependencies (trivial). cebf49d034 Roll recipe dependencies (trivial). 8ba11bcc74 Roll recipe dependencies (trivial). 8393300c28 Roll recipe dependencies (trivial). ea61091740 [pdf] Filter out empty contours in EmitPath 27aaf3d192 Remove dawn from CQ 2711a2eb95 Manual roll ANGLE from 2313796554ff to 82be364307a4 (13 revisions) 871578a722 Updating gardening docs b62fcabf5e Roll recipe dependencies (trivial). 5efed56680 Manually Roll Dawn from 294c85cfb313 to a4511bd8cfb9 (97 revisions) 4de5274363 Roll recipe dependencies (trivial). c9f57f09f0 Roll ANGLE from bea70939cf37 to 2313796554ff (13 revisions) 0c7172dc3b Roll Skia Infra from 7a0c66624686 to c174a0d57010 (12 revisions) a6b6608751 [graphite] Add Sparse Strips Clipping d1b4412c2d [pdf] Remove zombie state machine 325aa92729 Add spanned version of SkRegion APIs 0aa8826c12 Update SkRegion::setRects to use divide-and-conquer 55ed8c4db1 Guard against racing initialization of dng_sdk 0ad3b31652 Roll recipe dependencies (trivial). 0f4027ff43 [graphite] Cache single-buffer BindGroups on DawnBuffer 077b40f0df [graphite] Pull tile test cases into a shared header 2528746b4c Fix SIMD on x86 2d9bf58824 Extract Dawn's list of files to dawn_files.bzl 0d5f4adeae Revert "Reland oven-sh#2 "MiraclePtr: Add raw_ptr definitions""" c7fe8e6b02 Roll vulkan-deps from df04fe18c28e to 41728e9eef28 (2 revisions) 6afe3c43a8 Roll ANGLE from 52d177bd7e42 to bea70939cf37 (12 revisions) 24645ad9f9 Roll Skia Infra from 472ab5b3c3b9 to 7a0c66624686 (17 revisions) 0c2a8a779c Roll debugger-app-base from 18d4e53a226a to 518c0106b064 202cb5a63a Roll jsfiddle-base from 5bae7afba87d to 508fbad5adbd 3b718ddc8a Roll vulkan-deps from 1b6c53ba0f23 to df04fe18c28e (6 revisions) e2444d1965 [graphite] Track precompile paint key opacity 081803650b Add helper to do bulk extraction/analysis of SkRP stages 1403247dd6 [graphite] Move depthOnly off template parameter 76a371627c [ganesh] Fallback to external GL textures if import fails eb4f33fe2b [ganesh] Avoid overflow when combining AtlasTextOps 31220f5ef0 Reland oven-sh#2 "MiraclePtr: Add raw_ptr definitions"" 3c7ff4890a Fix compiler warnings from latest Clang b3b9a46f6e Fix Bazel Viewer build 27f7bba226 [Fonts] Add CBDT alpha bitmap test font generation 8611fc3c56 Roll vulkan-deps from 1380a5152f43 to 1b6c53ba0f23 (8 revisions) 5e7066dbaa Roll ANGLE from 4a6d53434044 to 52d177bd7e42 (10 revisions) 56ca5896c0 Roll Skia Infra from 4bf523d4b47c to 472ab5b3c3b9 (15 revisions) 6385958d2f Roll recipe dependencies (trivial). da8a27fbdc [graphite] Cache single-texture BindGroups on DawnTexture d4e23f36a0 Fix overflow in FT bounding boxes 2840dab3ee [graphite] Add generalized createBindGroup(...) to DawnResourceProvider 9d738e0f97 Force SkPictureBackedGlyphDrawable::MakeFromBuffer to never use sksl fceaf4cd95 Use more standard AVX512 and AVX2 flags Canonical link: https://commits.webkit.org/317645@main

…in inlined closure-call and varargs frames https://bugs.webkit.org/show_bug.cgi?id=315674 rdar://176555185 Reviewed by Yijia Huang. 208291@main added an InlineCallFrame check that demotes candidate allocations whose origin is a closure-call or varargs inline frame and whose escape site is in a different frame. The check is necessary because such an allocation, if sunk to the escape site, would have its Materialize* node emitted where the frame's closure-call callee slot or varargs argc slot has been reused by intervening code, causing subsequent stack walks to potentially dereference garbage. However, that fix was incomplete in two ways. First, the InlineCallFrame check ran before the closure rule's worklist ("rule #2"), so it only inspected the initial candidates. Rule #2 then promoted additional dependencies to satisfy the closure invariant (a sink candidate stored into a local allocation, that allocation must also be a sink candidate"), and any such promoted allocation that would have failed the InlineCallFrame check slipped through. Second, even for candidates the check correctly removed, rule #2's worklist re-promoted them in order to maintain its invariant, undoing the InlineCallFrame check. Fix this with two complementary changes: 1. Run the closure rule (rule #2) before the InlineCallFrame check, so the InlineCallFrame check sees both seeded and rule-#2-promoted candidates and is the final determination of which stay sunk. 2. Add an additional closure rule (which was already documented as a potential rule #1): remove candidates that depend on the candidates that were demoted (due to the InlineCallFrame mismatch). Like the original fix, this happens rarely. Add an ASSERT in the materialization-placement loop to verify that no allocation reaching it would fail the InlineCallFrame check. This catches the bug pattern in debug builds and guards against future regressions. Test: JSTests/stress/object-allocation-sinking-phase-must-only-move-allocations-if-stack-trace-is-still-valid-closure-rules.js * JSTests/stress/object-allocation-sinking-phase-must-only-move-allocations-if-stack-trace-is-still-valid-closure-rule-promoted-parent.js: Added. (makeInner.return.inner): (makeInner): (clobber): (sink): (opt): * JSTests/stress/object-allocation-sinking-phase-must-only-move-allocations-if-stack-trace-is-still-valid-closure-rules.js: Added. (makeInner.return.inner): (makeInner): (clobber): (sink): (opt): * Source/JavaScriptCore/dfg/DFGObjectAllocationSinkingPhase.cpp: Originally-landed-as: 305413.973@safari-7624.5-branch (a4e027e). rdar://185368183 Canonical link: https://commits.webkit.org/320362@main

Move stdint.h import out of __cplusplus guard in ForkExtras.h

208250a

DAlperin mentioned this pull request Sep 18, 2021

All deps now build on linux oven-sh/bun#27

Merged

Jarred-Sumner merged commit 2312676 into oven-sh:main Sep 18, 2021

claude Bot mentioned this pull request Jun 12, 2026

Shared-memory threads for JavaScriptCore (experimental, not working yet) #249

Open

claude Bot mentioned this pull request Jul 26, 2026

CodeBlock: renew old-age TTL for LLInt/Baseline blocks that are still executing #333

Merged

Jarred-Sumner mentioned this pull request Aug 2, 2026

Yarr: JIT lookbehinds, first-code-point alternation dispatch, Boyer-Moore and /u·/v spec alignment, RegExp correctness fixes #299

Merged

claude Bot mentioned this pull request Aug 18, 2026

[JSC] Yarr: regenerate the non-unicode /i canonicalization table with the Unicode 16 and 17 case pairs #456

Open

This was referenced Sep 4, 2026

[JSC] CodeBlock aging: refresh the counter snapshot on every look; drop the per-allocation byte counter #560

Merged

[JSC] CodeBlock aging: refresh the execution-counter snapshot on every look, not only past the TTL #566

Merged

Navigation Menu

Uh oh!

Move stdint.h import out of __cplusplus guard in ForkExtras.h - #2

Move stdint.h import out of __cplusplus guard in ForkExtras.h#2
Jarred-Sumner merged 1 commit into
oven-sh:mainfrom
DAlperin:main

DAlperin commented Sep 18, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

DAlperin commented Sep 18, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants