maybe upgrade by Jarred-Sumner · Pull Request #1 · oven-sh/WebKit

Jarred-Sumner · 2021-09-06T00:04:22Z

No description provided.

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

… be called more than once under WebCore::MediaControlsContextMenuProvider::contextMenuItemSelected https://bugs.webkit.org/show_bug.cgi?id=228725 <rdar://problem/81437221> Reviewed by Eric Carlson. The contextmenu system used by (modern) media controls are a bit wonky in that it has to support both macOS and iOS, which use wildly different mechanisms. The former has distinct methods for handling when a contextmenu item is selected vs when the menu is dismissed (at least as of r280374). The latter has a single method that handles both. Additionally, the (modern) media controls JS expects the following from `showMediaControlsContextMenu`: 1. `showMediaControlsContextMenu` will only `return true` if the contextmenu will be shown 2. the callback provided to `showMediaControlsContextMenu` will always/only be invoked when the contextmenu is dismissed (regardless of whether an item is selected) 3. if an item is selected, the logic for that will be handled by the `MediaControlsHost` This patch primarily addresses #2, but also slightly adjusts the code to fix #1. It does #1 by moving the call that saves the callback further down. On iOS, #2 already works. On macOS, it does #2 by changing from `CompletionHandler` to `Function`, allowing it to be called more than once, with the understanding that the JS callback will not be invoked more than once. This way, macOS can match the behavior of iOS by eagerly invoking the JS callback when a contextmenu item is selected without waiting for the menu to actually dismiss, while still handling the contextmenu being dismissed without an item being selected (and also not having to worry about whether the `CompletionHandler` has already been invoked). * Modules/mediacontrols/MediaControlsHost.h: * Modules/mediacontrols/MediaControlsHost.cpp: (WebCore::MediaControlsContextMenuProvider::create): (WebCore::MediaControlsContextMenuProvider::MediaControlsContextMenuProvider): (WebCore::MediaControlsContextMenuProvider::didDismissContextMenu): (WebCore::MediaControlsContextMenuProvider::contextMenuCleared): (WebCore::MediaControlsHost::showMediaControlsContextMenu): Canonical link: https://commits.webkit.org/240278@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280676 268f45cc-cd09-0410-ab3c-d52691b4dbfc

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

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

…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=242295 Reviewed by Michael Catanzaro. We need to use adoptGRef when calling g_variant_get_data_as_bytes as the return is already ref'd. See: https://github.com/GNOME/glib/blob/2.72.3/glib/gvariant-core.c#L975 Fixes: ==3126== 330 (120 direct, 210 indirect) bytes in 3 blocks are definitely lost in loss record 3,105 of 3,199 ==3126== at 0x48447ED: malloc (vg_replace_malloc.c:381) ==3126== by 0xA87B2E8: g_malloc (gmem.c:106) ==3126== by 0xA892E44: g_slice_alloc (gslice.c:1072) ==3126== by 0xA84B005: g_bytes_new_with_free_func (gbytes.c:186) ==3126== by 0xA84B067: g_bytes_new_take (gbytes.c:128) ==3126== by 0xA8B934D: g_variant_ensure_serialised (gvariant-core.c:460) ==3126== by 0xA8B958E: g_variant_get_data_as_bytes (gvariant-core.c:961) ==3126== by 0x8765214: WebCore::KeyedEncoderGlib::finishEncoding() (KeyedEncoderGlib.cpp:139) ==3126== by 0x53CF40E: WebKit::writeToDisk(std::unique_ptr<WebCore::KeyedEncoder, std::default_delete<WebCore::KeyedEncoder> >&&, WTF::String&&) (PersistencyUtils.cpp:53) ==3126== by 0x545EF8C: operator() (DeviceIdHashSaltStorage.cpp:201) ==3126== by 0x545EF8C: WTF::Detail::CallableWrapper<WebKit::DeviceIdHashSaltStorage::storeHashSaltToDisk(WebKit::DeviceIdHashSaltStorage::HashSaltForOrigin const&)::{lambda()#1}, void>::call() (Function.h:53) ==3126== by 0x6E52DE9: operator() (Function.h:82) ==3126== by 0x6E52DE9: operator() (WorkQueueGeneric.cpp:70) ==3126== by 0x6E52DE9: WTF::Detail::CallableWrapper<WTF::WorkQueueBase::dispatch(WTF::Function<void ()>&&)::{lambda()#1}, void>::call() (Function.h:53) ==3126== by 0x6DF490F: operator() (Function.h:82) ==3126== by 0x6DF490F: WTF::RunLoop::performWork() (RunLoop.cpp:133) ==3126== by 0x6E55171: WTF::RunLoop::RunLoop()::{lambda(void*)#1}::_FUN(void*) (RunLoopGLib.cpp:80) ==3126== by 0x6E55D61: operator() (RunLoopGLib.cpp:53) ==3126== by 0x6E55D61: WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)#1}::_FUN(_GSource*, int (*)(void*), void*) (RunLoopGLib.cpp:56) ==3126== by 0xA8723AB: g_main_dispatch (gmain.c:3381) ==3126== by 0xA875839: g_main_context_dispatch (gmain.c:4099) ==3126== by 0xA8759A7: g_main_context_iterate (gmain.c:4175) ==3126== by 0xA875D41: g_main_loop_run (gmain.c:4373) ==3126== by 0x6E5613C: WTF::RunLoop::run() (RunLoopGLib.cpp:108) ==3126== by 0x6E52E14: operator() (WorkQueueGeneric.cpp:51) ==3126== by 0x6E52E14: WTF::Detail::CallableWrapper<WTF::WorkQueueBase::platformInitialize(char const*, WTF::WorkQueueBase::Type, WTF::Thread::QOS)::{lambda()#1}, void>::call() (Function.h:53) ==3126== by 0x6DF6FD7: operator() (Function.h:82) ==3126== by 0x6DF6FD7: WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) (Threading.cpp:236) ==3126== by 0x6E59A3F: WTF::wtfThreadEntryPoint(void*) (ThreadingPOSIX.cpp:242) ==3126== by 0xA9D6DC2: start_thread (pthread_create.c:442) ==3126== by 0xAA4FA0F: clone (clone.S:100) ==3126== * Source/WebCore/platform/glib/KeyedEncoderGlib.cpp: (WebCore::KeyedEncoderGlib::finishEncoding): Canonical link: https://commits.webkit.org/252100@main

…e leak https://bugs.webkit.org/show_bug.cgi?id=242576 Reviewed by Xabier Rodriguez-Calvar. Refactor ref counting for GstContext in GLVideoSinkGStreamer to prevent a resource leak. Fixes: ==196== 401 (296 direct, 105 indirect) bytes in 1 blocks are definitely lost in loss record 58,280 of 62,411 ==196== at 0x4845A83: calloc (vg_replace_malloc.c:1328) ==196== by 0x15F58780: g_malloc0 (gmem.c:136) ==196== by 0x161C8CBB: gst_structure_new_id_empty_with_size (gststructure.c:281) ==196== by 0x161C8CBB: gst_structure_new_id_empty (gststructure.c:312) ==196== by 0x161716CF: gst_context_new (gstcontext.c:178) ==196== by 0x1122BB85: requestGLContext(char const*) (GLVideoSinkGStreamer.cpp:154) ==196== by 0x1122BD12: setGLContext(_GstElement*, char const*) (GLVideoSinkGStreamer.cpp:173) ==196== by 0x1122BE39: webKitGLVideoSinkChangeState(_GstElement*, GstStateChange) (GLVideoSinkGStreamer.cpp:189) ==196== by 0x1617FA11: gst_element_change_state (gstelement.c:3083) ==196== by 0x16180154: gst_element_set_state_func (gstelement.c:3037) ==196== by 0x40651CE6: activate_sink (gstplaybin3.c:3805) ==196== by 0x40651CE6: activate_sink.constprop.0 (gstplaybin3.c:3780) ==196== by 0x40652B3E: activate_group (gstplaybin3.c:4539) ==196== by 0x40652B3E: setup_next_source (gstplaybin3.c:4801) ==196== by 0x406542A7: gst_play_bin3_change_state (gstplaybin3.c:5031) ==196== by 0x1617FA11: gst_element_change_state (gstelement.c:3083) ==196== by 0x1617FA5A: gst_element_change_state (gstelement.c:3122) ==196== by 0x16180154: gst_element_set_state_func (gstelement.c:3037) ==196== by 0x11257BC9: WebCore::MediaPlayerPrivateGStreamer::changePipelineState(GstState) (MediaPlayerPrivateGStreamer.cpp:924) ==196== by 0x11258D8B: WebCore::MediaPlayerPrivateGStreamer::commitLoad() (MediaPlayerPrivateGStreamer.cpp:1184) ==196== by 0x1125420B: WebCore::MediaPlayerPrivateGStreamer::load(WTF::String const&) (MediaPlayerPrivateGStreamer.cpp:354) ==196== by 0x112542F4: WebCore::MediaPlayerPrivateGStreamer::load(WebCore::MediaStreamPrivate&) (MediaPlayerPrivateGStreamer.cpp:370) ==196== by 0x148CF508: WebCore::MediaPlayer::loadWithNextMediaEngine(WebCore::MediaPlayerFactory const*) (MediaPlayer.cpp:646) ==196== by 0x148CED64: WebCore::MediaPlayer::load(WebCore::MediaStreamPrivate&) (MediaPlayer.cpp:549) ==196== by 0x13CF7047: WebCore::HTMLMediaElement::loadResource(WTF::URL const&, WebCore::ContentType&, WTF::String const&) (HTMLMediaElement.cpp:1599) ==196== by 0x13CF5D70: WebCore::HTMLMediaElement::selectMediaResource()::{lambda()#1}::operator()() const (HTMLMediaElement.cpp:1413) ==196== by 0x13D291BD: WTF::Detail::CallableWrapper<WebCore::HTMLMediaElement::selectMediaResource()::{lambda()#1}, void>::call() (Function.h:53) ==196== by 0xD99E63C: WTF::Function<void ()>::operator()() const (Function.h:82) ==196== by 0x131C31E7: WTF::CancellableTask::operator()() (CancellableTask.h:86) ==196== by 0x13D2D2DD: WebCore::ActiveDOMObject::queueCancellableTaskKeepingObjectAlive<WebCore::HTMLMediaElement>(WebCore::HTMLMediaElement&, WebCore::TaskSource, WTF::TaskCancellationGroup&, WTF::Function<void ()>&&)::{lambda()#1}::operator()() (ActiveDOMObject.h:119) ==196== by 0x13D5C88F: WTF::Detail::CallableWrapper<WebCore::ActiveDOMObject::queueCancellableTaskKeepingObjectAlive<WebCore::HTMLMediaElement>(WebCore::HTMLMediaElement&, WebCore::TaskSource, WTF::TaskCancellationGroup&, WTF::Function<void ()>&&)::{lambda()#1}, void>::call() (Function.h:53) ==196== by 0xD99E63C: WTF::Function<void ()>::operator()() const (Function.h:82) ==196== by 0x1399229B: WebCore::EventLoopFunctionDispatchTask::execute() (EventLoop.cpp:159) ==196== by 0x13987D3A: WebCore::EventLoop::run() (EventLoop.cpp:123) ==196== by 0x13ABF15D: WebCore::WindowEventLoop::didReachTimeToRun() (WindowEventLoop.cpp:121) ==196== by 0x13AD46FB: void std::__invoke_impl<void, void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&>(std::__invoke_memfun_deref, void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&) (invoke.h:74) ==196== by 0x13AD4666: std::__invoke_result<void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&>::type std::__invoke<void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&>(void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&) (invoke.h:96) ==196== by 0x13AD45DC: void std::_Bind<void (WebCore::WindowEventLoop::*(WebCore::WindowEventLoop*))()>::__call<void, , 0ul>(std::tuple<>&&, std::_Index_tuple<0ul>) (functional:420) ==196== by 0x13AD456E: void std::_Bind<void (WebCore::WindowEventLoop::*(WebCore::WindowEventLoop*))()>::operator()<, void>() (functional:503) ==196== by 0x13AD4537: WTF::Detail::CallableWrapper<std::_Bind<void (WebCore::WindowEventLoop::*(WebCore::WindowEventLoop*))()>, void>::call() (Function.h:53) ==196== by 0xD99E63C: WTF::Function<void ()>::operator()() const (Function.h:82) ==196== by 0xE23D137: WebCore::Timer::fired() (Timer.h:135) ==196== by 0x146E59EF: WebCore::ThreadTimers::sharedTimerFiredInternal() (ThreadTimers.cpp:127) ==196== by 0x146E52E4: WebCore::ThreadTimers::setSharedTimer(WebCore::SharedTimer*)::{lambda()#1}::operator()() const (ThreadTimers.cpp:67) ==196== by 0x146E8407: WTF::Detail::CallableWrapper<WebCore::ThreadTimers::setSharedTimer(WebCore::SharedTimer*)::{lambda()#1}, void>::call() (Function.h:53) ==196== by 0xD99E63C: WTF::Function<void ()>::operator()() const (Function.h:82) ==196== by 0x14698311: WebCore::MainThreadSharedTimer::fired() (MainThreadSharedTimer.cpp:83) ==196== by 0x146A2E9D: void std::__invoke_impl<void, void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&>(std::__invoke_memfun_deref, void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&) (invoke.h:74) ==196== by 0x146A2E16: std::__invoke_result<void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&>::type std::__invoke<void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&>(void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&) (invoke.h:96) ==196== by 0x146A2D8C: void std::_Bind<void (WebCore::MainThreadSharedTimer::*(WebCore::MainThreadSharedTimer*))()>::__call<void, , 0ul>(std::tuple<>&&, std::_Index_tuple<0ul>) (functional:420) ==196== by 0x146A2D1E: void std::_Bind<void (WebCore::MainThreadSharedTimer::*(WebCore::MainThreadSharedTimer*))()>::operator()<, void>() (functional:503) ==196== by 0x146A2CC7: WTF::Detail::CallableWrapper<std::_Bind<void (WebCore::MainThreadSharedTimer::*(WebCore::MainThreadSharedTimer*))()>, void>::call() (Function.h:53) ==196== by 0xD99E63C: WTF::Function<void ()>::operator()() const (Function.h:82) ==196== by 0x146A2CE7: WTF::RunLoop::Timer<WebCore::MainThreadSharedTimer>::fired() (RunLoop.h:188) ==196== by 0x110196A8: WTF::RunLoop::TimerBase::TimerBase(WTF::RunLoop&)::{lambda(void*)#1}::operator()(void*) const (RunLoopGLib.cpp:177) ==196== by 0x110196E8: WTF::RunLoop::TimerBase::TimerBase(WTF::RunLoop&)::{lambda(void*)#1}::_FUN(void*) (RunLoopGLib.cpp:181) ==196== by 0x11018BFA: WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)#1}::operator()(_GSource*, int (*)(void*), void*) const (RunLoopGLib.cpp:53) ==196== by 0x11018C48: WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)#1}::_FUN(_GSource*, int (*)(void*), void*) (RunLoopGLib.cpp:56) ==196== by 0x15F52293: g_main_dispatch (gmain.c:3381) ==196== by 0x15F52293: g_main_context_dispatch (gmain.c:4099) ==196== by 0x15F52637: g_main_context_iterate.constprop.0 (gmain.c:4175) ==196== by 0x15F52942: g_main_loop_run (gmain.c:4373) ==196== by 0x110192B3: WTF::RunLoop::run() (RunLoopGLib.cpp:108) ==196== by 0xEFB8674: WebKit::AuxiliaryProcessMainBase<WebKit::WebProcess, true>::run(int, char**) (AuxiliaryProcessMain.h:70) ==196== by 0xEFB5D26: int WebKit::AuxiliaryProcessMain<WebKit::WebProcessMainWPE>(int, char**) (AuxiliaryProcessMain.h:96) ==196== by 0xEFB227E: WebKit::WebProcessMain(int, char**) (WebProcessMainWPE.cpp:75) ==196== by 0x109908: main (WebProcessMain.cpp:31) ==196== ==196== 403 (88 direct, 315 indirect) bytes in 1 blocks are definitely lost in loss record 58,282 of 62,411 ==196== at 0x4840899: malloc (vg_replace_malloc.c:381) ==196== by 0x15F58728: g_malloc (gmem.c:106) ==196== by 0x15F710B4: g_slice_alloc (gslice.c:1072) ==196== by 0x16171683: gst_context_new (gstcontext.c:174) ==196== by 0x1122BC0A: requestGLContext(char const*) (GLVideoSinkGStreamer.cpp:160) ==196== by 0x1122BD12: setGLContext(_GstElement*, char const*) (GLVideoSinkGStreamer.cpp:173) ==196== by 0x1122BE5D: webKitGLVideoSinkChangeState(_GstElement*, GstStateChange) (GLVideoSinkGStreamer.cpp:191) ==196== by 0x1617FA11: gst_element_change_state (gstelement.c:3083) ==196== by 0x16180154: gst_element_set_state_func (gstelement.c:3037) ==196== by 0x40651CE6: activate_sink (gstplaybin3.c:3805) ==196== by 0x40651CE6: activate_sink.constprop.0 (gstplaybin3.c:3780) ==196== by 0x40652B3E: activate_group (gstplaybin3.c:4539) ==196== by 0x40652B3E: setup_next_source (gstplaybin3.c:4801) ==196== by 0x406542A7: gst_play_bin3_change_state (gstplaybin3.c:5031) ==196== by 0x1617FA11: gst_element_change_state (gstelement.c:3083) ==196== by 0x1617FA5A: gst_element_change_state (gstelement.c:3122) ==196== by 0x16180154: gst_element_set_state_func (gstelement.c:3037) ==196== by 0x11257BC9: WebCore::MediaPlayerPrivateGStreamer::changePipelineState(GstState) (MediaPlayerPrivateGStreamer.cpp:924) ==196== by 0x11258D8B: WebCore::MediaPlayerPrivateGStreamer::commitLoad() (MediaPlayerPrivateGStreamer.cpp:1184) ==196== by 0x1125420B: WebCore::MediaPlayerPrivateGStreamer::load(WTF::String const&) (MediaPlayerPrivateGStreamer.cpp:354) ==196== by 0x112542F4: WebCore::MediaPlayerPrivateGStreamer::load(WebCore::MediaStreamPrivate&) (MediaPlayerPrivateGStreamer.cpp:370) ==196== by 0x148CF508: WebCore::MediaPlayer::loadWithNextMediaEngine(WebCore::MediaPlayerFactory const*) (MediaPlayer.cpp:646) ==196== by 0x148CED64: WebCore::MediaPlayer::load(WebCore::MediaStreamPrivate&) (MediaPlayer.cpp:549) ==196== by 0x13CF7047: WebCore::HTMLMediaElement::loadResource(WTF::URL const&, WebCore::ContentType&, WTF::String const&) (HTMLMediaElement.cpp:1599) ==196== by 0x13CF5D70: WebCore::HTMLMediaElement::selectMediaResource()::{lambda()#1}::operator()() const (HTMLMediaElement.cpp:1413) ==196== by 0x13D291BD: WTF::Detail::CallableWrapper<WebCore::HTMLMediaElement::selectMediaResource()::{lambda()#1}, void>::call() (Function.h:53) ==196== by 0xD99E63C: WTF::Function<void ()>::operator()() const (Function.h:82) ==196== by 0x131C31E7: WTF::CancellableTask::operator()() (CancellableTask.h:86) ==196== by 0x13D2D2DD: WebCore::ActiveDOMObject::queueCancellableTaskKeepingObjectAlive<WebCore::HTMLMediaElement>(WebCore::HTMLMediaElement&, WebCore::TaskSource, WTF::TaskCancellationGroup&, WTF::Function<void ()>&&)::{lambda()#1}::operator()() (ActiveDOMObject.h:119) ==196== by 0x13D5C88F: WTF::Detail::CallableWrapper<WebCore::ActiveDOMObject::queueCancellableTaskKeepingObjectAlive<WebCore::HTMLMediaElement>(WebCore::HTMLMediaElement&, WebCore::TaskSource, WTF::TaskCancellationGroup&, WTF::Function<void ()>&&)::{lambda()#1}, void>::call() (Function.h:53) ==196== by 0xD99E63C: WTF::Function<void ()>::operator()() const (Function.h:82) ==196== by 0x1399229B: WebCore::EventLoopFunctionDispatchTask::execute() (EventLoop.cpp:159) ==196== by 0x13987D3A: WebCore::EventLoop::run() (EventLoop.cpp:123) ==196== by 0x13ABF15D: WebCore::WindowEventLoop::didReachTimeToRun() (WindowEventLoop.cpp:121) ==196== by 0x13AD46FB: void std::__invoke_impl<void, void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&>(std::__invoke_memfun_deref, void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&) (invoke.h:74) ==196== by 0x13AD4666: std::__invoke_result<void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&>::type std::__invoke<void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&>(void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&) (invoke.h:96) ==196== by 0x13AD45DC: void std::_Bind<void (WebCore::WindowEventLoop::*(WebCore::WindowEventLoop*))()>::__call<void, , 0ul>(std::tuple<>&&, std::_Index_tuple<0ul>) (functional:420) ==196== by 0x13AD456E: void std::_Bind<void (WebCore::WindowEventLoop::*(WebCore::WindowEventLoop*))()>::operator()<, void>() (functional:503) ==196== by 0x13AD4537: WTF::Detail::CallableWrapper<std::_Bind<void (WebCore::WindowEventLoop::*(WebCore::WindowEventLoop*))()>, void>::call() (Function.h:53) ==196== by 0xD99E63C: WTF::Function<void ()>::operator()() const (Function.h:82) ==196== by 0xE23D137: WebCore::Timer::fired() (Timer.h:135) ==196== by 0x146E59EF: WebCore::ThreadTimers::sharedTimerFiredInternal() (ThreadTimers.cpp:127) ==196== by 0x146E52E4: WebCore::ThreadTimers::setSharedTimer(WebCore::SharedTimer*)::{lambda()#1}::operator()() const (ThreadTimers.cpp:67) ==196== by 0x146E8407: WTF::Detail::CallableWrapper<WebCore::ThreadTimers::setSharedTimer(WebCore::SharedTimer*)::{lambda()#1}, void>::call() (Function.h:53) ==196== by 0xD99E63C: WTF::Function<void ()>::operator()() const (Function.h:82) ==196== by 0x14698311: WebCore::MainThreadSharedTimer::fired() (MainThreadSharedTimer.cpp:83) ==196== by 0x146A2E9D: void std::__invoke_impl<void, void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&>(std::__invoke_memfun_deref, void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&) (invoke.h:74) ==196== by 0x146A2E16: std::__invoke_result<void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&>::type std::__invoke<void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&>(void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&) (invoke.h:96) ==196== by 0x146A2D8C: void std::_Bind<void (WebCore::MainThreadSharedTimer::*(WebCore::MainThreadSharedTimer*))()>::__call<void, , 0ul>(std::tuple<>&&, std::_Index_tuple<0ul>) (functional:420) ==196== by 0x146A2D1E: void std::_Bind<void (WebCore::MainThreadSharedTimer::*(WebCore::MainThreadSharedTimer*))()>::operator()<, void>() (functional:503) ==196== by 0x146A2CC7: WTF::Detail::CallableWrapper<std::_Bind<void (WebCore::MainThreadSharedTimer::*(WebCore::MainThreadSharedTimer*))()>, void>::call() (Function.h:53) ==196== by 0xD99E63C: WTF::Function<void ()>::operator()() const (Function.h:82) ==196== by 0x146A2CE7: WTF::RunLoop::Timer<WebCore::MainThreadSharedTimer>::fired() (RunLoop.h:188) ==196== by 0x110196A8: WTF::RunLoop::TimerBase::TimerBase(WTF::RunLoop&)::{lambda(void*)#1}::operator()(void*) const (RunLoopGLib.cpp:177) ==196== by 0x110196E8: WTF::RunLoop::TimerBase::TimerBase(WTF::RunLoop&)::{lambda(void*)#1}::_FUN(void*) (RunLoopGLib.cpp:181) ==196== by 0x11018BFA: WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)#1}::operator()(_GSource*, int (*)(void*), void*) const (RunLoopGLib.cpp:53) ==196== by 0x11018C48: WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)#1}::_FUN(_GSource*, int (*)(void*), void*) (RunLoopGLib.cpp:56) ==196== by 0x15F52293: g_main_dispatch (gmain.c:3381) ==196== by 0x15F52293: g_main_context_dispatch (gmain.c:4099) ==196== by 0x15F52637: g_main_context_iterate.constprop.0 (gmain.c:4175) ==196== by 0x15F52942: g_main_loop_run (gmain.c:4373) ==196== by 0x110192B3: WTF::RunLoop::run() (RunLoopGLib.cpp:108) ==196== by 0xEFB8674: WebKit::AuxiliaryProcessMainBase<WebKit::WebProcess, true>::run(int, char**) (AuxiliaryProcessMain.h:70) ==196== by 0xEFB5D26: int WebKit::AuxiliaryProcessMain<WebKit::WebProcessMainWPE>(int, char**) (AuxiliaryProcessMain.h:96) ==196== by 0xEFB227E: WebKit::WebProcessMain(int, char**) (WebProcessMainWPE.cpp:75) ==196== by 0x109908: main (WebProcessMain.cpp:31) ==196== * Source/WebCore/platform/graphics/gstreamer/GLVideoSinkGStreamer.cpp: (requestGLContext): (setGLContext): Canonical link: https://commits.webkit.org/252340@main

…tureMapperFlags https://bugs.webkit.org/show_bug.cgi?id=242561 Reviewed by Xabier Rodriguez-Calvar. Fixes: ==195== Conditional jump or move depends on uninitialised value(s) ==195== at 0x11429778: WebCore::TextureMapperPlatformLayerBuffer::paintToTextureMapper(WebCore::TextureMapper&, WebCore::FloatRect const&, WebCore::TransformationMatrix const&, float) (TextureMapperPlatformLayerBuffer.cpp:112) ==195== by 0x11403DDD: WebCore::TextureMapperLayer::paintSelf(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:202) ==195== by 0x114042D4: WebCore::TextureMapperLayer::paintSelfAndChildren(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:255) ==195== by 0x114049D4: WebCore::TextureMapperLayer::paintSelfAndChildrenWithReplica(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:319) ==195== by 0x1140683D: WebCore::TextureMapperLayer::paintSelfChildrenReplicaFilterAndMask(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:563) ==195== by 0x11406903: WebCore::TextureMapperLayer::paintRecursive(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:576) ==195== by 0x114046C9: WebCore::TextureMapperLayer::paintSelfAndChildren(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:283) ==195== by 0x114049D4: WebCore::TextureMapperLayer::paintSelfAndChildrenWithReplica(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:319) ==195== by 0x1140683D: WebCore::TextureMapperLayer::paintSelfChildrenReplicaFilterAndMask(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:563) ==195== by 0x11406903: WebCore::TextureMapperLayer::paintRecursive(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:576) ==195== by 0x114046C9: WebCore::TextureMapperLayer::paintSelfAndChildren(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:283) ==195== by 0x114049D4: WebCore::TextureMapperLayer::paintSelfAndChildrenWithReplica(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:319) ==195== by 0x1140683D: WebCore::TextureMapperLayer::paintSelfChildrenReplicaFilterAndMask(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:563) ==195== by 0x11406903: WebCore::TextureMapperLayer::paintRecursive(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:576) ==195== by 0x114046C9: WebCore::TextureMapperLayer::paintSelfAndChildren(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:283) ==195== by 0x114049D4: WebCore::TextureMapperLayer::paintSelfAndChildrenWithReplica(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:319) ==195== by 0x1140683D: WebCore::TextureMapperLayer::paintSelfChildrenReplicaFilterAndMask(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:563) ==195== by 0x11406903: WebCore::TextureMapperLayer::paintRecursive(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:576) ==195== by 0x114046C9: WebCore::TextureMapperLayer::paintSelfAndChildren(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:283) ==195== by 0x114049D4: WebCore::TextureMapperLayer::paintSelfAndChildrenWithReplica(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:319) ==195== by 0x1140683D: WebCore::TextureMapperLayer::paintSelfChildrenReplicaFilterAndMask(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:563) ==195== by 0x11406903: WebCore::TextureMapperLayer::paintRecursive(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:576) ==195== by 0x114046C9: WebCore::TextureMapperLayer::paintSelfAndChildren(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:283) ==195== by 0x114049D4: WebCore::TextureMapperLayer::paintSelfAndChildrenWithReplica(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:319) ==195== by 0x1140683D: WebCore::TextureMapperLayer::paintSelfChildrenReplicaFilterAndMask(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:563) ==195== by 0x11406903: WebCore::TextureMapperLayer::paintRecursive(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:576) ==195== by 0x114046C9: WebCore::TextureMapperLayer::paintSelfAndChildren(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:283) ==195== by 0x114049D4: WebCore::TextureMapperLayer::paintSelfAndChildrenWithReplica(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:319) ==195== by 0x1140683D: WebCore::TextureMapperLayer::paintSelfChildrenReplicaFilterAndMask(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:563) ==195== by 0x11406903: WebCore::TextureMapperLayer::paintRecursive(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:576) ==195== by 0x114046C9: WebCore::TextureMapperLayer::paintSelfAndChildren(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:283) ==195== by 0x114049D4: WebCore::TextureMapperLayer::paintSelfAndChildrenWithReplica(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:319) ==195== by 0x1140683D: WebCore::TextureMapperLayer::paintSelfChildrenReplicaFilterAndMask(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:563) ==195== by 0x11406903: WebCore::TextureMapperLayer::paintRecursive(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:576) ==195== by 0x11403586: WebCore::TextureMapperLayer::paint(WebCore::TextureMapper&) (TextureMapperLayer.cpp:145) ==195== by 0xE6C2F6B: WebKit::CoordinatedGraphicsScene::paintToCurrentGLContext(WebCore::TransformationMatrix const&, WebCore::FloatRect const&, unsigned int) (CoordinatedGraphicsScene.cpp:78) ==195== by 0xE6E47A2: WebKit::ThreadedCompositor::renderLayerTree() (ThreadedCompositor.cpp:240) ==195== by 0xE6E3762: WebKit::ThreadedCompositor::ThreadedCompositor(WebKit::ThreadedCompositor::Client&, WebKit::ThreadedDisplayRefreshMonitor::Client&, unsigned int, WebCore::IntSize const&, float, unsigned int)::{lambda()#1}::operator()() const (ThreadedCompositor.cpp:58) ==195== by 0xE6E83FD: WTF::Detail::CallableWrapper<WebKit::ThreadedCompositor::ThreadedCompositor(WebKit::ThreadedCompositor::Client&, WebKit::ThreadedDisplayRefreshMonitor::Client&, unsigned int, WebCore::IntSize const&, float, unsigned int)::{lambda()#1}, void>::call() (Function.h:53) ==195== by 0xD9D7F1C: WTF::Function<void ()>::operator()() const (Function.h:82) ==195== by 0xE6C660B: WebKit::CompositingRunLoop::updateTimerFired() (CompositingRunLoop.cpp:188) ==195== by 0xE6E33EF: void std::__invoke_impl<void, void (WebKit::CompositingRunLoop::*&)(), WebKit::CompositingRunLoop*&>(std::__invoke_memfun_deref, void (WebKit::CompositingRunLoop::*&)(), WebKit::CompositingRunLoop*&) (invoke.h:74) ==195== by 0xE6E3368: std::__invoke_result<void (WebKit::CompositingRunLoop::*&)(), WebKit::CompositingRunLoop*&>::type std::__invoke<void (WebKit::CompositingRunLoop::*&)(), WebKit::CompositingRunLoop*&>(void (WebKit::CompositingRunLoop::*&)(), WebKit::CompositingRunLoop*&) (invoke.h:96) ==195== by 0xE6E32DE: void std::_Bind<void (WebKit::CompositingRunLoop::*(WebKit::CompositingRunLoop*))()>::__call<void, , 0ul>(std::tuple<>&&, std::_Index_tuple<0ul>) (functional:420) ==195== by 0xE6E3270: void std::_Bind<void (WebKit::CompositingRunLoop::*(WebKit::CompositingRunLoop*))()>::operator()<, void>() (functional:503) ==195== by 0xE6E3219: WTF::Detail::CallableWrapper<std::_Bind<void (WebKit::CompositingRunLoop::*(WebKit::CompositingRunLoop*))()>, void>::call() (Function.h:53) ==195== by 0xD9D7F1C: WTF::Function<void ()>::operator()() const (Function.h:82) ==195== by 0xE6E3239: WTF::RunLoop::Timer<WebKit::CompositingRunLoop>::fired() (RunLoop.h:188) ==195== by 0x1108296A: WTF::RunLoop::TimerBase::TimerBase(WTF::RunLoop&)::{lambda(void*)#1}::operator()(void*) const (RunLoopGLib.cpp:177) ==195== by 0x110829AA: WTF::RunLoop::TimerBase::TimerBase(WTF::RunLoop&)::{lambda(void*)#1}::_FUN(void*) (RunLoopGLib.cpp:181) ==195== by 0x11081EBC: WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)#1}::operator()(_GSource*, int (*)(void*), void*) const (RunLoopGLib.cpp:53) ==195== by 0x11081F0A: WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)#1}::_FUN(_GSource*, int (*)(void*), void*) (RunLoopGLib.cpp:56) ==195== by 0x15FB8293: g_main_dispatch (gmain.c:3381) ==195== by 0x15FB8293: g_main_context_dispatch (gmain.c:4099) ==195== by 0x15FB8637: g_main_context_iterate.constprop.0 (gmain.c:4175) ==195== by 0x15FB8942: g_main_loop_run (gmain.c:4373) ==195== by 0x11082575: WTF::RunLoop::run() (RunLoopGLib.cpp:108) ==195== by 0xE6C5CB2: WebKit::createRunLoop()::{lambda()#1}::operator()() const (CompositingRunLoop.cpp:49) ==195== by 0xE6CADE5: WTF::Detail::CallableWrapper<WebKit::createRunLoop()::{lambda()#1}, void>::call() (Function.h:53) ==195== by 0xD9D7F1C: WTF::Function<void ()>::operator()() const (Function.h:82) ==195== by 0x10FDF034: WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) (Threading.cpp:236) ==195== by 0x1108F1BC: WTF::wtfThreadEntryPoint(void*) (ThreadingPOSIX.cpp:242) ==195== by 0x18A463B9: start_thread (pthread_create.c:481) ==195== by 0x16782952: clone (clone.S:95) ==195== Uninitialised value was created by a heap allocation ==195== at 0x4840899: malloc (vg_replace_malloc.c:381) ==195== by 0x10F92F47: WTF::fastMalloc(unsigned long) (FastMalloc.cpp:232) ==195== by 0x112E0165: WebCore::MediaPlayerPrivateGStreamer::operator new(unsigned long) (MediaPlayerPrivateGStreamer.h:128) ==195== by 0x112E5BB3: std::_MakeUniq<WebCore::MediaPlayerPrivateGStreamer>::__single_object std::make_unique<WebCore::MediaPlayerPrivateGStreamer, WebCore::MediaPlayer*&>(WebCore::MediaPlayer*&) (unique_ptr.h:962) ==195== by 0x112E24B9: decltype(auto) WTF::makeUnique<WebCore::MediaPlayerPrivateGStreamer, WebCore::MediaPlayer*&>(WebCore::MediaPlayer*&) (StdLibExtras.h:540) ==195== by 0x112E2509: WebCore::MediaPlayerFactoryGStreamer::createMediaEnginePlayer(WebCore::MediaPlayer*) const (MediaPlayerPrivateGStreamer.cpp:288) ==195== by 0x149351A3: WebCore::MediaPlayer::loadWithNextMediaEngine(WebCore::MediaPlayerFactory const*) (MediaPlayer.cpp:625) ==195== by 0x14934C7E: WebCore::MediaPlayer::load(WebCore::MediaStreamPrivate&) (MediaPlayer.cpp:549) ==195== by 0x13D5FCA5: WebCore::HTMLMediaElement::loadResource(WTF::URL const&, WebCore::ContentType&, WTF::String const&) (HTMLMediaElement.cpp:1599) ==195== by 0x13D5E9CE: WebCore::HTMLMediaElement::selectMediaResource()::{lambda()#1}::operator()() const (HTMLMediaElement.cpp:1413) ==195== by 0x13D91E1B: WTF::Detail::CallableWrapper<WebCore::HTMLMediaElement::selectMediaResource()::{lambda()#1}, void>::call() (Function.h:53) ==195== by 0xD9D7F1C: WTF::Function<void ()>::operator()() const (Function.h:82) ==195== by 0x1322C265: WTF::CancellableTask::operator()() (CancellableTask.h:86) ==195== by 0x13D95F3B: WebCore::ActiveDOMObject::queueCancellableTaskKeepingObjectAlive<WebCore::HTMLMediaElement>(WebCore::HTMLMediaElement&, WebCore::TaskSource, WTF::TaskCancellationGroup&, WTF::Function<void ()>&&)::{lambda()#1}::operator()() (ActiveDOMObject.h:119) ==195== by 0x13DC54ED: WTF::Detail::CallableWrapper<WebCore::ActiveDOMObject::queueCancellableTaskKeepingObjectAlive<WebCore::HTMLMediaElement>(WebCore::HTMLMediaElement&, WebCore::TaskSource, WTF::TaskCancellationGroup&, WTF::Function<void ()>&&)::{lambda()#1}, void>::call() (Function.h:53) ==195== by 0xD9D7F1C: WTF::Function<void ()>::operator()() const (Function.h:82) ==195== by 0x139FB2B1: WebCore::EventLoopFunctionDispatchTask::execute() (EventLoop.cpp:159) ==195== by 0x139F0D50: WebCore::EventLoop::run() (EventLoop.cpp:123) ==195== by 0x13B2815F: WebCore::WindowEventLoop::didReachTimeToRun() (WindowEventLoop.cpp:121) ==195== by 0x13B3D6FD: void std::__invoke_impl<void, void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&>(std::__invoke_memfun_deref, void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&) (invoke.h:74) ==195== by 0x13B3D668: std::__invoke_result<void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&>::type std::__invoke<void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&>(void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&) (invoke.h:96) ==195== by 0x13B3D5DE: void std::_Bind<void (WebCore::WindowEventLoop::*(WebCore::WindowEventLoop*))()>::__call<void, , 0ul>(std::tuple<>&&, std::_Index_tuple<0ul>) (functional:420) ==195== by 0x13B3D570: void std::_Bind<void (WebCore::WindowEventLoop::*(WebCore::WindowEventLoop*))()>::operator()<, void>() (functional:503) ==195== by 0x13B3D539: WTF::Detail::CallableWrapper<std::_Bind<void (WebCore::WindowEventLoop::*(WebCore::WindowEventLoop*))()>, void>::call() (Function.h:53) ==195== by 0xD9D7F1C: WTF::Function<void ()>::operator()() const (Function.h:82) ==195== by 0xE2769FD: WebCore::Timer::fired() (Timer.h:135) ==195== by 0x1474B909: WebCore::ThreadTimers::sharedTimerFiredInternal() (ThreadTimers.cpp:127) ==195== by 0x1474B1FE: WebCore::ThreadTimers::setSharedTimer(WebCore::SharedTimer*)::{lambda()#1}::operator()() const (ThreadTimers.cpp:67) ==195== by 0x1474E321: WTF::Detail::CallableWrapper<WebCore::ThreadTimers::setSharedTimer(WebCore::SharedTimer*)::{lambda()#1}, void>::call() (Function.h:53) ==195== by 0xD9D7F1C: WTF::Function<void ()>::operator()() const (Function.h:82) ==195== by 0x146FE25D: WebCore::MainThreadSharedTimer::fired() (MainThreadSharedTimer.cpp:83) ==195== by 0x14708DE9: void std::__invoke_impl<void, void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&>(std::__invoke_memfun_deref, void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&) (invoke.h:74) ==195== by 0x14708D62: std::__invoke_result<void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&>::type std::__invoke<void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&>(void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&) (invoke.h:96) ==195== by 0x14708CD8: void std::_Bind<void (WebCore::MainThreadSharedTimer::*(WebCore::MainThreadSharedTimer*))()>::__call<void, , 0ul>(std::tuple<>&&, std::_Index_tuple<0ul>) (functional:420) ==195== by 0x14708C6A: void std::_Bind<void (WebCore::MainThreadSharedTimer::*(WebCore::MainThreadSharedTimer*))()>::operator()<, void>() (functional:503) ==195== by 0x14708C13: WTF::Detail::CallableWrapper<std::_Bind<void (WebCore::MainThreadSharedTimer::*(WebCore::MainThreadSharedTimer*))()>, void>::call() (Function.h:53) ==195== by 0xD9D7F1C: WTF::Function<void ()>::operator()() const (Function.h:82) ==195== by 0x14708C33: WTF::RunLoop::Timer<WebCore::MainThreadSharedTimer>::fired() (RunLoop.h:188) ==195== by 0x1108296A: WTF::RunLoop::TimerBase::TimerBase(WTF::RunLoop&)::{lambda(void*)#1}::operator()(void*) const (RunLoopGLib.cpp:177) ==195== by 0x110829AA: WTF::RunLoop::TimerBase::TimerBase(WTF::RunLoop&)::{lambda(void*)#1}::_FUN(void*) (RunLoopGLib.cpp:181) ==195== by 0x11081EBC: WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)#1}::operator()(_GSource*, int (*)(void*), void*) const (RunLoopGLib.cpp:53) ==195== by 0x11081F0A: WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)#1}::_FUN(_GSource*, int (*)(void*), void*) (RunLoopGLib.cpp:56) ==195== by 0x15FB8293: g_main_dispatch (gmain.c:3381) ==195== by 0x15FB8293: g_main_context_dispatch (gmain.c:4099) ==195== by 0x15FB8637: g_main_context_iterate.constprop.0 (gmain.c:4175) ==195== by 0x15FB8942: g_main_loop_run (gmain.c:4373) ==195== by 0x11082575: WTF::RunLoop::run() (RunLoopGLib.cpp:108) ==195== by 0xF024098: WebKit::AuxiliaryProcessMainBase<WebKit::WebProcess, true>::run(int, char**) (AuxiliaryProcessMain.h:70) ==195== by 0xF02174A: int WebKit::AuxiliaryProcessMain<WebKit::WebProcessMainWPE>(int, char**) (AuxiliaryProcessMain.h:96) ==195== by 0xF01DCA2: WebKit::WebProcessMain(int, char**) (WebProcessMainWPE.cpp:75) ==195== by 0x109918: main (WebProcessMain.cpp:31) ==195== * Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.h: Canonical link: https://commits.webkit.org/252393@main

…us wrapper https://bugs.webkit.org/show_bug.cgi?id=242734 Reviewed by Antti Koivisto. When the anonymous block wrapper for an inline level child is not needed anymore (sibling block is removed or became non-inflow), we 1. detach the inline level child (and its subtree) 2. destroy the anonymous wrapper 3. re-attach the inline level child under the new parent (most likely the parent of the destroyed anonymous wrapper) We call this re-parenting activity an "internal move". Certain properties (e.g fragmentation state) are not supposed to change during this type of move (we simply stop calling some "reset" functions when RenderObject::IsInternalMove::Yes) This patch ensures that the internal move flag is set for both #1 and #3. * Source/WebCore/rendering/RenderBlockFlow.cpp: drive-by fix to ensure no ruby content gets multi-column context. (WebCore::RenderBlockFlow::willCreateColumns const): * Source/WebCore/rendering/updating/RenderTreeBuilder.cpp: (WebCore::RenderTreeBuilder::removeAnonymousWrappersForInlineChildrenIfNeeded): Make sure both detach and attach are covered with the "internal move" flag as currently only the attach is covered. It means that whatever flags we reset at detach (not an internal move) we don't set back on attach (internal move). Canonical link: https://commits.webkit.org/252456@main

https://bugs.webkit.org/show_bug.cgi?id=242517 Reviewed by Darin Adler. We need to initialize processIdentifier as it is accessed by the equality operator for GlobalWindowIdentifier. Fixes the following valgrind error: ==137== Conditional jump or move depends on uninitialised value(s) ==137== at 0x144770C4: WebCore::operator==(WebCore::GlobalWindowIdentifier const&, WebCore::GlobalWindowIdentifier const&) (GlobalWindowIdentifier.h:49) ==137== by 0x1447715D: WTF::GlobalWindowIdentifierHash::equal(WebCore::GlobalWindowIdentifier const&, WebCore::GlobalWindowIdentifier const&) (GlobalWindowIdentifier.h:85) ==137== by 0x1447ACBA: bool WTF::HashMapTranslator<WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::DefaultHash<WebCore::GlobalWindowIdentifier> >::equal<WebCore::GlobalWindowIdentifier, WebCore::GlobalWindowIdentifier>(WebCore::GlobalWindowIdentifier const&, WebCore::GlobalWindowIdentifier const&) (HashMap.h:229) ==137== by 0x1447AAEB: void WTF::HashTable<WebCore::GlobalWindowIdentifier, WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*>, WTF::KeyValuePairKeyExtractor<WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*> >, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::HashTraits<WebCore::GlobalWindowIdentifier> >::checkKey<WTF::HashMapTranslator<WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::DefaultHash<WebCore::GlobalWindowIdentifier> >, WebCore::GlobalWindowIdentifier>(WebCore::GlobalWindowIdentifier const&) (HashTable.h:664) ==137== by 0x14479888: WTF::HashTableAddResult<WTF::HashTableIterator<WTF::HashTable<WebCore::GlobalWindowIdentifier, WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*>, WTF::KeyValuePairKeyExtractor<WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*> >, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::HashTraits<WebCore::GlobalWindowIdentifier> >, WebCore::GlobalWindowIdentifier, WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*>, WTF::KeyValuePairKeyExtractor<WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*> >, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::HashTraits<WebCore::GlobalWindowIdentifier> > > WTF::HashTable<WebCore::GlobalWindowIdentifier, WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*>, WTF::KeyValuePairKeyExtractor<WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*> >, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::HashTraits<WebCore::GlobalWindowIdentifier> >::add<WTF::HashMapTranslator<WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::DefaultHash<WebCore::GlobalWindowIdentifier> >, WebCore::GlobalWindowIdentifier const&, WebCore::AbstractDOMWindow*>(WebCore::GlobalWindowIdentifier const&, WebCore::AbstractDOMWindow*&&) (HashTable.h:932) ==137== by 0x1447895D: WTF::HashTableAddResult<WTF::HashTableIterator<WTF::HashTable<WebCore::GlobalWindowIdentifier, WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*>, WTF::KeyValuePairKeyExtractor<WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*> >, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::HashTraits<WebCore::GlobalWindowIdentifier> >, WebCore::GlobalWindowIdentifier, WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*>, WTF::KeyValuePairKeyExtractor<WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*> >, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::HashTraits<WebCore::GlobalWindowIdentifier> > > WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::inlineAdd<WebCore::GlobalWindowIdentifier const&, WebCore::AbstractDOMWindow*>(WebCore::GlobalWindowIdentifier const&, WebCore::AbstractDOMWindow*&&) (HashMap.h:382) ==137== by 0x1447795B: WTF::HashTableAddResult<WTF::HashTableIterator<WTF::HashTable<WebCore::GlobalWindowIdentifier, WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*>, WTF::KeyValuePairKeyExtractor<WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*> >, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::HashTraits<WebCore::GlobalWindowIdentifier> >, WebCore::GlobalWindowIdentifier, WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*>, WTF::KeyValuePairKeyExtractor<WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*> >, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::HashTraits<WebCore::GlobalWindowIdentifier> > > WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::add<WebCore::AbstractDOMWindow*>(WebCore::GlobalWindowIdentifier const&, WebCore::AbstractDOMWindow*&&) (HashMap.h:417) ==137== by 0x144705B3: WebCore::AbstractDOMWindow::AbstractDOMWindow(WebCore::GlobalWindowIdentifier&&) (AbstractDOMWindow.cpp:48) ==137== by 0x1448AA3C: WebCore::DOMWindow::DOMWindow(WebCore::Document&) (DOMWindow.cpp:405) ==137== by 0x1392F767: WebCore::DOMWindow::create(WebCore::Document&) (DOMWindow.h:124) ==137== by 0x139026F1: WebCore::Document::createDOMWindow() (Document.cpp:5119) ==137== by 0x142DD1B7: WebCore::DocumentWriter::begin(WTF::URL const&, bool, WebCore::Document*, WebCore::ProcessQualified<WTF::UUID>)::{lambda()#1}::operator()() const (DocumentWriter.cpp:165) ==137== by 0x142E61DB: WTF::Detail::CallableWrapper<WebCore::DocumentWriter::begin(WTF::URL const&, bool, WebCore::Document*, WebCore::ProcessQualified<WTF::UUID>)::{lambda()#1}, void>::call() (Function.h:53) ==137== by 0xD9D5E94: WTF::Function<void ()>::operator()() const (Function.h:82) ==137== by 0x1431A333: WebCore::FrameLoader::clear(WTF::RefPtr<WebCore::Document, WTF::RawPtrTraits<WebCore::Document>, WTF::DefaultRefDerefTraits<WebCore::Document> >&&, bool, bool, bool, WTF::Function<void ()>&&) (FrameLoader.cpp:646) ==137== by 0x142DD5B1: WebCore::DocumentWriter::begin(WTF::URL const&, bool, WebCore::Document*, WebCore::ProcessQualified<WTF::UUID>) (DocumentWriter.cpp:168) ==137== by 0x142D05BB: WebCore::DocumentLoader::commitData(WebCore::SharedBuffer const&) (DocumentLoader.cpp:1235) ==137== by 0x142CAE8C: WebCore::DocumentLoader::finishedLoading() (DocumentLoader.cpp:493) ==137== by 0x142D44AA: WebCore::DocumentLoader::maybeLoadEmpty() (DocumentLoader.cpp:2038) ==137== by 0x142D4D93: WebCore::DocumentLoader::startLoadingMainResource() (DocumentLoader.cpp:2065) ==137== by 0x143188E2: WebCore::FrameLoader::init() (FrameLoader.cpp:351) ==137== by 0x144DB8BF: WebCore::Frame::init() (Frame.cpp:192) ==137== by 0xEFD71C5: WebKit::WebFrame::initWithCoreMainFrame(WebKit::WebPage&, WebCore::Frame&) (WebFrame.cpp:115) ==137== by 0xEF7CECD: WebKit::WebPage::WebPage(WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters&&) (WebPage.cpp:721) ==137== by 0xEF7B307: WebKit::WebPage::create(WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters&&) (WebPage.cpp:461) ==137== by 0xECA85C2: WebKit::WebProcess::createWebPage(WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters&&) (WebProcess.cpp:837) ==137== by 0xDEB4991: void IPC::callMemberFunctionImpl<WebKit::WebProcess, void (WebKit::WebProcess::*)(WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters&&), std::tuple<WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters>, 0ul, 1ul>(WebKit::WebProcess*, void (WebKit::WebProcess::*)(WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters&&), std::tuple<WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters>&&, std::integer_sequence<unsigned long, 0ul, 1ul>) (HandleMessage.h:131) ==137== by 0xDEB1B6F: void IPC::callMemberFunction<WebKit::WebProcess, void (WebKit::WebProcess::*)(WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters&&), std::tuple<WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters>, std::integer_sequence<unsigned long, 0ul, 1ul> >(std::tuple<WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters>&&, WebKit::WebProcess*, void (WebKit::WebProcess::*)(WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters&&)) (HandleMessage.h:137) ==137== by 0xDEACC26: void IPC::handleMessage<Messages::WebProcess::CreateWebPage, WebKit::WebProcess, void (WebKit::WebProcess::*)(WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters&&)>(IPC::Connection&, IPC::Decoder&, WebKit::WebProcess*, void (WebKit::WebProcess::*)(WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters&&)) (HandleMessage.h:259) ==137== by 0xDEAA311: WebKit::WebProcess::didReceiveWebProcessMessage(IPC::Connection&, IPC::Decoder&) (WebProcessMessageReceiver.cpp:280) ==137== by 0xECA8AA3: WebKit::WebProcess::didReceiveMessage(IPC::Connection&, IPC::Decoder&) (WebProcess.cpp:916) ==137== by 0xE58AFE3: IPC::Connection::dispatchMessage(IPC::Decoder&) (Connection.cpp:1108) ==137== by 0xE58B27A: IPC::Connection::dispatchMessage(std::unique_ptr<IPC::Decoder, std::default_delete<IPC::Decoder> >) (Connection.cpp:1153) ==137== by 0xE58B821: IPC::Connection::dispatchOneIncomingMessage() (Connection.cpp:1222) ==137== by 0xE58ACF3: IPC::Connection::enqueueIncomingMessage(std::unique_ptr<IPC::Decoder, std::default_delete<IPC::Decoder> >)::{lambda()#1}::operator()() (Connection.cpp:1072) ==137== by 0xE591DD7: WTF::Detail::CallableWrapper<IPC::Connection::enqueueIncomingMessage(std::unique_ptr<IPC::Decoder, std::default_delete<IPC::Decoder> >)::{lambda()#1}, void>::call() (Function.h:53) ==137== by 0xD9D5E94: WTF::Function<void ()>::operator()() const (Function.h:82) ==137== by 0x10FD4BEE: WTF::RunLoop::performWork() (RunLoop.cpp:133) ==137== by 0x110803FD: WTF::RunLoop::RunLoop()::{lambda(void*)#1}::operator()(void*) const (RunLoopGLib.cpp:80) ==137== by 0x11080421: WTF::RunLoop::RunLoop()::{lambda(void*)#1}::_FUN(void*) (RunLoopGLib.cpp:82) ==137== by 0x11080390: WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)#1}::operator()(_GSource*, int (*)(void*), void*) const (RunLoopGLib.cpp:53) ==137== by 0x110803DE: WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)#1}::_FUN(_GSource*, int (*)(void*), void*) (RunLoopGLib.cpp:56) ==137== by 0x15FB4293: g_main_dispatch (gmain.c:3381) ==137== by 0x15FB4293: g_main_context_dispatch (gmain.c:4099) ==137== by 0x15FB4637: g_main_context_iterate.constprop.0 (gmain.c:4175) ==137== by 0x15FB4942: g_main_loop_run (gmain.c:4373) ==137== by 0x11080A49: WTF::RunLoop::run() (RunLoopGLib.cpp:108) ==137== by 0xF022010: WebKit::AuxiliaryProcessMainBase<WebKit::WebProcess, true>::run(int, char**) (AuxiliaryProcessMain.h:70) ==137== by 0xF01F6C2: int WebKit::AuxiliaryProcessMain<WebKit::WebProcessMainWPE>(int, char**) (AuxiliaryProcessMain.h:96) ==137== by 0xF01BC1A: WebKit::WebProcessMain(int, char**) (WebProcessMainWPE.cpp:75) ==137== by 0x109918: main (WebProcessMain.cpp:31) ==137== Uninitialised value was created by a stack allocation ==137== at 0x1447AA1A: void WTF::HashTable<WebCore::GlobalWindowIdentifier, WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*>, WTF::KeyValuePairKeyExtractor<WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*> >, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::HashTraits<WebCore::GlobalWindowIdentifier> >::checkKey<WTF::HashMapTranslator<WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::DefaultHash<WebCore::GlobalWindowIdentifier> >, WebCore::GlobalWindowIdentifier>(WebCore::GlobalWindowIdentifier const&) (HashTable.h:655) ==137== * Source/WebCore/page/GlobalWindowIdentifier.h: (WTF::HashTraits<WebCore::GlobalWindowIdentifier>::constructDeletedValue): Canonical link: https://commits.webkit.org/252473@main

https://bugs.webkit.org/show_bug.cgi?id=241856 Reviewed by Yusuke Suzuki. 1. Ruby treats numeric 0 as truthy. However, there's a test in arm64LowerMalformedLoadStoreAddresses which assumes a value of 0 would be false. As a result, we see offlineasm emit inefficient LLInt code like this: ".loc 3 821\n" "movz x16, #0 \n" // LowLevelInterpreter64.asm:821 "add x13, x3, x16 \n" "ldr x0, [x13] \n" ... instead of this: ".loc 3 821\n" "ldr x0, [x3] \n" // LowLevelInterpreter64.asm:821 This patch fixes this. 2. offlineasm's emitARM64MoveImmediate chooses to use `movn` instead of `movz` based on whether a 64-bit value is negative or not. Instead, it should be making that decision based on the number of halfwords (16-bits) in the value that is 0xffff vs 0. As a result, offlineasm emits code like this: ".loc 1 1638\n" "movn x27, #1, lsl #48 \n" // LowLevelInterpreter.asm:1638 "movk x27, #0, lsl #32 \n" "movk x27, #0, lsl #16 \n" "movk x27, #0 \n" ... instead of this: ".loc 1 1638\n" "movz x27, WebKit#65534, lsl #48 \n" // LowLevelInterpreter.asm:1638 This patch fixes this. 3. offlineasm is trivially assuming the range of immediate offsets for ldr/str instructions is [-255..4095]. However, that's only the range for byte sized load-stores. For 32-bit, the range is actually [-255..16380]. For 64-bit, the range is actually [-255..32760]. As a result, offlineasm emits code like this: ".loc 1 633\n" "movn x16, WebKit#16383 \n" // LowLevelInterpreter.asm:633 ".loc 1 1518\n" "and x3, x3, x16 \n" // LowLevelInterpreter.asm:1518 ".loc 1 1519\n" "movz x16, WebKit#16088 \n" // LowLevelInterpreter.asm:1519 "add x17, x3, x16 \n" "ldr x3, [x17] \n" ... instead of this: ".loc 1 633\n" "movn x17, WebKit#16383 \n" // LowLevelInterpreter.asm:633 ".loc 1 1518\n" "and x3, x3, x17 \n" // LowLevelInterpreter.asm:1518 ".loc 1 1519\n" "ldr x3, [x3, WebKit#16088] \n" // LowLevelInterpreter.asm:1519 This patch fixes this for 64-bit and 32-bit load-stores. 16-bit load-stores also has a wider range, but for now, it will continue to use the conservative range. This patch also introduces an `isMalformedArm64LoadAStoreAddress` so that this range check can be done consistently in all the places that checks for it. 4. offlineasm is eagerly emitting no-op arguments in instructions, e.g. "lsl #0", and adding 0. As a result, offlineasm emits code like this: ".loc 3 220\n" "movz x13, WebKit#51168, lsl #0 \n" // LowLevelInterpreter64.asm:220 "add x17, x1, x13, lsl #0 \n" "ldr w4, [x17, #0] \n" ... instead of this: ".loc 3 220\n" "movz x13, WebKit#51168 \n" // LowLevelInterpreter64.asm:220 "add x17, x1, x13 \n" "ldr w4, [x17] \n" This unnecessary arguments are actually very common throughout the emitted LLIntAssembly.h. This patch removes these unnecessary arguments, which makes the emitted LLInt code more human readable due to less clutter. This patch has passed the testapi and JSC stress tests with a Release build on an M1 Mac. I also manually verified that the emitARM64MoveImmediate code is working properly by hacking up LowLevelInterpreter64.asm to emit moves of constants of different values in the ranges, and for load-store instructions of different sizes, and visually inspecting the emitted code. * Source/JavaScriptCore/offlineasm/arm64.rb: Canonical link: https://commits.webkit.org/251771@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@295766 268f45cc-cd09-0410-ab3c-d52691b4dbfc

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

https://bugs.webkit.org/show_bug.cgi?id=242295 Reviewed by Michael Catanzaro. We need to use adoptGRef when calling g_variant_get_data_as_bytes as the return is already ref'd. See: https://github.com/GNOME/glib/blob/2.72.3/glib/gvariant-core.c#L975 Fixes: ==3126== 330 (120 direct, 210 indirect) bytes in 3 blocks are definitely lost in loss record 3,105 of 3,199 ==3126== at 0x48447ED: malloc (vg_replace_malloc.c:381) ==3126== by 0xA87B2E8: g_malloc (gmem.c:106) ==3126== by 0xA892E44: g_slice_alloc (gslice.c:1072) ==3126== by 0xA84B005: g_bytes_new_with_free_func (gbytes.c:186) ==3126== by 0xA84B067: g_bytes_new_take (gbytes.c:128) ==3126== by 0xA8B934D: g_variant_ensure_serialised (gvariant-core.c:460) ==3126== by 0xA8B958E: g_variant_get_data_as_bytes (gvariant-core.c:961) ==3126== by 0x8765214: WebCore::KeyedEncoderGlib::finishEncoding() (KeyedEncoderGlib.cpp:139) ==3126== by 0x53CF40E: WebKit::writeToDisk(std::unique_ptr<WebCore::KeyedEncoder, std::default_delete<WebCore::KeyedEncoder> >&&, WTF::String&&) (PersistencyUtils.cpp:53) ==3126== by 0x545EF8C: operator() (DeviceIdHashSaltStorage.cpp:201) ==3126== by 0x545EF8C: WTF::Detail::CallableWrapper<WebKit::DeviceIdHashSaltStorage::storeHashSaltToDisk(WebKit::DeviceIdHashSaltStorage::HashSaltForOrigin const&)::{lambda()#1}, void>::call() (Function.h:53) ==3126== by 0x6E52DE9: operator() (Function.h:82) ==3126== by 0x6E52DE9: operator() (WorkQueueGeneric.cpp:70) ==3126== by 0x6E52DE9: WTF::Detail::CallableWrapper<WTF::WorkQueueBase::dispatch(WTF::Function<void ()>&&)::{lambda()#1}, void>::call() (Function.h:53) ==3126== by 0x6DF490F: operator() (Function.h:82) ==3126== by 0x6DF490F: WTF::RunLoop::performWork() (RunLoop.cpp:133) ==3126== by 0x6E55171: WTF::RunLoop::RunLoop()::{lambda(void*)#1}::_FUN(void*) (RunLoopGLib.cpp:80) ==3126== by 0x6E55D61: operator() (RunLoopGLib.cpp:53) ==3126== by 0x6E55D61: WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)#1}::_FUN(_GSource*, int (*)(void*), void*) (RunLoopGLib.cpp:56) ==3126== by 0xA8723AB: g_main_dispatch (gmain.c:3381) ==3126== by 0xA875839: g_main_context_dispatch (gmain.c:4099) ==3126== by 0xA8759A7: g_main_context_iterate (gmain.c:4175) ==3126== by 0xA875D41: g_main_loop_run (gmain.c:4373) ==3126== by 0x6E5613C: WTF::RunLoop::run() (RunLoopGLib.cpp:108) ==3126== by 0x6E52E14: operator() (WorkQueueGeneric.cpp:51) ==3126== by 0x6E52E14: WTF::Detail::CallableWrapper<WTF::WorkQueueBase::platformInitialize(char const*, WTF::WorkQueueBase::Type, WTF::Thread::QOS)::{lambda()#1}, void>::call() (Function.h:53) ==3126== by 0x6DF6FD7: operator() (Function.h:82) ==3126== by 0x6DF6FD7: WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) (Threading.cpp:236) ==3126== by 0x6E59A3F: WTF::wtfThreadEntryPoint(void*) (ThreadingPOSIX.cpp:242) ==3126== by 0xA9D6DC2: start_thread (pthread_create.c:442) ==3126== by 0xAA4FA0F: clone (clone.S:100) ==3126== * Source/WebCore/platform/glib/KeyedEncoderGlib.cpp: (WebCore::KeyedEncoderGlib::finishEncoding): Canonical link: https://commits.webkit.org/252100@main

…e leak https://bugs.webkit.org/show_bug.cgi?id=242576 Reviewed by Xabier Rodriguez-Calvar. Refactor ref counting for GstContext in GLVideoSinkGStreamer to prevent a resource leak. Fixes: ==196== 401 (296 direct, 105 indirect) bytes in 1 blocks are definitely lost in loss record 58,280 of 62,411 ==196== at 0x4845A83: calloc (vg_replace_malloc.c:1328) ==196== by 0x15F58780: g_malloc0 (gmem.c:136) ==196== by 0x161C8CBB: gst_structure_new_id_empty_with_size (gststructure.c:281) ==196== by 0x161C8CBB: gst_structure_new_id_empty (gststructure.c:312) ==196== by 0x161716CF: gst_context_new (gstcontext.c:178) ==196== by 0x1122BB85: requestGLContext(char const*) (GLVideoSinkGStreamer.cpp:154) ==196== by 0x1122BD12: setGLContext(_GstElement*, char const*) (GLVideoSinkGStreamer.cpp:173) ==196== by 0x1122BE39: webKitGLVideoSinkChangeState(_GstElement*, GstStateChange) (GLVideoSinkGStreamer.cpp:189) ==196== by 0x1617FA11: gst_element_change_state (gstelement.c:3083) ==196== by 0x16180154: gst_element_set_state_func (gstelement.c:3037) ==196== by 0x40651CE6: activate_sink (gstplaybin3.c:3805) ==196== by 0x40651CE6: activate_sink.constprop.0 (gstplaybin3.c:3780) ==196== by 0x40652B3E: activate_group (gstplaybin3.c:4539) ==196== by 0x40652B3E: setup_next_source (gstplaybin3.c:4801) ==196== by 0x406542A7: gst_play_bin3_change_state (gstplaybin3.c:5031) ==196== by 0x1617FA11: gst_element_change_state (gstelement.c:3083) ==196== by 0x1617FA5A: gst_element_change_state (gstelement.c:3122) ==196== by 0x16180154: gst_element_set_state_func (gstelement.c:3037) ==196== by 0x11257BC9: WebCore::MediaPlayerPrivateGStreamer::changePipelineState(GstState) (MediaPlayerPrivateGStreamer.cpp:924) ==196== by 0x11258D8B: WebCore::MediaPlayerPrivateGStreamer::commitLoad() (MediaPlayerPrivateGStreamer.cpp:1184) ==196== by 0x1125420B: WebCore::MediaPlayerPrivateGStreamer::load(WTF::String const&) (MediaPlayerPrivateGStreamer.cpp:354) ==196== by 0x112542F4: WebCore::MediaPlayerPrivateGStreamer::load(WebCore::MediaStreamPrivate&) (MediaPlayerPrivateGStreamer.cpp:370) ==196== by 0x148CF508: WebCore::MediaPlayer::loadWithNextMediaEngine(WebCore::MediaPlayerFactory const*) (MediaPlayer.cpp:646) ==196== by 0x148CED64: WebCore::MediaPlayer::load(WebCore::MediaStreamPrivate&) (MediaPlayer.cpp:549) ==196== by 0x13CF7047: WebCore::HTMLMediaElement::loadResource(WTF::URL const&, WebCore::ContentType&, WTF::String const&) (HTMLMediaElement.cpp:1599) ==196== by 0x13CF5D70: WebCore::HTMLMediaElement::selectMediaResource()::{lambda()#1}::operator()() const (HTMLMediaElement.cpp:1413) ==196== by 0x13D291BD: WTF::Detail::CallableWrapper<WebCore::HTMLMediaElement::selectMediaResource()::{lambda()#1}, void>::call() (Function.h:53) ==196== by 0xD99E63C: WTF::Function<void ()>::operator()() const (Function.h:82) ==196== by 0x131C31E7: WTF::CancellableTask::operator()() (CancellableTask.h:86) ==196== by 0x13D2D2DD: WebCore::ActiveDOMObject::queueCancellableTaskKeepingObjectAlive<WebCore::HTMLMediaElement>(WebCore::HTMLMediaElement&, WebCore::TaskSource, WTF::TaskCancellationGroup&, WTF::Function<void ()>&&)::{lambda()#1}::operator()() (ActiveDOMObject.h:119) ==196== by 0x13D5C88F: WTF::Detail::CallableWrapper<WebCore::ActiveDOMObject::queueCancellableTaskKeepingObjectAlive<WebCore::HTMLMediaElement>(WebCore::HTMLMediaElement&, WebCore::TaskSource, WTF::TaskCancellationGroup&, WTF::Function<void ()>&&)::{lambda()#1}, void>::call() (Function.h:53) ==196== by 0xD99E63C: WTF::Function<void ()>::operator()() const (Function.h:82) ==196== by 0x1399229B: WebCore::EventLoopFunctionDispatchTask::execute() (EventLoop.cpp:159) ==196== by 0x13987D3A: WebCore::EventLoop::run() (EventLoop.cpp:123) ==196== by 0x13ABF15D: WebCore::WindowEventLoop::didReachTimeToRun() (WindowEventLoop.cpp:121) ==196== by 0x13AD46FB: void std::__invoke_impl<void, void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&>(std::__invoke_memfun_deref, void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&) (invoke.h:74) ==196== by 0x13AD4666: std::__invoke_result<void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&>::type std::__invoke<void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&>(void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&) (invoke.h:96) ==196== by 0x13AD45DC: void std::_Bind<void (WebCore::WindowEventLoop::*(WebCore::WindowEventLoop*))()>::__call<void, , 0ul>(std::tuple<>&&, std::_Index_tuple<0ul>) (functional:420) ==196== by 0x13AD456E: void std::_Bind<void (WebCore::WindowEventLoop::*(WebCore::WindowEventLoop*))()>::operator()<, void>() (functional:503) ==196== by 0x13AD4537: WTF::Detail::CallableWrapper<std::_Bind<void (WebCore::WindowEventLoop::*(WebCore::WindowEventLoop*))()>, void>::call() (Function.h:53) ==196== by 0xD99E63C: WTF::Function<void ()>::operator()() const (Function.h:82) ==196== by 0xE23D137: WebCore::Timer::fired() (Timer.h:135) ==196== by 0x146E59EF: WebCore::ThreadTimers::sharedTimerFiredInternal() (ThreadTimers.cpp:127) ==196== by 0x146E52E4: WebCore::ThreadTimers::setSharedTimer(WebCore::SharedTimer*)::{lambda()#1}::operator()() const (ThreadTimers.cpp:67) ==196== by 0x146E8407: WTF::Detail::CallableWrapper<WebCore::ThreadTimers::setSharedTimer(WebCore::SharedTimer*)::{lambda()#1}, void>::call() (Function.h:53) ==196== by 0xD99E63C: WTF::Function<void ()>::operator()() const (Function.h:82) ==196== by 0x14698311: WebCore::MainThreadSharedTimer::fired() (MainThreadSharedTimer.cpp:83) ==196== by 0x146A2E9D: void std::__invoke_impl<void, void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&>(std::__invoke_memfun_deref, void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&) (invoke.h:74) ==196== by 0x146A2E16: std::__invoke_result<void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&>::type std::__invoke<void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&>(void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&) (invoke.h:96) ==196== by 0x146A2D8C: void std::_Bind<void (WebCore::MainThreadSharedTimer::*(WebCore::MainThreadSharedTimer*))()>::__call<void, , 0ul>(std::tuple<>&&, std::_Index_tuple<0ul>) (functional:420) ==196== by 0x146A2D1E: void std::_Bind<void (WebCore::MainThreadSharedTimer::*(WebCore::MainThreadSharedTimer*))()>::operator()<, void>() (functional:503) ==196== by 0x146A2CC7: WTF::Detail::CallableWrapper<std::_Bind<void (WebCore::MainThreadSharedTimer::*(WebCore::MainThreadSharedTimer*))()>, void>::call() (Function.h:53) ==196== by 0xD99E63C: WTF::Function<void ()>::operator()() const (Function.h:82) ==196== by 0x146A2CE7: WTF::RunLoop::Timer<WebCore::MainThreadSharedTimer>::fired() (RunLoop.h:188) ==196== by 0x110196A8: WTF::RunLoop::TimerBase::TimerBase(WTF::RunLoop&)::{lambda(void*)#1}::operator()(void*) const (RunLoopGLib.cpp:177) ==196== by 0x110196E8: WTF::RunLoop::TimerBase::TimerBase(WTF::RunLoop&)::{lambda(void*)#1}::_FUN(void*) (RunLoopGLib.cpp:181) ==196== by 0x11018BFA: WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)#1}::operator()(_GSource*, int (*)(void*), void*) const (RunLoopGLib.cpp:53) ==196== by 0x11018C48: WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)#1}::_FUN(_GSource*, int (*)(void*), void*) (RunLoopGLib.cpp:56) ==196== by 0x15F52293: g_main_dispatch (gmain.c:3381) ==196== by 0x15F52293: g_main_context_dispatch (gmain.c:4099) ==196== by 0x15F52637: g_main_context_iterate.constprop.0 (gmain.c:4175) ==196== by 0x15F52942: g_main_loop_run (gmain.c:4373) ==196== by 0x110192B3: WTF::RunLoop::run() (RunLoopGLib.cpp:108) ==196== by 0xEFB8674: WebKit::AuxiliaryProcessMainBase<WebKit::WebProcess, true>::run(int, char**) (AuxiliaryProcessMain.h:70) ==196== by 0xEFB5D26: int WebKit::AuxiliaryProcessMain<WebKit::WebProcessMainWPE>(int, char**) (AuxiliaryProcessMain.h:96) ==196== by 0xEFB227E: WebKit::WebProcessMain(int, char**) (WebProcessMainWPE.cpp:75) ==196== by 0x109908: main (WebProcessMain.cpp:31) ==196== ==196== 403 (88 direct, 315 indirect) bytes in 1 blocks are definitely lost in loss record 58,282 of 62,411 ==196== at 0x4840899: malloc (vg_replace_malloc.c:381) ==196== by 0x15F58728: g_malloc (gmem.c:106) ==196== by 0x15F710B4: g_slice_alloc (gslice.c:1072) ==196== by 0x16171683: gst_context_new (gstcontext.c:174) ==196== by 0x1122BC0A: requestGLContext(char const*) (GLVideoSinkGStreamer.cpp:160) ==196== by 0x1122BD12: setGLContext(_GstElement*, char const*) (GLVideoSinkGStreamer.cpp:173) ==196== by 0x1122BE5D: webKitGLVideoSinkChangeState(_GstElement*, GstStateChange) (GLVideoSinkGStreamer.cpp:191) ==196== by 0x1617FA11: gst_element_change_state (gstelement.c:3083) ==196== by 0x16180154: gst_element_set_state_func (gstelement.c:3037) ==196== by 0x40651CE6: activate_sink (gstplaybin3.c:3805) ==196== by 0x40651CE6: activate_sink.constprop.0 (gstplaybin3.c:3780) ==196== by 0x40652B3E: activate_group (gstplaybin3.c:4539) ==196== by 0x40652B3E: setup_next_source (gstplaybin3.c:4801) ==196== by 0x406542A7: gst_play_bin3_change_state (gstplaybin3.c:5031) ==196== by 0x1617FA11: gst_element_change_state (gstelement.c:3083) ==196== by 0x1617FA5A: gst_element_change_state (gstelement.c:3122) ==196== by 0x16180154: gst_element_set_state_func (gstelement.c:3037) ==196== by 0x11257BC9: WebCore::MediaPlayerPrivateGStreamer::changePipelineState(GstState) (MediaPlayerPrivateGStreamer.cpp:924) ==196== by 0x11258D8B: WebCore::MediaPlayerPrivateGStreamer::commitLoad() (MediaPlayerPrivateGStreamer.cpp:1184) ==196== by 0x1125420B: WebCore::MediaPlayerPrivateGStreamer::load(WTF::String const&) (MediaPlayerPrivateGStreamer.cpp:354) ==196== by 0x112542F4: WebCore::MediaPlayerPrivateGStreamer::load(WebCore::MediaStreamPrivate&) (MediaPlayerPrivateGStreamer.cpp:370) ==196== by 0x148CF508: WebCore::MediaPlayer::loadWithNextMediaEngine(WebCore::MediaPlayerFactory const*) (MediaPlayer.cpp:646) ==196== by 0x148CED64: WebCore::MediaPlayer::load(WebCore::MediaStreamPrivate&) (MediaPlayer.cpp:549) ==196== by 0x13CF7047: WebCore::HTMLMediaElement::loadResource(WTF::URL const&, WebCore::ContentType&, WTF::String const&) (HTMLMediaElement.cpp:1599) ==196== by 0x13CF5D70: WebCore::HTMLMediaElement::selectMediaResource()::{lambda()#1}::operator()() const (HTMLMediaElement.cpp:1413) ==196== by 0x13D291BD: WTF::Detail::CallableWrapper<WebCore::HTMLMediaElement::selectMediaResource()::{lambda()#1}, void>::call() (Function.h:53) ==196== by 0xD99E63C: WTF::Function<void ()>::operator()() const (Function.h:82) ==196== by 0x131C31E7: WTF::CancellableTask::operator()() (CancellableTask.h:86) ==196== by 0x13D2D2DD: WebCore::ActiveDOMObject::queueCancellableTaskKeepingObjectAlive<WebCore::HTMLMediaElement>(WebCore::HTMLMediaElement&, WebCore::TaskSource, WTF::TaskCancellationGroup&, WTF::Function<void ()>&&)::{lambda()#1}::operator()() (ActiveDOMObject.h:119) ==196== by 0x13D5C88F: WTF::Detail::CallableWrapper<WebCore::ActiveDOMObject::queueCancellableTaskKeepingObjectAlive<WebCore::HTMLMediaElement>(WebCore::HTMLMediaElement&, WebCore::TaskSource, WTF::TaskCancellationGroup&, WTF::Function<void ()>&&)::{lambda()#1}, void>::call() (Function.h:53) ==196== by 0xD99E63C: WTF::Function<void ()>::operator()() const (Function.h:82) ==196== by 0x1399229B: WebCore::EventLoopFunctionDispatchTask::execute() (EventLoop.cpp:159) ==196== by 0x13987D3A: WebCore::EventLoop::run() (EventLoop.cpp:123) ==196== by 0x13ABF15D: WebCore::WindowEventLoop::didReachTimeToRun() (WindowEventLoop.cpp:121) ==196== by 0x13AD46FB: void std::__invoke_impl<void, void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&>(std::__invoke_memfun_deref, void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&) (invoke.h:74) ==196== by 0x13AD4666: std::__invoke_result<void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&>::type std::__invoke<void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&>(void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&) (invoke.h:96) ==196== by 0x13AD45DC: void std::_Bind<void (WebCore::WindowEventLoop::*(WebCore::WindowEventLoop*))()>::__call<void, , 0ul>(std::tuple<>&&, std::_Index_tuple<0ul>) (functional:420) ==196== by 0x13AD456E: void std::_Bind<void (WebCore::WindowEventLoop::*(WebCore::WindowEventLoop*))()>::operator()<, void>() (functional:503) ==196== by 0x13AD4537: WTF::Detail::CallableWrapper<std::_Bind<void (WebCore::WindowEventLoop::*(WebCore::WindowEventLoop*))()>, void>::call() (Function.h:53) ==196== by 0xD99E63C: WTF::Function<void ()>::operator()() const (Function.h:82) ==196== by 0xE23D137: WebCore::Timer::fired() (Timer.h:135) ==196== by 0x146E59EF: WebCore::ThreadTimers::sharedTimerFiredInternal() (ThreadTimers.cpp:127) ==196== by 0x146E52E4: WebCore::ThreadTimers::setSharedTimer(WebCore::SharedTimer*)::{lambda()#1}::operator()() const (ThreadTimers.cpp:67) ==196== by 0x146E8407: WTF::Detail::CallableWrapper<WebCore::ThreadTimers::setSharedTimer(WebCore::SharedTimer*)::{lambda()#1}, void>::call() (Function.h:53) ==196== by 0xD99E63C: WTF::Function<void ()>::operator()() const (Function.h:82) ==196== by 0x14698311: WebCore::MainThreadSharedTimer::fired() (MainThreadSharedTimer.cpp:83) ==196== by 0x146A2E9D: void std::__invoke_impl<void, void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&>(std::__invoke_memfun_deref, void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&) (invoke.h:74) ==196== by 0x146A2E16: std::__invoke_result<void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&>::type std::__invoke<void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&>(void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&) (invoke.h:96) ==196== by 0x146A2D8C: void std::_Bind<void (WebCore::MainThreadSharedTimer::*(WebCore::MainThreadSharedTimer*))()>::__call<void, , 0ul>(std::tuple<>&&, std::_Index_tuple<0ul>) (functional:420) ==196== by 0x146A2D1E: void std::_Bind<void (WebCore::MainThreadSharedTimer::*(WebCore::MainThreadSharedTimer*))()>::operator()<, void>() (functional:503) ==196== by 0x146A2CC7: WTF::Detail::CallableWrapper<std::_Bind<void (WebCore::MainThreadSharedTimer::*(WebCore::MainThreadSharedTimer*))()>, void>::call() (Function.h:53) ==196== by 0xD99E63C: WTF::Function<void ()>::operator()() const (Function.h:82) ==196== by 0x146A2CE7: WTF::RunLoop::Timer<WebCore::MainThreadSharedTimer>::fired() (RunLoop.h:188) ==196== by 0x110196A8: WTF::RunLoop::TimerBase::TimerBase(WTF::RunLoop&)::{lambda(void*)#1}::operator()(void*) const (RunLoopGLib.cpp:177) ==196== by 0x110196E8: WTF::RunLoop::TimerBase::TimerBase(WTF::RunLoop&)::{lambda(void*)#1}::_FUN(void*) (RunLoopGLib.cpp:181) ==196== by 0x11018BFA: WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)#1}::operator()(_GSource*, int (*)(void*), void*) const (RunLoopGLib.cpp:53) ==196== by 0x11018C48: WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)#1}::_FUN(_GSource*, int (*)(void*), void*) (RunLoopGLib.cpp:56) ==196== by 0x15F52293: g_main_dispatch (gmain.c:3381) ==196== by 0x15F52293: g_main_context_dispatch (gmain.c:4099) ==196== by 0x15F52637: g_main_context_iterate.constprop.0 (gmain.c:4175) ==196== by 0x15F52942: g_main_loop_run (gmain.c:4373) ==196== by 0x110192B3: WTF::RunLoop::run() (RunLoopGLib.cpp:108) ==196== by 0xEFB8674: WebKit::AuxiliaryProcessMainBase<WebKit::WebProcess, true>::run(int, char**) (AuxiliaryProcessMain.h:70) ==196== by 0xEFB5D26: int WebKit::AuxiliaryProcessMain<WebKit::WebProcessMainWPE>(int, char**) (AuxiliaryProcessMain.h:96) ==196== by 0xEFB227E: WebKit::WebProcessMain(int, char**) (WebProcessMainWPE.cpp:75) ==196== by 0x109908: main (WebProcessMain.cpp:31) ==196== * Source/WebCore/platform/graphics/gstreamer/GLVideoSinkGStreamer.cpp: (requestGLContext): (setGLContext): Canonical link: https://commits.webkit.org/252340@main

…tureMapperFlags https://bugs.webkit.org/show_bug.cgi?id=242561 Reviewed by Xabier Rodriguez-Calvar. Fixes: ==195== Conditional jump or move depends on uninitialised value(s) ==195== at 0x11429778: WebCore::TextureMapperPlatformLayerBuffer::paintToTextureMapper(WebCore::TextureMapper&, WebCore::FloatRect const&, WebCore::TransformationMatrix const&, float) (TextureMapperPlatformLayerBuffer.cpp:112) ==195== by 0x11403DDD: WebCore::TextureMapperLayer::paintSelf(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:202) ==195== by 0x114042D4: WebCore::TextureMapperLayer::paintSelfAndChildren(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:255) ==195== by 0x114049D4: WebCore::TextureMapperLayer::paintSelfAndChildrenWithReplica(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:319) ==195== by 0x1140683D: WebCore::TextureMapperLayer::paintSelfChildrenReplicaFilterAndMask(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:563) ==195== by 0x11406903: WebCore::TextureMapperLayer::paintRecursive(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:576) ==195== by 0x114046C9: WebCore::TextureMapperLayer::paintSelfAndChildren(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:283) ==195== by 0x114049D4: WebCore::TextureMapperLayer::paintSelfAndChildrenWithReplica(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:319) ==195== by 0x1140683D: WebCore::TextureMapperLayer::paintSelfChildrenReplicaFilterAndMask(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:563) ==195== by 0x11406903: WebCore::TextureMapperLayer::paintRecursive(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:576) ==195== by 0x114046C9: WebCore::TextureMapperLayer::paintSelfAndChildren(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:283) ==195== by 0x114049D4: WebCore::TextureMapperLayer::paintSelfAndChildrenWithReplica(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:319) ==195== by 0x1140683D: WebCore::TextureMapperLayer::paintSelfChildrenReplicaFilterAndMask(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:563) ==195== by 0x11406903: WebCore::TextureMapperLayer::paintRecursive(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:576) ==195== by 0x114046C9: WebCore::TextureMapperLayer::paintSelfAndChildren(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:283) ==195== by 0x114049D4: WebCore::TextureMapperLayer::paintSelfAndChildrenWithReplica(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:319) ==195== by 0x1140683D: WebCore::TextureMapperLayer::paintSelfChildrenReplicaFilterAndMask(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:563) ==195== by 0x11406903: WebCore::TextureMapperLayer::paintRecursive(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:576) ==195== by 0x114046C9: WebCore::TextureMapperLayer::paintSelfAndChildren(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:283) ==195== by 0x114049D4: WebCore::TextureMapperLayer::paintSelfAndChildrenWithReplica(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:319) ==195== by 0x1140683D: WebCore::TextureMapperLayer::paintSelfChildrenReplicaFilterAndMask(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:563) ==195== by 0x11406903: WebCore::TextureMapperLayer::paintRecursive(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:576) ==195== by 0x114046C9: WebCore::TextureMapperLayer::paintSelfAndChildren(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:283) ==195== by 0x114049D4: WebCore::TextureMapperLayer::paintSelfAndChildrenWithReplica(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:319) ==195== by 0x1140683D: WebCore::TextureMapperLayer::paintSelfChildrenReplicaFilterAndMask(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:563) ==195== by 0x11406903: WebCore::TextureMapperLayer::paintRecursive(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:576) ==195== by 0x114046C9: WebCore::TextureMapperLayer::paintSelfAndChildren(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:283) ==195== by 0x114049D4: WebCore::TextureMapperLayer::paintSelfAndChildrenWithReplica(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:319) ==195== by 0x1140683D: WebCore::TextureMapperLayer::paintSelfChildrenReplicaFilterAndMask(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:563) ==195== by 0x11406903: WebCore::TextureMapperLayer::paintRecursive(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:576) ==195== by 0x114046C9: WebCore::TextureMapperLayer::paintSelfAndChildren(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:283) ==195== by 0x114049D4: WebCore::TextureMapperLayer::paintSelfAndChildrenWithReplica(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:319) ==195== by 0x1140683D: WebCore::TextureMapperLayer::paintSelfChildrenReplicaFilterAndMask(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:563) ==195== by 0x11406903: WebCore::TextureMapperLayer::paintRecursive(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:576) ==195== by 0x11403586: WebCore::TextureMapperLayer::paint(WebCore::TextureMapper&) (TextureMapperLayer.cpp:145) ==195== by 0xE6C2F6B: WebKit::CoordinatedGraphicsScene::paintToCurrentGLContext(WebCore::TransformationMatrix const&, WebCore::FloatRect const&, unsigned int) (CoordinatedGraphicsScene.cpp:78) ==195== by 0xE6E47A2: WebKit::ThreadedCompositor::renderLayerTree() (ThreadedCompositor.cpp:240) ==195== by 0xE6E3762: WebKit::ThreadedCompositor::ThreadedCompositor(WebKit::ThreadedCompositor::Client&, WebKit::ThreadedDisplayRefreshMonitor::Client&, unsigned int, WebCore::IntSize const&, float, unsigned int)::{lambda()#1}::operator()() const (ThreadedCompositor.cpp:58) ==195== by 0xE6E83FD: WTF::Detail::CallableWrapper<WebKit::ThreadedCompositor::ThreadedCompositor(WebKit::ThreadedCompositor::Client&, WebKit::ThreadedDisplayRefreshMonitor::Client&, unsigned int, WebCore::IntSize const&, float, unsigned int)::{lambda()#1}, void>::call() (Function.h:53) ==195== by 0xD9D7F1C: WTF::Function<void ()>::operator()() const (Function.h:82) ==195== by 0xE6C660B: WebKit::CompositingRunLoop::updateTimerFired() (CompositingRunLoop.cpp:188) ==195== by 0xE6E33EF: void std::__invoke_impl<void, void (WebKit::CompositingRunLoop::*&)(), WebKit::CompositingRunLoop*&>(std::__invoke_memfun_deref, void (WebKit::CompositingRunLoop::*&)(), WebKit::CompositingRunLoop*&) (invoke.h:74) ==195== by 0xE6E3368: std::__invoke_result<void (WebKit::CompositingRunLoop::*&)(), WebKit::CompositingRunLoop*&>::type std::__invoke<void (WebKit::CompositingRunLoop::*&)(), WebKit::CompositingRunLoop*&>(void (WebKit::CompositingRunLoop::*&)(), WebKit::CompositingRunLoop*&) (invoke.h:96) ==195== by 0xE6E32DE: void std::_Bind<void (WebKit::CompositingRunLoop::*(WebKit::CompositingRunLoop*))()>::__call<void, , 0ul>(std::tuple<>&&, std::_Index_tuple<0ul>) (functional:420) ==195== by 0xE6E3270: void std::_Bind<void (WebKit::CompositingRunLoop::*(WebKit::CompositingRunLoop*))()>::operator()<, void>() (functional:503) ==195== by 0xE6E3219: WTF::Detail::CallableWrapper<std::_Bind<void (WebKit::CompositingRunLoop::*(WebKit::CompositingRunLoop*))()>, void>::call() (Function.h:53) ==195== by 0xD9D7F1C: WTF::Function<void ()>::operator()() const (Function.h:82) ==195== by 0xE6E3239: WTF::RunLoop::Timer<WebKit::CompositingRunLoop>::fired() (RunLoop.h:188) ==195== by 0x1108296A: WTF::RunLoop::TimerBase::TimerBase(WTF::RunLoop&)::{lambda(void*)#1}::operator()(void*) const (RunLoopGLib.cpp:177) ==195== by 0x110829AA: WTF::RunLoop::TimerBase::TimerBase(WTF::RunLoop&)::{lambda(void*)#1}::_FUN(void*) (RunLoopGLib.cpp:181) ==195== by 0x11081EBC: WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)#1}::operator()(_GSource*, int (*)(void*), void*) const (RunLoopGLib.cpp:53) ==195== by 0x11081F0A: WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)#1}::_FUN(_GSource*, int (*)(void*), void*) (RunLoopGLib.cpp:56) ==195== by 0x15FB8293: g_main_dispatch (gmain.c:3381) ==195== by 0x15FB8293: g_main_context_dispatch (gmain.c:4099) ==195== by 0x15FB8637: g_main_context_iterate.constprop.0 (gmain.c:4175) ==195== by 0x15FB8942: g_main_loop_run (gmain.c:4373) ==195== by 0x11082575: WTF::RunLoop::run() (RunLoopGLib.cpp:108) ==195== by 0xE6C5CB2: WebKit::createRunLoop()::{lambda()#1}::operator()() const (CompositingRunLoop.cpp:49) ==195== by 0xE6CADE5: WTF::Detail::CallableWrapper<WebKit::createRunLoop()::{lambda()#1}, void>::call() (Function.h:53) ==195== by 0xD9D7F1C: WTF::Function<void ()>::operator()() const (Function.h:82) ==195== by 0x10FDF034: WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) (Threading.cpp:236) ==195== by 0x1108F1BC: WTF::wtfThreadEntryPoint(void*) (ThreadingPOSIX.cpp:242) ==195== by 0x18A463B9: start_thread (pthread_create.c:481) ==195== by 0x16782952: clone (clone.S:95) ==195== Uninitialised value was created by a heap allocation ==195== at 0x4840899: malloc (vg_replace_malloc.c:381) ==195== by 0x10F92F47: WTF::fastMalloc(unsigned long) (FastMalloc.cpp:232) ==195== by 0x112E0165: WebCore::MediaPlayerPrivateGStreamer::operator new(unsigned long) (MediaPlayerPrivateGStreamer.h:128) ==195== by 0x112E5BB3: std::_MakeUniq<WebCore::MediaPlayerPrivateGStreamer>::__single_object std::make_unique<WebCore::MediaPlayerPrivateGStreamer, WebCore::MediaPlayer*&>(WebCore::MediaPlayer*&) (unique_ptr.h:962) ==195== by 0x112E24B9: decltype(auto) WTF::makeUnique<WebCore::MediaPlayerPrivateGStreamer, WebCore::MediaPlayer*&>(WebCore::MediaPlayer*&) (StdLibExtras.h:540) ==195== by 0x112E2509: WebCore::MediaPlayerFactoryGStreamer::createMediaEnginePlayer(WebCore::MediaPlayer*) const (MediaPlayerPrivateGStreamer.cpp:288) ==195== by 0x149351A3: WebCore::MediaPlayer::loadWithNextMediaEngine(WebCore::MediaPlayerFactory const*) (MediaPlayer.cpp:625) ==195== by 0x14934C7E: WebCore::MediaPlayer::load(WebCore::MediaStreamPrivate&) (MediaPlayer.cpp:549) ==195== by 0x13D5FCA5: WebCore::HTMLMediaElement::loadResource(WTF::URL const&, WebCore::ContentType&, WTF::String const&) (HTMLMediaElement.cpp:1599) ==195== by 0x13D5E9CE: WebCore::HTMLMediaElement::selectMediaResource()::{lambda()#1}::operator()() const (HTMLMediaElement.cpp:1413) ==195== by 0x13D91E1B: WTF::Detail::CallableWrapper<WebCore::HTMLMediaElement::selectMediaResource()::{lambda()#1}, void>::call() (Function.h:53) ==195== by 0xD9D7F1C: WTF::Function<void ()>::operator()() const (Function.h:82) ==195== by 0x1322C265: WTF::CancellableTask::operator()() (CancellableTask.h:86) ==195== by 0x13D95F3B: WebCore::ActiveDOMObject::queueCancellableTaskKeepingObjectAlive<WebCore::HTMLMediaElement>(WebCore::HTMLMediaElement&, WebCore::TaskSource, WTF::TaskCancellationGroup&, WTF::Function<void ()>&&)::{lambda()#1}::operator()() (ActiveDOMObject.h:119) ==195== by 0x13DC54ED: WTF::Detail::CallableWrapper<WebCore::ActiveDOMObject::queueCancellableTaskKeepingObjectAlive<WebCore::HTMLMediaElement>(WebCore::HTMLMediaElement&, WebCore::TaskSource, WTF::TaskCancellationGroup&, WTF::Function<void ()>&&)::{lambda()#1}, void>::call() (Function.h:53) ==195== by 0xD9D7F1C: WTF::Function<void ()>::operator()() const (Function.h:82) ==195== by 0x139FB2B1: WebCore::EventLoopFunctionDispatchTask::execute() (EventLoop.cpp:159) ==195== by 0x139F0D50: WebCore::EventLoop::run() (EventLoop.cpp:123) ==195== by 0x13B2815F: WebCore::WindowEventLoop::didReachTimeToRun() (WindowEventLoop.cpp:121) ==195== by 0x13B3D6FD: void std::__invoke_impl<void, void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&>(std::__invoke_memfun_deref, void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&) (invoke.h:74) ==195== by 0x13B3D668: std::__invoke_result<void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&>::type std::__invoke<void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&>(void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&) (invoke.h:96) ==195== by 0x13B3D5DE: void std::_Bind<void (WebCore::WindowEventLoop::*(WebCore::WindowEventLoop*))()>::__call<void, , 0ul>(std::tuple<>&&, std::_Index_tuple<0ul>) (functional:420) ==195== by 0x13B3D570: void std::_Bind<void (WebCore::WindowEventLoop::*(WebCore::WindowEventLoop*))()>::operator()<, void>() (functional:503) ==195== by 0x13B3D539: WTF::Detail::CallableWrapper<std::_Bind<void (WebCore::WindowEventLoop::*(WebCore::WindowEventLoop*))()>, void>::call() (Function.h:53) ==195== by 0xD9D7F1C: WTF::Function<void ()>::operator()() const (Function.h:82) ==195== by 0xE2769FD: WebCore::Timer::fired() (Timer.h:135) ==195== by 0x1474B909: WebCore::ThreadTimers::sharedTimerFiredInternal() (ThreadTimers.cpp:127) ==195== by 0x1474B1FE: WebCore::ThreadTimers::setSharedTimer(WebCore::SharedTimer*)::{lambda()#1}::operator()() const (ThreadTimers.cpp:67) ==195== by 0x1474E321: WTF::Detail::CallableWrapper<WebCore::ThreadTimers::setSharedTimer(WebCore::SharedTimer*)::{lambda()#1}, void>::call() (Function.h:53) ==195== by 0xD9D7F1C: WTF::Function<void ()>::operator()() const (Function.h:82) ==195== by 0x146FE25D: WebCore::MainThreadSharedTimer::fired() (MainThreadSharedTimer.cpp:83) ==195== by 0x14708DE9: void std::__invoke_impl<void, void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&>(std::__invoke_memfun_deref, void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&) (invoke.h:74) ==195== by 0x14708D62: std::__invoke_result<void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&>::type std::__invoke<void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&>(void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&) (invoke.h:96) ==195== by 0x14708CD8: void std::_Bind<void (WebCore::MainThreadSharedTimer::*(WebCore::MainThreadSharedTimer*))()>::__call<void, , 0ul>(std::tuple<>&&, std::_Index_tuple<0ul>) (functional:420) ==195== by 0x14708C6A: void std::_Bind<void (WebCore::MainThreadSharedTimer::*(WebCore::MainThreadSharedTimer*))()>::operator()<, void>() (functional:503) ==195== by 0x14708C13: WTF::Detail::CallableWrapper<std::_Bind<void (WebCore::MainThreadSharedTimer::*(WebCore::MainThreadSharedTimer*))()>, void>::call() (Function.h:53) ==195== by 0xD9D7F1C: WTF::Function<void ()>::operator()() const (Function.h:82) ==195== by 0x14708C33: WTF::RunLoop::Timer<WebCore::MainThreadSharedTimer>::fired() (RunLoop.h:188) ==195== by 0x1108296A: WTF::RunLoop::TimerBase::TimerBase(WTF::RunLoop&)::{lambda(void*)#1}::operator()(void*) const (RunLoopGLib.cpp:177) ==195== by 0x110829AA: WTF::RunLoop::TimerBase::TimerBase(WTF::RunLoop&)::{lambda(void*)#1}::_FUN(void*) (RunLoopGLib.cpp:181) ==195== by 0x11081EBC: WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)#1}::operator()(_GSource*, int (*)(void*), void*) const (RunLoopGLib.cpp:53) ==195== by 0x11081F0A: WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)#1}::_FUN(_GSource*, int (*)(void*), void*) (RunLoopGLib.cpp:56) ==195== by 0x15FB8293: g_main_dispatch (gmain.c:3381) ==195== by 0x15FB8293: g_main_context_dispatch (gmain.c:4099) ==195== by 0x15FB8637: g_main_context_iterate.constprop.0 (gmain.c:4175) ==195== by 0x15FB8942: g_main_loop_run (gmain.c:4373) ==195== by 0x11082575: WTF::RunLoop::run() (RunLoopGLib.cpp:108) ==195== by 0xF024098: WebKit::AuxiliaryProcessMainBase<WebKit::WebProcess, true>::run(int, char**) (AuxiliaryProcessMain.h:70) ==195== by 0xF02174A: int WebKit::AuxiliaryProcessMain<WebKit::WebProcessMainWPE>(int, char**) (AuxiliaryProcessMain.h:96) ==195== by 0xF01DCA2: WebKit::WebProcessMain(int, char**) (WebProcessMainWPE.cpp:75) ==195== by 0x109918: main (WebProcessMain.cpp:31) ==195== * Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.h: Canonical link: https://commits.webkit.org/252393@main

…us wrapper https://bugs.webkit.org/show_bug.cgi?id=242734 Reviewed by Antti Koivisto. When the anonymous block wrapper for an inline level child is not needed anymore (sibling block is removed or became non-inflow), we 1. detach the inline level child (and its subtree) 2. destroy the anonymous wrapper 3. re-attach the inline level child under the new parent (most likely the parent of the destroyed anonymous wrapper) We call this re-parenting activity an "internal move". Certain properties (e.g fragmentation state) are not supposed to change during this type of move (we simply stop calling some "reset" functions when RenderObject::IsInternalMove::Yes) This patch ensures that the internal move flag is set for both #1 and #3. * Source/WebCore/rendering/RenderBlockFlow.cpp: drive-by fix to ensure no ruby content gets multi-column context. (WebCore::RenderBlockFlow::willCreateColumns const): * Source/WebCore/rendering/updating/RenderTreeBuilder.cpp: (WebCore::RenderTreeBuilder::removeAnonymousWrappersForInlineChildrenIfNeeded): Make sure both detach and attach are covered with the "internal move" flag as currently only the attach is covered. It means that whatever flags we reset at detach (not an internal move) we don't set back on attach (internal move). Canonical link: https://commits.webkit.org/252456@main

https://bugs.webkit.org/show_bug.cgi?id=242517 Reviewed by Darin Adler. We need to initialize processIdentifier as it is accessed by the equality operator for GlobalWindowIdentifier. Fixes the following valgrind error: ==137== Conditional jump or move depends on uninitialised value(s) ==137== at 0x144770C4: WebCore::operator==(WebCore::GlobalWindowIdentifier const&, WebCore::GlobalWindowIdentifier const&) (GlobalWindowIdentifier.h:49) ==137== by 0x1447715D: WTF::GlobalWindowIdentifierHash::equal(WebCore::GlobalWindowIdentifier const&, WebCore::GlobalWindowIdentifier const&) (GlobalWindowIdentifier.h:85) ==137== by 0x1447ACBA: bool WTF::HashMapTranslator<WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::DefaultHash<WebCore::GlobalWindowIdentifier> >::equal<WebCore::GlobalWindowIdentifier, WebCore::GlobalWindowIdentifier>(WebCore::GlobalWindowIdentifier const&, WebCore::GlobalWindowIdentifier const&) (HashMap.h:229) ==137== by 0x1447AAEB: void WTF::HashTable<WebCore::GlobalWindowIdentifier, WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*>, WTF::KeyValuePairKeyExtractor<WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*> >, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::HashTraits<WebCore::GlobalWindowIdentifier> >::checkKey<WTF::HashMapTranslator<WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::DefaultHash<WebCore::GlobalWindowIdentifier> >, WebCore::GlobalWindowIdentifier>(WebCore::GlobalWindowIdentifier const&) (HashTable.h:664) ==137== by 0x14479888: WTF::HashTableAddResult<WTF::HashTableIterator<WTF::HashTable<WebCore::GlobalWindowIdentifier, WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*>, WTF::KeyValuePairKeyExtractor<WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*> >, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::HashTraits<WebCore::GlobalWindowIdentifier> >, WebCore::GlobalWindowIdentifier, WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*>, WTF::KeyValuePairKeyExtractor<WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*> >, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::HashTraits<WebCore::GlobalWindowIdentifier> > > WTF::HashTable<WebCore::GlobalWindowIdentifier, WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*>, WTF::KeyValuePairKeyExtractor<WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*> >, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::HashTraits<WebCore::GlobalWindowIdentifier> >::add<WTF::HashMapTranslator<WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::DefaultHash<WebCore::GlobalWindowIdentifier> >, WebCore::GlobalWindowIdentifier const&, WebCore::AbstractDOMWindow*>(WebCore::GlobalWindowIdentifier const&, WebCore::AbstractDOMWindow*&&) (HashTable.h:932) ==137== by 0x1447895D: WTF::HashTableAddResult<WTF::HashTableIterator<WTF::HashTable<WebCore::GlobalWindowIdentifier, WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*>, WTF::KeyValuePairKeyExtractor<WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*> >, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::HashTraits<WebCore::GlobalWindowIdentifier> >, WebCore::GlobalWindowIdentifier, WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*>, WTF::KeyValuePairKeyExtractor<WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*> >, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::HashTraits<WebCore::GlobalWindowIdentifier> > > WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::inlineAdd<WebCore::GlobalWindowIdentifier const&, WebCore::AbstractDOMWindow*>(WebCore::GlobalWindowIdentifier const&, WebCore::AbstractDOMWindow*&&) (HashMap.h:382) ==137== by 0x1447795B: WTF::HashTableAddResult<WTF::HashTableIterator<WTF::HashTable<WebCore::GlobalWindowIdentifier, WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*>, WTF::KeyValuePairKeyExtractor<WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*> >, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::HashTraits<WebCore::GlobalWindowIdentifier> >, WebCore::GlobalWindowIdentifier, WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*>, WTF::KeyValuePairKeyExtractor<WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*> >, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::HashTraits<WebCore::GlobalWindowIdentifier> > > WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::add<WebCore::AbstractDOMWindow*>(WebCore::GlobalWindowIdentifier const&, WebCore::AbstractDOMWindow*&&) (HashMap.h:417) ==137== by 0x144705B3: WebCore::AbstractDOMWindow::AbstractDOMWindow(WebCore::GlobalWindowIdentifier&&) (AbstractDOMWindow.cpp:48) ==137== by 0x1448AA3C: WebCore::DOMWindow::DOMWindow(WebCore::Document&) (DOMWindow.cpp:405) ==137== by 0x1392F767: WebCore::DOMWindow::create(WebCore::Document&) (DOMWindow.h:124) ==137== by 0x139026F1: WebCore::Document::createDOMWindow() (Document.cpp:5119) ==137== by 0x142DD1B7: WebCore::DocumentWriter::begin(WTF::URL const&, bool, WebCore::Document*, WebCore::ProcessQualified<WTF::UUID>)::{lambda()#1}::operator()() const (DocumentWriter.cpp:165) ==137== by 0x142E61DB: WTF::Detail::CallableWrapper<WebCore::DocumentWriter::begin(WTF::URL const&, bool, WebCore::Document*, WebCore::ProcessQualified<WTF::UUID>)::{lambda()#1}, void>::call() (Function.h:53) ==137== by 0xD9D5E94: WTF::Function<void ()>::operator()() const (Function.h:82) ==137== by 0x1431A333: WebCore::FrameLoader::clear(WTF::RefPtr<WebCore::Document, WTF::RawPtrTraits<WebCore::Document>, WTF::DefaultRefDerefTraits<WebCore::Document> >&&, bool, bool, bool, WTF::Function<void ()>&&) (FrameLoader.cpp:646) ==137== by 0x142DD5B1: WebCore::DocumentWriter::begin(WTF::URL const&, bool, WebCore::Document*, WebCore::ProcessQualified<WTF::UUID>) (DocumentWriter.cpp:168) ==137== by 0x142D05BB: WebCore::DocumentLoader::commitData(WebCore::SharedBuffer const&) (DocumentLoader.cpp:1235) ==137== by 0x142CAE8C: WebCore::DocumentLoader::finishedLoading() (DocumentLoader.cpp:493) ==137== by 0x142D44AA: WebCore::DocumentLoader::maybeLoadEmpty() (DocumentLoader.cpp:2038) ==137== by 0x142D4D93: WebCore::DocumentLoader::startLoadingMainResource() (DocumentLoader.cpp:2065) ==137== by 0x143188E2: WebCore::FrameLoader::init() (FrameLoader.cpp:351) ==137== by 0x144DB8BF: WebCore::Frame::init() (Frame.cpp:192) ==137== by 0xEFD71C5: WebKit::WebFrame::initWithCoreMainFrame(WebKit::WebPage&, WebCore::Frame&) (WebFrame.cpp:115) ==137== by 0xEF7CECD: WebKit::WebPage::WebPage(WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters&&) (WebPage.cpp:721) ==137== by 0xEF7B307: WebKit::WebPage::create(WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters&&) (WebPage.cpp:461) ==137== by 0xECA85C2: WebKit::WebProcess::createWebPage(WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters&&) (WebProcess.cpp:837) ==137== by 0xDEB4991: void IPC::callMemberFunctionImpl<WebKit::WebProcess, void (WebKit::WebProcess::*)(WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters&&), std::tuple<WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters>, 0ul, 1ul>(WebKit::WebProcess*, void (WebKit::WebProcess::*)(WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters&&), std::tuple<WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters>&&, std::integer_sequence<unsigned long, 0ul, 1ul>) (HandleMessage.h:131) ==137== by 0xDEB1B6F: void IPC::callMemberFunction<WebKit::WebProcess, void (WebKit::WebProcess::*)(WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters&&), std::tuple<WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters>, std::integer_sequence<unsigned long, 0ul, 1ul> >(std::tuple<WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters>&&, WebKit::WebProcess*, void (WebKit::WebProcess::*)(WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters&&)) (HandleMessage.h:137) ==137== by 0xDEACC26: void IPC::handleMessage<Messages::WebProcess::CreateWebPage, WebKit::WebProcess, void (WebKit::WebProcess::*)(WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters&&)>(IPC::Connection&, IPC::Decoder&, WebKit::WebProcess*, void (WebKit::WebProcess::*)(WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters&&)) (HandleMessage.h:259) ==137== by 0xDEAA311: WebKit::WebProcess::didReceiveWebProcessMessage(IPC::Connection&, IPC::Decoder&) (WebProcessMessageReceiver.cpp:280) ==137== by 0xECA8AA3: WebKit::WebProcess::didReceiveMessage(IPC::Connection&, IPC::Decoder&) (WebProcess.cpp:916) ==137== by 0xE58AFE3: IPC::Connection::dispatchMessage(IPC::Decoder&) (Connection.cpp:1108) ==137== by 0xE58B27A: IPC::Connection::dispatchMessage(std::unique_ptr<IPC::Decoder, std::default_delete<IPC::Decoder> >) (Connection.cpp:1153) ==137== by 0xE58B821: IPC::Connection::dispatchOneIncomingMessage() (Connection.cpp:1222) ==137== by 0xE58ACF3: IPC::Connection::enqueueIncomingMessage(std::unique_ptr<IPC::Decoder, std::default_delete<IPC::Decoder> >)::{lambda()#1}::operator()() (Connection.cpp:1072) ==137== by 0xE591DD7: WTF::Detail::CallableWrapper<IPC::Connection::enqueueIncomingMessage(std::unique_ptr<IPC::Decoder, std::default_delete<IPC::Decoder> >)::{lambda()#1}, void>::call() (Function.h:53) ==137== by 0xD9D5E94: WTF::Function<void ()>::operator()() const (Function.h:82) ==137== by 0x10FD4BEE: WTF::RunLoop::performWork() (RunLoop.cpp:133) ==137== by 0x110803FD: WTF::RunLoop::RunLoop()::{lambda(void*)#1}::operator()(void*) const (RunLoopGLib.cpp:80) ==137== by 0x11080421: WTF::RunLoop::RunLoop()::{lambda(void*)#1}::_FUN(void*) (RunLoopGLib.cpp:82) ==137== by 0x11080390: WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)#1}::operator()(_GSource*, int (*)(void*), void*) const (RunLoopGLib.cpp:53) ==137== by 0x110803DE: WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)#1}::_FUN(_GSource*, int (*)(void*), void*) (RunLoopGLib.cpp:56) ==137== by 0x15FB4293: g_main_dispatch (gmain.c:3381) ==137== by 0x15FB4293: g_main_context_dispatch (gmain.c:4099) ==137== by 0x15FB4637: g_main_context_iterate.constprop.0 (gmain.c:4175) ==137== by 0x15FB4942: g_main_loop_run (gmain.c:4373) ==137== by 0x11080A49: WTF::RunLoop::run() (RunLoopGLib.cpp:108) ==137== by 0xF022010: WebKit::AuxiliaryProcessMainBase<WebKit::WebProcess, true>::run(int, char**) (AuxiliaryProcessMain.h:70) ==137== by 0xF01F6C2: int WebKit::AuxiliaryProcessMain<WebKit::WebProcessMainWPE>(int, char**) (AuxiliaryProcessMain.h:96) ==137== by 0xF01BC1A: WebKit::WebProcessMain(int, char**) (WebProcessMainWPE.cpp:75) ==137== by 0x109918: main (WebProcessMain.cpp:31) ==137== Uninitialised value was created by a stack allocation ==137== at 0x1447AA1A: void WTF::HashTable<WebCore::GlobalWindowIdentifier, WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*>, WTF::KeyValuePairKeyExtractor<WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*> >, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::HashTraits<WebCore::GlobalWindowIdentifier> >::checkKey<WTF::HashMapTranslator<WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::DefaultHash<WebCore::GlobalWindowIdentifier> >, WebCore::GlobalWindowIdentifier>(WebCore::GlobalWindowIdentifier const&) (HashTable.h:655) ==137== * Source/WebCore/page/GlobalWindowIdentifier.h: (WTF::HashTraits<WebCore::GlobalWindowIdentifier>::constructDeletedValue): Canonical link: https://commits.webkit.org/252473@main

…ing-navigations-and-traversals/tentative/forward-to-pruned-entry.html is flaky https://bugs.webkit.org/show_bug.cgi?id=243518 <rdar://98082718> Reviewed by Geoffrey Garen. The test calls `history.forward()` which determines that the next HistoryItem is #1 and schedules a navigation to #1. The test then does a synchronous fragment navigation, which prunes the forward HistoryItem from the back/forward list. When the attempt to navigate to HistoryItem #1 in the async task, it should no longer be part of the back/forward and thus no navigation should happen. The navigation to #1 was happening in WebKit however and this was causing the test to be flaky (since the test checks on a timer to see if the navigation to #1 happened or not). WebKit was trying to deal with this by checking BackForwardController::containsItem() in ScheduledHistoryNavigation::fire() and aborting if the BackForwardController no longer contains the HistoryItem. However, in the WebKit2 implementation, the Back / Forward list lives in the UIProcess and WebBackForwardListProxy::containsItem() was failing to ask the UIProcess. Instead, it was relying on the idToHistoryItemMap() map on the WebProcess side. The issue with this is that the map only gets updated asynchronously via IPC from the UIProcess. In the context of the test, we may not have received this IPC from the UIProcess yet when the ScheduledHistoryNavigation fires since the navigation that pruned the HistoryItem was a synchronous fragment navigation. To address the issue, I updated ebBackForwardListProxy::containsItem() to ask the UIProcess instead of relying on idToHistoryItemMap(), for better reliability. * Source/WebKit/UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::backForwardListContainsItem): * Source/WebKit/UIProcess/WebPageProxy.h: * Source/WebKit/UIProcess/WebPageProxy.messages.in: * Source/WebKit/WebProcess/WebPage/WebBackForwardListProxy.cpp: (WebKit::WebBackForwardListProxy::containsItem const): Canonical link: https://commits.webkit.org/253121@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=249765 rdar://103631099 Reviewed by Mark Lam. In ARM64, we are leveraging LDR style address, which can take 32bit index in addressing and zero-extend / sign-extend that in load/store. This is useful since WasmAddress' index is 32bit and we need to zero-extend it. However, we cannot use this addressing when there is an offset since this addressing cannot encode offset. As a result, we are emitting Move32 and Add64 when there is an offset. However, ARM64 can do even better for that case since ARM64 add / sub instructions also support LDR style extension. This patch adds AddZeroExtend64 and AddSignExtend64. They take 32bit second operand and extend it before adding. This is particularly useful when computing WasmAddress. We also leverage this in AirIRGenerator. In the added testb3, the generated code is changed as follows. Before: O2: testWasmAddressWithOffset()... Generated JIT code for Compilation: Code at [0x115f74980, 0x115f749a0): <0> 0x115f74980: pacibsp <4> 0x115f74984: stp fp, lr, [sp, #-16]! <8> 0x115f74988: mov fp, sp <12> 0x115f7498c: ubfx x0, x0, #0, #32; emitSave <16> 0x115f74990: add x0, x2, x0 <20> 0x115f74994: sturb w1, [x0, #1] <24> 0x115f74998: ldp fp, lr, [sp], #16 <28> 0x115f7499c: retab After: O2: testWasmAddressWithOffset()... Generated JIT code for Compilation: Code at [0x121108980, 0x1211089a0): <0> 0x121108980: pacibsp <4> 0x121108984: stp fp, lr, [sp, #-16]! <8> 0x121108988: mov fp, sp <12> 0x12110898c: add x0, x2, w0, uxtw; emitSave <16> 0x121108990: sturb w1, [x0, #1] <20> 0x121108994: ldp fp, lr, [sp], #16 <24> 0x121108998: retab * Source/JavaScriptCore/assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::addZeroExtend64): (JSC::MacroAssemblerARM64::addSignExtend64): * Source/JavaScriptCore/b3/B3LowerToAir.cpp: * Source/JavaScriptCore/b3/air/AirInstInlines.h: (JSC::B3::Air::isAddZeroExtend64Valid): (JSC::B3::Air::isAddSignExtend64Valid): * Source/JavaScriptCore/b3/air/AirOpcode.opcodes: Canonical link: https://commits.webkit.org/258259@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=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=255872 rdar://108738795 Reviewed by Darin Adler. It turns out that JSON, HTTP, and XML all use the same whitespace definition, so let's make them share it. Also correct an existing comment for that function as \v is not part of isASCIIWhitespace(), but \f is. Furthermore, remove the "optimization" from these whitespace functions per a comment from Chris Dumez at WebKit#13080 (comment): > Just verified out of curiosity and llvm does generate the same code > with -O2 (tried both arm64 and x86_64): > > isXMLSpace1(char): // @isXMLSpace1(char) > mov x8, WebKit#9728 // =0x2600 > and w9, w0, #0xff > movk x8, #1, lsl #32 > cmp w9, #33 > cset w9, lo > lsr x8, x8, x0 > and w0, w9, w8 > ret > isXMLSpace2(char): // @isXMLSpace2(char) > mov x8, WebKit#9728 // =0x2600 > and w9, w0, #0xff > movk x8, #1, lsl #32 > cmp w9, #33 > cset w9, lo > lsr x8, x8, x0 > and w0, w9, w8 > ret > > Ahmad-S792 Let's simplify the code then. * Source/WTF/wtf/ASCIICType.h: (WTF::isASCIIWhitespace): (WTF::isJSONOrHTTPOrXMLWhitespace): (WTF::isJSONOrHTTPWhitespace): Deleted. * Source/WTF/wtf/JSONValues.cpp: (WTF::JSONImpl::Value::parseJSON): * Source/WTF/wtf/text/StringToIntegerConversion.h: * Source/WebCore/Modules/cache/DOMCache.cpp: (WebCore::hasResponseVaryStarHeaderValue): * Source/WebCore/Modules/cache/DOMCacheEngine.cpp: (WebCore::DOMCacheEngine::queryCacheMatch): * Source/WebCore/Modules/fetch/FetchBodyConsumer.cpp: (WebCore::parseParameters): (WebCore::parseMIMEType): (WebCore::FetchBodyConsumer::packageFormData): * Source/WebCore/Modules/fetch/FetchHeaders.cpp: (WebCore::canWriteHeader): (WebCore::appendToHeaderMap): (WebCore::FetchHeaders::set): (WebCore::FetchHeaders::filterAndFill): * Source/WebCore/mathml/MathMLPresentationElement.cpp: (WebCore::MathMLPresentationElement::parseMathMLLength): * Source/WebCore/mathml/MathMLTokenElement.cpp: (WebCore::MathMLTokenElement::convertToSingleCodePoint): * Source/WebCore/page/csp/ContentSecurityPolicyDirectiveList.cpp: (WebCore::ContentSecurityPolicyDirectiveList::parse): * Source/WebCore/platform/ReferrerPolicy.cpp: (WebCore::parseReferrerPolicy): * Source/WebCore/platform/network/DataURLDecoder.cpp: (WebCore::DataURLDecoder::DecodeTask::process): * Source/WebCore/platform/network/HTTPParsers.cpp: (WebCore::parseContentTypeOptionsHeader): (WebCore::parseClearSiteDataHeader): (WebCore::parseRange): (WebCore::parseCrossOriginResourcePolicyHeader): * Source/WebCore/platform/network/HTTPParsers.h: (WebCore::addToAccessControlAllowList): * Source/WebCore/platform/network/ParsedContentType.cpp: (WebCore::skipSpaces): (WebCore::parseToken): (WebCore::ParsedContentType::create): (WebCore::ParsedContentType::setContentType): * Source/WebCore/platform/network/ResourceResponseBase.cpp: (WebCore::ResourceResponseBase::containsInvalidHTTPHeaders const): * Source/WebCore/platform/network/TimingAllowOrigin.cpp: (WebCore::passesTimingAllowOriginCheck): * Source/WebCore/xml/XMLHttpRequest.cpp: (WebCore::XMLHttpRequest::setRequestHeader): * Source/WebCore/xml/XPathFunctions.cpp: (WebCore::XPath::FunNormalizeSpace::evaluate const): * Source/WebCore/xml/XPathParser.cpp: (WebCore::XPath::Parser::skipWS): * Source/WebCore/xml/XPathUtil.cpp: (WebCore::XPath::isXMLSpace): Deleted. * Source/WebCore/xml/XPathUtil.h: * Source/WebKit/NetworkProcess/cache/CacheStorageEngineCache.cpp: (WebKit::CacheStorage::updateVaryInformation): * Source/WebKit/NetworkProcess/soup/WebSocketTaskSoup.cpp: (WebKit::WebSocketTask::WebSocketTask): * Source/WebKit/NetworkProcess/storage/CacheStorageRecord.h: (WebKit::CacheStorageRecordInformation::updateVaryHeaders): * Source/WebKit/WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::shouldSkipDecidePolicyForResponse const): Canonical link: https://commits.webkit.org/266253@main

https://bugs.webkit.org/show_bug.cgi?id=266153 Reviewed by Antti Koivisto. This patch adds support for "ruby-align: space-around" on both bidi and non-bidi content. "ruby-align: space-around" consists of 2 adjustments at run level. - run spacing at justification opportunities (similar to text-align: justify) - content offsetting to distribute one extra justification opportunity space before/after base content In this patch we start computing the offset values at step #1 and pass them over to InlineContentBuilder where the final ruby processing happens (using visual order). InlineContentAligner takes these offset values and adjusts (aligns) the display boxes accordingly. What makes it a bit more verbose is the fact that while non-bidi base runs have the correct spacing (e.g. when annotation is wider than the base), we lose that information at visual reordering (<- we essentially have a fast path for non-bidi content, where as we build the Line for line breaking we also compute horizontal content positions) It simply means that while non-bidi content, offsetting means just moving content inside the base without pushing adjacent content/expanding enclosing inline boxes, bidi content needs both (see AdjustContentOnlyInsideRubyBase). * Source/WebCore/layout/formattingContexts/inline/InlineContentAligner.cpp: (WebCore::Layout::shiftDisplayBox): (WebCore::Layout::expandInlineBox): (WebCore::Layout::alignmentOffset): (WebCore::Layout::expandInlineBoxWithDescendants): (WebCore::Layout::shiftRubyBaseContentByAlignmentOffset): (WebCore::Layout::InlineContentAligner::applyRubyAlignSpaceAround): (WebCore::Layout::InlineContentAligner::applyRubyBaseAlignmentOffset): (WebCore::Layout::InlineContentAligner::applyRubyAlign): Deleted. * Source/WebCore/layout/formattingContexts/inline/InlineContentAligner.h: * Source/WebCore/layout/formattingContexts/inline/InlineLine.h: * Source/WebCore/layout/formattingContexts/inline/InlineLineBuilder.cpp: (WebCore::Layout::LineBuilder::layoutInlineContent): * Source/WebCore/layout/formattingContexts/inline/LineLayoutResult.h: * Source/WebCore/layout/formattingContexts/inline/TextOnlySimpleLineBuilder.cpp: (WebCore::Layout::TextOnlySimpleLineBuilder::layoutInlineContent): * Source/WebCore/layout/formattingContexts/inline/display/InlineDisplayContentBuilder.cpp: (WebCore::Layout::InlineDisplayContentBuilder::build): (WebCore::Layout::InlineDisplayContentBuilder::processRubyContent): * Source/WebCore/layout/formattingContexts/inline/display/InlineDisplayContentBuilder.h: * Source/WebCore/layout/formattingContexts/inline/ruby/RubyFormattingContext.cpp: (WebCore::Layout::RubyFormattingContext::applyRubyAlignOnBaseContent): (WebCore::Layout::RubyFormattingContext::applyRubyAlign): (WebCore::Layout::RubyFormattingContext::applyAlignmentOffsetList): (WebCore::Layout::applyRubyAlignOnBaseContent): Deleted. * Source/WebCore/layout/formattingContexts/inline/ruby/RubyFormattingContext.h: Canonical link: https://commits.webkit.org/271836@main

https://bugs.webkit.org/show_bug.cgi?id=272292 Reviewed by Antti Koivisto. 1. In some cases (e.g. pseudo content) a subtree root gets detached first followed by the descendant renderers 2. Repaint functions start with traversing all the way to the RenderView just to check if dispatching repaint is safe -which in most cases comes back true (normal at-layout repaint, invalidation, standard tree teardown) This patch fixes a correctness and a performance issue: correctness: In case of #1, when calling willBeRemovedFromTree() (right before deleting the descendant renderer), the renderer is already detached from the render tree. It is still attached to the root of the subtree (which is already detached), but has no access to the rest of the render tree (i.e. willBeRemovedFromTree is technically just willBeRemovedFromParent) performance: ensuring correctness eliminates the need for checking if the renderer is still attached. (Sadly ::imageChanged gets called indirectly through initializeStyle before the initial attach) * Source/WebCore/rendering/RenderObject.cpp: (WebCore::RenderObject::repaint const): Use isDescendantOf instead of isRooted() as I am planning on completely remove isRooted(). (WebCore::RenderObject::repaintRectangle const): (WebCore::RenderObject::repaintSlowRepaintObject const): * Source/WebCore/rendering/updating/RenderTreeBuilder.cpp: (WebCore::RenderTreeBuilder::destroy): (WebCore::RenderTreeBuilder::detachFromRenderElement): * Source/WebCore/rendering/updating/RenderTreeBuilder.h: Canonical link: https://commits.webkit.org/277186@main

…n addFloatsToNewParent https://bugs.webkit.org/show_bug.cgi?id=290898 <rdar://143296265> Reviewed by Antti Koivisto. In this patch 1. we let m_floatingObjects go stale on the skipped root (we already do that for the skipped subtree by not running layout) 2. we descend into skipped subtrees while cleaning up floats even when m_floatingObjects is stale/empty Having up-to-date m_floatingObjects on the skipped root, while stale m_floatingObjects on the skipped subtree can lead to issues when (#1) a previously intrusive float (#2) becomes non-intrusive and (#3) eventually gets deleted prevents us from being able to cleanup m_floatingObjects in skipped subtree(s). at #1 m_floatingObjects is populated with the intrusive float (both skipped root and renderers in skipped subtree) and at #2 since we only run layout on the skipped root, m_floatingObjects gets updated by removing this previously intrusive float (skipped subtree becomes stale) and at #3 we don't descend into the skipped subtree to cleanup m_floatingObjects since the skipped root does not have this float anymore (removed at #2). * Source/WebCore/rendering/RenderBlockFlow.cpp: (WebCore::RenderBlockFlow::markSiblingsWithFloatsForLayout): Canonical link: https://commits.webkit.org/293119@main

…n addFloatsToNewParent https://bugs.webkit.org/show_bug.cgi?id=290898 <rdar://149579273> Reviewed by Antti Koivisto. In this patch 1. we let m_floatingObjects go stale on the skipped root (we already do that for the skipped subtree by not running layout) 2. we descend into skipped subtrees while cleaning up floats even when m_floatingObjects is stale/empty Having up-to-date m_floatingObjects on the skipped root, while stale m_floatingObjects on the skipped subtree can lead to issues when (#1) a previously intrusive float (#2) becomes non-intrusive and (#3) eventually gets deleted prevents us from being able to cleanup m_floatingObjects in skipped subtree(s). at #1 m_floatingObjects is populated with the intrusive float (both skipped root and renderers in skipped subtree) and at #2 since we only run layout on the skipped root, m_floatingObjects gets updated by removing this previously intrusive float (skipped subtree becomes stale) and at #3 we don't descend into the skipped subtree to cleanup m_floatingObjects since the skipped root does not have this float anymore (removed at #2). * Source/WebCore/rendering/RenderBlockFlow.cpp: (WebCore::RenderBlockFlow::markSiblingsWithFloatsForLayout): Canonical link: https://commits.webkit.org/293889@main

…rsor smoothly rdar://148762897 https://bugs.webkit.org/show_bug.cgi?id=292042 Reviewed by Devin Rousso. This is a combination of two issues: 1. If the WKInspectorWKWebView has safeAreaInsets set and therefore _obscuredContentInsets configured, adjusting its dimensions does not take that into account. Assuming there is a left inset configured to be X and the new docked inspector width requested by the frontend is W, the frontend is not aware of the extra X pixels needed when rendering the WKInspectorWKWebView (because the frontend lives inside that web view), which then needs to be (W + X) pixels wide instead. 2. The setAttachedWindowHeight/Width commands in the backend take an `unsigned int` as the new dimension's type, but the frontend computes in floating point (JavaScript's Number), which always gets rounded down when the new dimension gets passed in and coerced to an int. This makes the new view just slightly smaller than required over the course of dragging. * Source/WebKit/UIProcess/Inspector/mac/WebInspectorUIProxyMac.mm: (WebKit::WebInspectorUIProxy::platformSetAttachedWindowHeight): (WebKit::WebInspectorUIProxy::platformSetAttachedWindowWidth): - Fix issue #1. * Source/WebInspectorUI/UserInterface/Base/Main.js: - Fix issue #2. - Adding the rounding on resulting dimension alone was sufficient to fix the "always-shrinking" bug. However, resizing still didn't feel completely smooth; the inspector wouldn't shrink by itself, but it still felt like having some lag following the moving cursor. I took a simpler approach to compute the delta, where we use the original dimension as the standard instead of the last frame, which turns out to be extremely smooth and exactly what we wanted. Tested the fix manually on various inspector zoom factors from 60% to 240%, combined with or without an _obscuredContentInsets applied on the WKInspectorWKWebView. Canonical link: https://commits.webkit.org/294123@main

https://bugs.webkit.org/show_bug.cgi?id=293470 Reviewed by Antti Koivisto. 1. In WebKit, column spanners are moved out of their original insertion position and get reparented under the column container. 2. "is this renderer inside a skipped subtree" logic consults parent state. Now the parent of a column spanner (#1) may be completely outside of 'c-v: h' tricking us into believing the spanner is not hidden. * LayoutTests/imported/w3c/web-platform-tests/css/css-contain/content-visibility/content-visibility-hidden-with-column-spanner-expected.html: Added. * LayoutTests/imported/w3c/web-platform-tests/css/css-contain/content-visibility/content-visibility-hidden-with-column-spanner-ref.html: Added. * LayoutTests/imported/w3c/web-platform-tests/css/css-contain/content-visibility/content-visibility-hidden-with-column-spanner.html: Added. * Source/WebCore/rendering/RenderBlock.cpp: (WebCore::RenderBlock::paintChild): * Source/WebCore/rendering/RenderBlockFlow.cpp: (WebCore::RenderBlockFlow::layoutBlockChildren): * Source/WebCore/rendering/RenderBox.h: * Source/WebCore/rendering/RenderBoxInlines.h: (WebCore::RenderBox::isColumnSpanner const): * Source/WebCore/rendering/RenderObject.cpp: (WebCore::RenderObject::isSkippedContent const): Canonical link: https://commits.webkit.org/295335@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

…ht (005,007) and table-alignment-003 and 005 https://bugs.webkit.org/show_bug.cgi?id=296852 Reviewed by Antti Koivisto. 1. lastLineLogicalBaseline should return a value relative to the logical top of the box even when the box's lines are inverted (vertical-lr). This ensures that any baseline function simply returns the distance from the logical top, regardless of the writing mode. 2. Collapse lastLinePhysicalBaseline and lastLineLogicalBaseline into one function and call it lastLineBaseline (and also rename firstLinePhysicalBaseline to firstLineBaseline) 3. When IFC takes a box's baseline right before running inline layout, flip it over for inverted lines when applicable (this is what we used to do at #1). * LayoutTests/TestExpectations: * LayoutTests/fast/text/emphasis-overlap-expected.txt: * LayoutTests/fast/writing-mode/flipped-blocks-inline-map-local-to-container-expected.html: * LayoutTests/fast/writing-mode/flipped-blocks-inline-map-local-to-container.html: * Source/WebCore/layout/integration/LayoutIntegrationBoxGeometryUpdater.cpp: (WebCore::LayoutIntegration::baselineForBox): (WebCore::LayoutIntegration::setIntegrationBaseline): * Source/WebCore/layout/integration/inline/LayoutIntegrationLineLayout.cpp: (WebCore::LayoutIntegration::LineLayout::firstLineBaseline const): (WebCore::LayoutIntegration::LineLayout::lastLineBaseline const): (WebCore::LayoutIntegration::LineLayout::baselineForLine const): (WebCore::LayoutIntegration::LineLayout::firstLinePhysicalBaseline const): Deleted. (WebCore::LayoutIntegration::LineLayout::lastLinePhysicalBaseline const): Deleted. (WebCore::LayoutIntegration::LineLayout::physicalBaselineForLine const): Deleted. (WebCore::LayoutIntegration::LineLayout::lastLineLogicalBaseline const): Deleted. * Source/WebCore/layout/integration/inline/LayoutIntegrationLineLayout.h: * Source/WebCore/rendering/RenderBlockFlow.cpp: (WebCore::RenderBlockFlow::firstLineBaseline const): (WebCore::RenderBlockFlow::lastLineBaseline const): Canonical link: https://commits.webkit.org/298236@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

rdar://161694748 https://bugs.webkit.org/show_bug.cgi?id=299920 Reviewed by Ryosuke Niwa. Prior to this patch, DocumentInlines.h was the most expensive header used in WebCore; it is included 303 times in a WebCore Unified build, and on this machine, each include of that file too the compile on average 1.5s to parse, for a total of 8m CPU minutes of time spent parsing this header. To diagnose why this header is so expensive, I commented out all the implementations from the body of this header and ran a compile, collecting a list of all the errors encountered. I then collected the counts of each error message, and grouped liked errors together. It became clear that most uses of DocumentInlines.h were to pull in a very narrow set of inlined methods, but to get those few methods had to include a very large and very heavy header. To address this, DocumentInlines.h was broken up into separate headers, each which includes only Document.h and one or two other headers. Usually the second header was required to define the return type of the method, and the type definition is required because the return type is a CheckedPtr or RefPtr. However because the return value is typically used at the call site, that return value header would have been included already, meaning this style of header has zero effective additional cost. The files were created in descending order of the number of uses: - DocumentView.h - 187 - DocumentPage.h - 175 - DocumentQuirks.h - 84 - DocumentSecurityOrigin.h - 54 - DocumentResourceLoader.h - 49 - DocumentMarkers.h - 27 - DocumentEventLoop.h - 26 - DocumentSettingsValues.h - 23 - DocumentWindow.h - 19 The remaining grab-bag of inlined methods had less than 10 uses each and were left in DocumentInlines.h. After this patch, DocumentInlines.h is used in just over 100 implementation files and no headers. None of the new Document*.h headers or DocumentInlines.h appear in the top 100 most expensive header files. DocumentInlines.h dropped from the #1 most expensive header taking 8m to parse to #389 and 5.7s of parsing. The most expensive new header is DocumentPage.h at #124 and 25s of parsing. Canonical link: https://commits.webkit.org/300989@main

https://bugs.webkit.org/show_bug.cgi?id=304917 rdar://167529315 Reviewed by Marcus Plutowski. This patch implements chain of compare with ARM64 ccmp / ccmn. Let's say, if (x0 == 0 && x1 == 1) { // target-block } Then this will be compiled via LLVM into wasm. And this will create BitAnd(Equal(a, 0), Equal(b, 1)). Then ARM64 ccmp can handle it as follows. cmp x0, #0 ccmp x1, #1, #0, eq // cmp x1, #1 when flag is eq and override, otherwise set #0 to flag b.eq target-block This reduces small weird basic blocks and reduces prediction miss, and reduces code size. We introduce CompareOnFlags, CompareConditionallyOnFlags, and BranchOnFlags Air opcodes. All of them are annotated as /effects since this relies on the current flag, and they are not producing register output while it has side effects. This ensures that we are not removing these instructions, and we are not hoisting etc. randomly. We introduced V8's compare chain detection mechanism and using it for chained cmp code generation. Tests: Source/JavaScriptCore/b3/testb3_1.cpp Source/JavaScriptCore/b3/testb3_8.cpp * Source/JavaScriptCore/assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::compareOnFlags32): (JSC::MacroAssemblerARM64::compareOnFlags64): (JSC::MacroAssemblerARM64::compareOnFlagsFloat): (JSC::MacroAssemblerARM64::compareOnFlagsDouble): (JSC::MacroAssemblerARM64::compareConditionallyOnFlags32): (JSC::MacroAssemblerARM64::compareConditionallyOnFlags64): (JSC::MacroAssemblerARM64::compareConditionallyOnFlagsFloat): (JSC::MacroAssemblerARM64::compareConditionallyOnFlagsDouble): (JSC::MacroAssemblerARM64::branchOnFlags): * Source/JavaScriptCore/b3/B3LowerToAir.cpp: * Source/JavaScriptCore/b3/air/AirOpcode.opcodes: * Source/JavaScriptCore/b3/air/AirOptimizeBlockOrder.cpp: (JSC::B3::Air::optimizeBlockOrder): * Source/JavaScriptCore/b3/testb3.h: * Source/JavaScriptCore/b3/testb3_1.cpp: (run): * Source/JavaScriptCore/b3/testb3_8.cpp: (testCCmpAnd32): (testCCmpAnd64): (testCCmpOr32): (testCCmpOr64): (testCCmpAndAnd32): (testCCmpOrOr32): (testCCmpAndOr32): (testCCmnAnd32WithNegativeImm): (testCCmnAnd64WithNegativeImm): (testCCmpWithLargePositiveImm): (testCCmpWithLargeNegativeImm): (testCCmpSmartOperandOrdering32): (testCCmpSmartOperandOrdering64): (testCCmpOperandCommutation32): (testCCmpOperandCommutation64): (testCCmpCombinedOptimizations): (testCCmpZeroRegisterOptimization32): (testCCmpZeroRegisterOptimization64): (testCCmpMixedAndOr32): (testCCmpMixedOrAnd32): (testCCmpNegatedAnd32): (testCCmpNegatedOr32): (testCCmpMixedWidth32And64): (testCCmpMixedWidth64And32): Canonical link: https://commits.webkit.org/305493@main

https://bugs.webkit.org/show_bug.cgi?id=313931 Reviewed by Sihui Liu. If a request was being completed when stop() was called, we weren't explicitly cleaning it up and running it's completion handlers. Test case transaction-stop-during-request-dispatch.html highlights the issue: 1. iframe issues 10 get requests, calls txn.commit(), sets onsuccess on the first request 2. From inside firstGet.onsuccess, iframe postMessages the parent — this queues the parent's onmessage task 3. Handler returns -> finishedDispatchEventForRequest clears m_currentlyCompletingRequest, then handleOperationsCompletedOnServer immediately sets it to get oven-sh#1 4. Parent's onmessage (queued before step 3 finished) runs frame.remove() while m_currentlyCompletingRequest = get oven-sh#1 5. IDBTransaction::stop() runs with completion in flight — pre-fix path returns early, retain cycle survives Canonical link: https://commits.webkit.org/312647@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

af63dbd enabled the libpas JIT heap on Windows, but on Windows ARM64 DFG worker threads intermittently hit a PAS_ASSERT inside jit_heap_try_allocate -> pas_segregated_heap_ensure_allocator_index. On ARM64 Windows, libpas's __builtin_trap() compiles to brk oven-sh#1, which the OS reports as STATUS_ILLEGAL_INSTRUCTION rather than a breakpoint, so the crash surfaces as a flaky 'illegal instruction' failure. Windows x64 has not exhibited the same failure, so leave the libpas JIT heap enabled there and fall back to the legacy MetaAllocator path on Windows ARM64 only until the assertion is root-caused.

…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

…treated as a page reload https://bugs.webkit.org/show_bug.cgi?id=314145 rdar://176933795 Reviewed by Chris Dumez. A refresh (via <meta http-equiv="refresh"> or the HTTP Refresh header) whose target URL equals the current document's URL ignoring fragments, but adds or changes the fragment identifier, is a same-document fragment navigation per the HTML "navigate to a fragment" step [1]. It must not issue a network request or emit a new Referer header. ScheduledRedirect::fire() decided whether the redirect was a "refresh" using equalIgnoringFragmentIdentifier(), which is true both for an identical URL and for the same URL with a different fragment. In the latter case it wrongly forced ResourceRequestCachePolicy::ReloadIgnoringCacheData, which makes FrameLoader::loadFrameRequest() pick FrameLoadType::Reload. Because shouldPerformFragmentNavigation() bails out for reloads, WebKit performed a full network load of the fragment URL instead of an in-document scroll, sending a fresh Referer (the page's own URL) rather than preserving the original referrer. Treat the redirect as a same-document fragment navigation only when the refresh's own target URL carries a fragment that differs from the current document's fragment. The decision is made against the target captured at parse time, not against whatever fragment the user may have scrolled to afterward: a bare <meta http-equiv="refresh"> with no url= records a fragmentless target and must always reload (preserving scroll restoration) even if the document's current URL has since gained a fragment via location.assign('oven-sh#1'). Only when the target itself adds or changes the fragment does the redirect flow as a Standard navigation so shouldPerformFragmentNavigation() performs the same-document scroll with the referrer unchanged. [1] https://html.spec.whatwg.org/multipage/browsing-the-web.html#navigate-fragid-step * LayoutTests/imported/w3c/web-platform-tests/html/browsers/browsing-the-web/navigating-across-documents/refresh/same-document-refresh-expected.txt: Progression. * Source/WebCore/loader/NavigationScheduler.cpp: (WebCore::ScheduledRedirect::fire): Canonical link: https://commits.webkit.org/316001@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

@replace

…ew() swaps KEEP; matchStr isEmpty → JSString::length() regexp-phase3-audit. regexp is the #1 per-test regressor (−13% tip vs baseline). Audited all 9 view() swaps of 96decd2 in RegExpPrototype.cpp: none sit in JetStream's fast path — stringProtoFuncReplace → replaceUsingRegExpSearch, not this slow generic @@replace. The −13% lives in StringPrototype.cpp replaceUsingRegExpSearch / ed33154 jsSubstringOfResolved, not here. One local micro-opt kept: matchStr->isEmpty() (derived a GCOwnedDataScope) → matchJSString->length() (single m_length load, no scope). Profile (miniprof 2 kHz, Box2D, /tmp/pmp-out/report.txt — no regexp frames in Box2D; regexp-specific profile not captured under load-avg 40). Per-test % (3x interleaved, /tmp/fix2-bench3x2.log clean-env medians + subset): baseline patched delta JetStream2 total 196.120 206.259 +5.17% regexp 352.449 268.594 -23.79% (noisy, load-avg 40; fix is in StringPrototype, not here) seq-crash-survey: CRASH_COUNT=0 (17/17 sequence + full suite) — /tmp/fix3-survey.log

…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

Jarred-Sumner merged commit 1447dba into oven-sh:main Sep 6, 2021

Jarred-Sumner force-pushed the main branch from f26a667 to 6a34777 Compare September 6, 2021 00:13

robobun mentioned this pull request Apr 21, 2026

[YARR] Fix JIT SEGV from parenContextHead nulling across aliased slots #189

Closed

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

This was referenced Aug 18, 2026

DFG: LiveCatchVariablePreservationPhase flushed the wrong handler's locals when one try range leads directly into another #417

Open

Add DFG/FTL nodes for byte-offset scalar accessors on ArrayBufferView receivers #330

Merged

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

This was referenced Sep 6, 2026

[YARR] Reject \ + non-ASCII as an identity escape in Unicode mode #577

Open

[JSC] Add JSGenericTypedArrayView::createWithAuxiliaryVector #584

Closed

Navigation Menu

Uh oh!

maybe upgrade - #1

maybe upgrade#1
Jarred-Sumner merged 0 commit into
oven-sh:mainfrom
WebKit:main

Jarred-Sumner commented Sep 6, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

Jarred-Sumner commented Sep 6, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant