Fix typo in domain.endsWith() check for hulu.com by berelig · Pull Request #1 · WebKit/WebKit

berelig · 2021-02-17T15:11:41Z

Missing period after the subdomain.

Missing period before the subdomain.

JonWBedard · 2021-02-17T18:21:42Z

@berelig we aren't ready to start using GitHub pull requests yet (although it's something we're working towards), for now, please file a bug via bugs.webkit.org and upload a patch with Tools/Scripts/webkit-patch upload. You can do all of this from your GitHub checkout.

https://bugs.webkit.org/show_bug.cgi?id=223082 Patch by Kimmo Kinnunen <[email protected]> on 2021-03-17 Reviewed by Kenneth Russell. Source/WebCore: * CMakeLists.txt: * SourcesCocoa.txt: * WebCore.xcodeproj/project.pbxproj: * platform/graphics/cocoa/GraphicsContextGLOpenGLCocoa.mm: (WebCore::InitializeEGLDisplay): (WebCore::GraphicsContextGLOpenGL::GraphicsContextGLOpenGL): * platform/graphics/opengl/GraphicsContextGLOpenGL.h: Hold the default EGLDisplay with a scoped holder that counts the references to the default display. (WebCore::GraphicsContextGLOpenGL::releaseAllResourcesIfUnused): Add a call that uninitializes the ANGLE default display if there are no uses of the default display. Source/WebKit: Schedule a check for releasing the ANGLE default display when global count of remote graphics contexts reach zero. This should decrease the memory use of sessions where WebGL is not always on. Dispatch the check 0.2s after hitting zero, so that the optimization still affects page navigations but maybe does not redundantly deinitialize / reinitialize ANGLE in the cases where the context #1 is created and destroyed frequently. * GPUProcess/graphics/RemoteGraphicsContextGL.cpp: (WebKit::dispatchReleaseAllResourcesIfUnused): (WebKit::RemoteGraphicsContextGL::initialize): (WebKit::RemoteGraphicsContextGL::stopListeningForIPC): Canonical link: https://commits.webkit.org/235402@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@274557 268f45cc-cd09-0410-ab3c-d52691b4dbfc

REGRESSION(r268615): images flicker on apple.com/ios/ios-14 https://bugs.webkit.org/show_bug.cgi?id=221054 <rdar://problem/72880447> Reviewed by Dean Jackson. Source/WebCore: When we added support for accelerated animations of individual transform properties in r268615 (bug 217842), we made it so that base values of each transform-related property had a non-interpolating animation in the Core Animation animations list that would combine with interpolating animations for that property as additive animations. Prior to any of those animations, we'd reset the combined transform with an identity transform as another non-interpolating animation. However, we neglected to consider the case where one of the interpolating animations would not start right away if a positive delay was set. In the case of this apple.com page, the target element would be composited due to a "will-change: transform" style, and a non-animated "transform" was set as well as an animation for the "transform" property with a delay. Since we had a "transform" animation, we'd create a Core Animation animations lists as follows: 1. non-interpolating, non-additive animation set to the identity matrix 2. interpolating, additive animation with the keyframes set in the CSS animation, with a begin time set to the current time plus the specified delay The result of this was that during the animation delay, the static "transform" property was overridden by animation #1 until animation #2 would kick in. We now make it so that for each transform-related property, we create a non-interpoloating, additive animation to represent the static value for that property for the duration of any potential delay until the first interpolating animation for this property starts. In this example, the Core Animation animations list is now as follows: 1. non-interpolating, non-additive animation set to the identity matrix 2. non-interpolating, additive animation set to the static transform value 3. interpolating, additive animation with the keyframes set in the CSS animation, with a begin time set to the current time plus the specified delay We implement this with a new lambda function within GraphicsLayerCA::updateAnimations() called addAnimationsForProperty() which adds a non-interpolating animation in two cases: 1. if there is no animation for this property at all, making it last forever 2. if all animations have a delay, making it last until the first animation starts Tests: webanimations/multiple-transform-properties-and-multiple-transform-properties-animation-with-delay-on-forced-layer.html webanimations/rotate-property-and-rotate-animation-with-delay-on-forced-layer.html webanimations/scale-property-and-scale-animation-with-delay-on-forced-layer.html webanimations/transform-property-and-transform-animation-with-delay-on-forced-layer.html webanimations/translate-property-and-translate-animation-with-delay-on-forced-layer.html * platform/graphics/ca/GraphicsLayerCA.cpp: (WebCore::GraphicsLayerCA::updateAnimations): LayoutTests: Add a series of tests ensuring that starting an animation for transform-related properties does not clobber the static value for this property. We only run those tests on WK2 because running those in WK1 is flaky as there doesn't seem to be a solid test utility to determine that Core Animation animations have been committed, even with long delays that would make tests run slow. * TestExpectations: * platform/ios-wk2/TestExpectations: * platform/mac-wk2/TestExpectations: * webanimations/multiple-transform-properties-and-multiple-transform-properties-animation-with-delay-on-forced-layer-expected.html: Added. * webanimations/multiple-transform-properties-and-multiple-transform-properties-animation-with-delay-on-forced-layer.html: Added. * webanimations/resources/wait-until-animations-are-committed.js: Added. * webanimations/rotate-property-and-rotate-animation-with-delay-on-forced-layer-expected.html: Added. * webanimations/rotate-property-and-rotate-animation-with-delay-on-forced-layer.html: Added. * webanimations/scale-property-and-scale-animation-with-delay-on-forced-layer-expected.html: Added. * webanimations/scale-property-and-scale-animation-with-delay-on-forced-layer.html: Added. * webanimations/transform-property-and-transform-animation-with-delay-on-forced-layer-expected.html: Added. * webanimations/transform-property-and-transform-animation-with-delay-on-forced-layer.html: Added. * webanimations/translate-property-and-translate-animation-with-delay-on-forced-layer-expected.html: Added. * webanimations/translate-property-and-translate-animation-with-delay-on-forced-layer.html: Added. Canonical link: https://commits.webkit.org/233429@trunk git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272004 268f45cc-cd09-0410-ab3c-d52691b4dbfc Canonical link: https://commits.webkit.org/232923.106@safari-611-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-611-branch@272264 268f45cc-cd09-0410-ab3c-d52691b4dbfc

@A

[JSC] Insert PhantomLocal just before SetLocal for |this| to ensure liveness https://bugs.webkit.org/show_bug.cgi?id=221353 <rdar://problem/70373862> Reviewed by Saam Barati. Let's consider the following case before SSA conversion. BB#0: SetArgumentDefinitely(this) ... @A: SomethingFun() MoveHint(@A, this) SetLocal(@A, this) Jump #1 BB#1: ... ExitOK (this point) ... @b: SomethingFun() MoveHint(@b, this) SetLocal(@b, this) ... BB#2: (Catch entry point) ... @c: SetArgumentDefinitely(this) ... Jump #1 We have two entry points. And BB#0 sets @A to |this| while BB#2 does not update |this|, so it is using @c. We have several patterns we can store |this|: arrow functions' |this| loading, derived constructors' |this| update. So we can see SetLocal(@x, this) at arbitrary code points in CodeBlocks having them. The problem is that DFG strongly assumed that |this| is initialized in the root basic block only once. So usually, we do not insert Flush/PhantomLocal for |this|. But this is problematic when we can store |this| at arbitrary basic blocks since we do not properly insert Flush/PhantomLocal(this) in BB#1's just before Store. Not inserting that in the above case makes |this| dead in BB#1's head liveness. Then we do not properly insert Phi(BB#0, BB#2) for |this|. This is OK for non |this| locals since literally that local is not used at all in BB#1. But |this| is special since it is always live in bytecode. So, OSR availability will be broken in the above graph: at ExitOK place, |this| must be live in bytecode. But |this| is pointing ConflictingFlush since BB#0 says @A and BB#2 says @c while we do not have Phi. The problem is that we do not keep liveness of |this| properly in BB#1. When setting a new |this|, we insert PhantomLocal to keep liveness so that appropriate Phi will be inserted when two predecessors have different DFG nodes for |this|, and this graph can appear in arrow functions, derived constructors, and code with catch. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::setArgument): * dfg/DFGVariableAccessDataDump.cpp: (JSC::DFG::VariableAccessDataDump::dump const): Canonical link: https://commits.webkit.org/233677@trunk git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272349 268f45cc-cd09-0410-ab3c-d52691b4dbfc Canonical link: https://commits.webkit.org/232923.164@safari-611-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-611-branch@272533 268f45cc-cd09-0410-ab3c-d52691b4dbfc

REGRESSION(r268615): images flicker on apple.com/ios/ios-14 https://bugs.webkit.org/show_bug.cgi?id=221054 <rdar://problem/72880447> Reviewed by Dean Jackson. Source/WebCore: When we added support for accelerated animations of individual transform properties in r268615 (bug 217842), we made it so that base values of each transform-related property had a non-interpolating animation in the Core Animation animations list that would combine with interpolating animations for that property as additive animations. Prior to any of those animations, we'd reset the combined transform with an identity transform as another non-interpolating animation. However, we neglected to consider the case where one of the interpolating animations would not start right away if a positive delay was set. In the case of this apple.com page, the target element would be composited due to a "will-change: transform" style, and a non-animated "transform" was set as well as an animation for the "transform" property with a delay. Since we had a "transform" animation, we'd create a Core Animation animations lists as follows: 1. non-interpolating, non-additive animation set to the identity matrix 2. interpolating, additive animation with the keyframes set in the CSS animation, with a begin time set to the current time plus the specified delay The result of this was that during the animation delay, the static "transform" property was overridden by animation #1 until animation #2 would kick in. We now make it so that for each transform-related property, we create a non-interpoloating, additive animation to represent the static value for that property for the duration of any potential delay until the first interpolating animation for this property starts. In this example, the Core Animation animations list is now as follows: 1. non-interpolating, non-additive animation set to the identity matrix 2. non-interpolating, additive animation set to the static transform value 3. interpolating, additive animation with the keyframes set in the CSS animation, with a begin time set to the current time plus the specified delay We implement this with a new lambda function within GraphicsLayerCA::updateAnimations() called addAnimationsForProperty() which adds a non-interpolating animation in two cases: 1. if there is no animation for this property at all, making it last forever 2. if all animations have a delay, making it last until the first animation starts Tests: webanimations/multiple-transform-properties-and-multiple-transform-properties-animation-with-delay-on-forced-layer.html webanimations/rotate-property-and-rotate-animation-with-delay-on-forced-layer.html webanimations/scale-property-and-scale-animation-with-delay-on-forced-layer.html webanimations/transform-property-and-transform-animation-with-delay-on-forced-layer.html webanimations/translate-property-and-translate-animation-with-delay-on-forced-layer.html * platform/graphics/ca/GraphicsLayerCA.cpp: (WebCore::GraphicsLayerCA::updateAnimations): LayoutTests: Add a series of tests ensuring that starting an animation for transform-related properties does not clobber the static value for this property. We only run those tests on WK2 because running those in WK1 is flaky as there doesn't seem to be a solid test utility to determine that Core Animation animations have been committed, even with long delays that would make tests run slow. * TestExpectations: * platform/ios-wk2/TestExpectations: * platform/mac-wk2/TestExpectations: * webanimations/multiple-transform-properties-and-multiple-transform-properties-animation-with-delay-on-forced-layer-expected.html: Added. * webanimations/multiple-transform-properties-and-multiple-transform-properties-animation-with-delay-on-forced-layer.html: Added. * webanimations/resources/wait-until-animations-are-committed.js: Added. * webanimations/rotate-property-and-rotate-animation-with-delay-on-forced-layer-expected.html: Added. * webanimations/rotate-property-and-rotate-animation-with-delay-on-forced-layer.html: Added. * webanimations/scale-property-and-scale-animation-with-delay-on-forced-layer-expected.html: Added. * webanimations/scale-property-and-scale-animation-with-delay-on-forced-layer.html: Added. * webanimations/transform-property-and-transform-animation-with-delay-on-forced-layer-expected.html: Added. * webanimations/transform-property-and-transform-animation-with-delay-on-forced-layer.html: Added. * webanimations/translate-property-and-translate-animation-with-delay-on-forced-layer-expected.html: Added. * webanimations/translate-property-and-translate-animation-with-delay-on-forced-layer.html: Added. Canonical link: https://commits.webkit.org/233429@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272004 268f45cc-cd09-0410-ab3c-d52691b4dbfc Canonical link: https://commits.webkit.org/232923.106@safari-611-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-611-branch@272264 268f45cc-cd09-0410-ab3c-d52691b4dbfc

@A

[JSC] Insert PhantomLocal just before SetLocal for |this| to ensure liveness https://bugs.webkit.org/show_bug.cgi?id=221353 <rdar://problem/70373862> Reviewed by Saam Barati. Let's consider the following case before SSA conversion. BB#0: SetArgumentDefinitely(this) ... @A: SomethingFun() MoveHint(@A, this) SetLocal(@A, this) Jump #1 BB#1: ... ExitOK (this point) ... @b: SomethingFun() MoveHint(@b, this) SetLocal(@b, this) ... BB#2: (Catch entry point) ... @c: SetArgumentDefinitely(this) ... Jump #1 We have two entry points. And BB#0 sets @A to |this| while BB#2 does not update |this|, so it is using @c. We have several patterns we can store |this|: arrow functions' |this| loading, derived constructors' |this| update. So we can see SetLocal(@x, this) at arbitrary code points in CodeBlocks having them. The problem is that DFG strongly assumed that |this| is initialized in the root basic block only once. So usually, we do not insert Flush/PhantomLocal for |this|. But this is problematic when we can store |this| at arbitrary basic blocks since we do not properly insert Flush/PhantomLocal(this) in BB#1's just before Store. Not inserting that in the above case makes |this| dead in BB#1's head liveness. Then we do not properly insert Phi(BB#0, BB#2) for |this|. This is OK for non |this| locals since literally that local is not used at all in BB#1. But |this| is special since it is always live in bytecode. So, OSR availability will be broken in the above graph: at ExitOK place, |this| must be live in bytecode. But |this| is pointing ConflictingFlush since BB#0 says @A and BB#2 says @c while we do not have Phi. The problem is that we do not keep liveness of |this| properly in BB#1. When setting a new |this|, we insert PhantomLocal to keep liveness so that appropriate Phi will be inserted when two predecessors have different DFG nodes for |this|, and this graph can appear in arrow functions, derived constructors, and code with catch. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::setArgument): * dfg/DFGVariableAccessDataDump.cpp: (JSC::DFG::VariableAccessDataDump::dump const): Canonical link: https://commits.webkit.org/233677@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272349 268f45cc-cd09-0410-ab3c-d52691b4dbfc Canonical link: https://commits.webkit.org/232923.164@safari-611-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-611-branch@272533 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=226751 Reviewed by Simon Fraser. Source/WebCore: This patch adds the initial support for content like this: <table> <tr> <td style="width: 10%"></td><td style="width: 90%"></td> </tr> </table> Percent values work in mysterious ways in cases when the table has no fixed width. 1. The smaller the percent value is, the wider the table may become. Percent values are resolved against the cell's border box (so essentially they are resolved against their own content as opposed to the table/containing block) and the formula is slightly different. <td style="padding: 5px; width: 20%;"></td> : produces a 10px wide border box (horizontal border: 0px, padding: 10px, content: 0px). The maximum constraint is resolved to 50px (width / percent * 100) <td style="padding: 5px; width: 100%;"></td> : produces a 10px wide border box and the maximum constraint is resolved to 10px. This maximum constraint value turns into the available width for the table content and becomes the final table width. 2. With multiple rows, we pick the highest _percent_ value for each column (as opposed to the resolved values). <tr><td style="width: 20%"></td></tr> (assum same 5px padding on both sides) <tr><td style="width: 80%"></td></tr> While the second row's cell has a higher maximum constraint value (50px see #1) since we only look at the raw percent values, this content only produces a 12.5px wide table. 3. The percent values do not accumulate across columns but instead we pick the largest one to represent the entire table's max constraint width. <tr><td style="width: 60%"></td><td style="width: 40%"></td></tr> 60% resolves to 16.6px 40% resolves to 25px and we use the 25px value as the width for the entire table (and not 16.6px + 25px). 4. Since we pick the highest percent values across rows for each columns, we may end up with > 100%. In such cases we start dropping percent values for subsequent columns: <tr><td style="width: 20%;"></td><td style="width: 80%;"></td></tr> <tr><td style="width: 60%;"></td><td style="width: 10%;"></td></tr> First column width is max(20%, 60%) -> 60% Second column width is max(80%, 10%) -> 80% As we limit the accumulated percent value to 100%, the final column percent values are 60% and 40% (and not 80%). Now the 60% is resolved to 16.6px and the 40% is resolved to 25px and since we don't accumulate these values (see #3) the final table width is 25px (based on a percent value which is not even in the markup). 5. While the smaller percent values produce wider tables (see #1), during the available space distribution columns with smaller percent values get assigned less space. <tr><td style="width: 1%"></td><td style="width: 99%"></td></tr> This content produces a 1000px wide table due to the small (1%) percent value (see #1 #2 and #3). When we distribute the available space (1000px), the first cell gets only 10px (1%) while the second cell ends up with 990px (99%). (and this is the cherry on top (not included in this patch): Imagine the following scenario: 1. the accumulated column percent value > 100% (let's say 80% and 30%) 2. as we reach the 100% while walking the columns one by one (see #4), the remaining percent value becomes 0%. 3. In order to avoid division by 0, we pick a very small epsilon value to run the formula. 4. Now this very small percent value produces a large resolved value (see #2) which means <tr><td style="width: 100%"></td></tr> produces a 10px wide table <tr><td style="width: 100%"></td><td style="width: 1%"></td></tr> <- note the 1% produces a very very very wide table. ) Test: fast/layoutformattingcontext/table-with-percent-columns-only-no-content.html * layout/formattingContexts/table/TableFormattingContext.cpp: (WebCore::Layout::TableFormattingContext::computedIntrinsicWidthConstraints): (WebCore::Layout::TableFormattingContext::computedPreferredWidthForColumns): * layout/formattingContexts/table/TableGrid.h: (WebCore::Layout::TableGrid::Column::percent const): (WebCore::Layout::TableGrid::Column::setFixedWidth): (WebCore::Layout::TableGrid::Column::setPercent): * layout/formattingContexts/table/TableLayout.cpp: (WebCore::Layout::TableFormattingContext::TableLayout::distributedHorizontalSpace): LayoutTests: * fast/layoutformattingcontext/table-with-percent-columns-only-no-content-expected.html: Added. * fast/layoutformattingcontext/table-with-percent-columns-only-no-content.html: Added. Canonical link: https://commits.webkit.org/238594@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@278605 268f45cc-cd09-0410-ab3c-d52691b4dbfc

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

… 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

https://bugs.webkit.org/show_bug.cgi?id=232265 Patch by Mikhail R. Gadelha <[email protected]> on 2021-11-09 Reviewed by Saam Barati. Follow-up from https://bugs.webkit.org/show_bug.cgi?id=232242, this patch includes several small code changes but the patch doesn't add/remove any feature: 1. Removed several calls to operationPutByVal*Cell* that were only used by the 32 bit code paths due to the lack of registers. These calls were replaced by the calls used by the 64 bit paths, that expect EncodedJSValues 2. Because of #1, this patch removes those methods, since no one uses them anymore. 3. Created compilePutByVal to handle all cases (similar to compileGetByVal). 4. Removed the Edge& childX from the PutByVal handling (and all methods that expected them) in favor of getting them from node when needed. 5. Unified compileContiguousPutByVal so it could be used by both 32 and 64 bit archs. 6. Removed a lot of whitespace. * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileContiguousPutByVal): (JSC::DFG::SpeculativeJIT::compileDoublePutByVal): (JSC::DFG::SpeculativeJIT::compilePutByVal): (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray): (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray): Deleted. (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray): Deleted. (JSC::DFG::SpeculativeJIT::compileGetByValForObjectWithString): Deleted. (JSC::DFG::SpeculativeJIT::compileGetByValForObjectWithSymbol): Deleted. (JSC::DFG::SpeculativeJIT::compileGetPrivateName): Deleted. (JSC::DFG::SpeculativeJIT::compileGetPrivateNameByVal): Deleted. (JSC::DFG::SpeculativeJIT::compileGetPrivateNameById): Deleted. (JSC::DFG::SpeculativeJIT::compilePutByValForCellWithString): Deleted. (JSC::DFG::SpeculativeJIT::compilePutByValForCellWithSymbol): Deleted. (JSC::DFG::SpeculativeJIT::compileGetByValWithThis): Deleted. (JSC::DFG::SpeculativeJIT::compilePutPrivateName): Deleted. (JSC::DFG::SpeculativeJIT::compilePutPrivateNameById): Deleted. (JSC::DFG::SpeculativeJIT::compileCheckPrivateBrand): Deleted. (JSC::DFG::SpeculativeJIT::compileSetPrivateBrand): Deleted. (JSC::DFG::SpeculativeJIT::compileCheckTypeInfoFlags): Deleted. (JSC::DFG::SpeculativeJIT::compileParseInt): Deleted. (JSC::DFG::SpeculativeJIT::compileOverridesHasInstance): Deleted. (JSC::DFG::SpeculativeJIT::compileInstanceOfForCells): Deleted. (JSC::DFG::SpeculativeJIT::compileInstanceOf): Deleted. (JSC::DFG::SpeculativeJIT::compileValueBitNot): Deleted. (JSC::DFG::SpeculativeJIT::compileBitwiseNot): Deleted. (JSC::DFG::SpeculativeJIT::emitUntypedOrAnyBigIntBitOp): Deleted. (JSC::DFG::SpeculativeJIT::compileValueBitwiseOp): Deleted. (JSC::DFG::SpeculativeJIT::compileBitwiseOp): Deleted. (JSC::DFG::SpeculativeJIT::emitUntypedOrBigIntRightShiftBitOp): Deleted. (JSC::DFG::SpeculativeJIT::compileValueLShiftOp): Deleted. (JSC::DFG::SpeculativeJIT::compileValueBitRShift): Deleted. (JSC::DFG::SpeculativeJIT::compileShiftOp): Deleted. (JSC::DFG::SpeculativeJIT::compileValueAdd): Deleted. (JSC::DFG::SpeculativeJIT::compileValueSub): Deleted. (JSC::DFG::SpeculativeJIT::compileMathIC): Deleted. (JSC::DFG::SpeculativeJIT::compileInstanceOfCustom): Deleted. (JSC::DFG::SpeculativeJIT::compileIsCellWithType): Deleted. (JSC::DFG::SpeculativeJIT::compileIsTypedArrayView): Deleted. (JSC::DFG::SpeculativeJIT::compileToObjectOrCallObjectConstructor): Deleted. (JSC::DFG::SpeculativeJIT::compileArithAdd): Deleted. (JSC::DFG::SpeculativeJIT::compileArithAbs): Deleted. (JSC::DFG::SpeculativeJIT::compileArithClz32): Deleted. (JSC::DFG::SpeculativeJIT::compileArithDoubleUnaryOp): Deleted. (JSC::DFG::SpeculativeJIT::compileArithSub): Deleted. (JSC::DFG::SpeculativeJIT::compileIncOrDec): Deleted. (JSC::DFG::SpeculativeJIT::compileValueNegate): Deleted. (JSC::DFG::SpeculativeJIT::compileArithNegate): Deleted. (JSC::DFG::SpeculativeJIT::compileValueMul): Deleted. (JSC::DFG::SpeculativeJIT::compileArithMul): Deleted. (JSC::DFG::SpeculativeJIT::compileValueDiv): Deleted. (JSC::DFG::SpeculativeJIT::compileArithDiv): Deleted. (JSC::DFG::SpeculativeJIT::compileArithFRound): Deleted. (JSC::DFG::SpeculativeJIT::compileValueMod): Deleted. (JSC::DFG::SpeculativeJIT::compileArithMod): Deleted. (JSC::DFG::SpeculativeJIT::compileArithRounding): Deleted. (JSC::DFG::SpeculativeJIT::compileArithUnary): Deleted. (JSC::DFG::SpeculativeJIT::compileArithSqrt): Deleted. (JSC::DFG::SpeculativeJIT::compileArithMinMax): Deleted. (JSC::DFG::compileArithPowIntegerFastPath): Deleted. (JSC::DFG::SpeculativeJIT::compileValuePow): Deleted. (JSC::DFG::SpeculativeJIT::compileArithPow): Deleted. (JSC::DFG::SpeculativeJIT::compare): Deleted. (JSC::DFG::SpeculativeJIT::compileCompareUnsigned): Deleted. (JSC::DFG::SpeculativeJIT::compileStrictEq): Deleted. (JSC::DFG::SpeculativeJIT::compileBooleanCompare): Deleted. (JSC::DFG::SpeculativeJIT::compileInt32Compare): Deleted. (JSC::DFG::SpeculativeJIT::compileDoubleCompare): Deleted. (JSC::DFG::SpeculativeJIT::compileObjectEquality): Deleted. (JSC::DFG::SpeculativeJIT::compileSymbolEquality): Deleted. (JSC::DFG::SpeculativeJIT::compilePeepHoleSymbolEquality): Deleted. (JSC::DFG::SpeculativeJIT::emitBitwiseJSValueEquality): Deleted. (JSC::DFG::SpeculativeJIT::emitBranchOnBitwiseJSValueEquality): Deleted. (JSC::DFG::SpeculativeJIT::compileNotDoubleNeitherDoubleNorHeapBigIntNorStringStrictEquality): Deleted. (JSC::DFG::SpeculativeJIT::compilePeepHoleNotDoubleNeitherDoubleNorHeapBigIntNorStringStrictEquality): Deleted. (JSC::DFG::SpeculativeJIT::compileStringEquality): Deleted. (JSC::DFG::SpeculativeJIT::compileStringToUntypedEquality): Deleted. (JSC::DFG::SpeculativeJIT::compileStringIdentEquality): Deleted. (JSC::DFG::SpeculativeJIT::compileStringIdentToNotStringVarEquality): Deleted. (JSC::DFG::SpeculativeJIT::compileStringCompare): Deleted. (JSC::DFG::SpeculativeJIT::compileStringIdentCompare): Deleted. (JSC::DFG::SpeculativeJIT::compileSameValue): Deleted. (JSC::DFG::SpeculativeJIT::compileToBooleanString): Deleted. (JSC::DFG::SpeculativeJIT::compileToBooleanStringOrOther): Deleted. (JSC::DFG::SpeculativeJIT::emitStringBranch): Deleted. (JSC::DFG::SpeculativeJIT::emitStringOrOtherBranch): Deleted. (JSC::DFG::SpeculativeJIT::compileConstantStoragePointer): Deleted. (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage): Deleted. (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage): Deleted. (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset): Deleted. (JSC::DFG::SpeculativeJIT::compileGetByValOnDirectArguments): Deleted. (JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments): Deleted. (JSC::DFG::SpeculativeJIT::compileGetScope): Deleted. (JSC::DFG::SpeculativeJIT::compileSkipScope): Deleted. (JSC::DFG::SpeculativeJIT::compileGetGlobalObject): Deleted. (JSC::DFG::SpeculativeJIT::compileGetGlobalThis): Deleted. (JSC::DFG::SpeculativeJIT::canBeRope): Deleted. (JSC::DFG::SpeculativeJIT::compileGetArrayLength): Deleted. (JSC::DFG::SpeculativeJIT::compileCheckIdent): Deleted. (JSC::DFG::SpeculativeJIT::compileNewFunctionCommon): Deleted. (JSC::DFG::SpeculativeJIT::compileNewFunction): Deleted. (JSC::DFG::SpeculativeJIT::compileSetFunctionName): Deleted. (JSC::DFG::SpeculativeJIT::compileVarargsLength): Deleted. (JSC::DFG::SpeculativeJIT::compileLoadVarargs): Deleted. (JSC::DFG::SpeculativeJIT::compileForwardVarargs): Deleted. (JSC::DFG::SpeculativeJIT::compileCreateActivation): Deleted. (JSC::DFG::SpeculativeJIT::compileCreateDirectArguments): Deleted. (JSC::DFG::SpeculativeJIT::compileGetFromArguments): Deleted. (JSC::DFG::SpeculativeJIT::compilePutToArguments): Deleted. (JSC::DFG::SpeculativeJIT::compileGetArgument): Deleted. (JSC::DFG::SpeculativeJIT::compileCreateScopedArguments): Deleted. (JSC::DFG::SpeculativeJIT::compileCreateClonedArguments): Deleted. (JSC::DFG::SpeculativeJIT::compileCreateArgumentsButterfly): Deleted. (JSC::DFG::SpeculativeJIT::compileCreateRest): Deleted. (JSC::DFG::SpeculativeJIT::compileSpread): Deleted. (JSC::DFG::SpeculativeJIT::compileNewArray): Deleted. (JSC::DFG::SpeculativeJIT::compileNewArrayWithSpread): Deleted. (JSC::DFG::SpeculativeJIT::compileGetRestLength): Deleted. (JSC::DFG::SpeculativeJIT::emitPopulateSliceIndex): Deleted. (JSC::DFG::SpeculativeJIT::compileArraySlice): Deleted. (JSC::DFG::SpeculativeJIT::compileArrayIndexOf): Deleted. (JSC::DFG::SpeculativeJIT::compileArrayPush): Deleted. (JSC::DFG::SpeculativeJIT::compileNotifyWrite): Deleted. (JSC::DFG::SpeculativeJIT::compileIsObject): Deleted. (JSC::DFG::SpeculativeJIT::compileTypeOfIsObject): Deleted. (JSC::DFG::SpeculativeJIT::compileIsCallable): Deleted. (JSC::DFG::SpeculativeJIT::compileIsConstructor): Deleted. (JSC::DFG::SpeculativeJIT::compileTypeOf): Deleted. (JSC::DFG::SpeculativeJIT::emitStructureCheck): Deleted. (JSC::DFG::SpeculativeJIT::compileCheckIsConstant): Deleted. (JSC::DFG::SpeculativeJIT::compileCheckNotEmpty): Deleted. (JSC::DFG::SpeculativeJIT::compileCheckStructure): Deleted. (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage): Deleted. (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage): Deleted. (JSC::DFG::SpeculativeJIT::compileNukeStructureAndSetButterfly): Deleted. (JSC::DFG::SpeculativeJIT::compileGetButterfly): Deleted. (JSC::DFG::allocateTemporaryRegistersForSnippet): Deleted. (JSC::DFG::SpeculativeJIT::compileCallDOM): Deleted. (JSC::DFG::SpeculativeJIT::compileCallDOMGetter): Deleted. (JSC::DFG::SpeculativeJIT::compileCheckJSCast): Deleted. (JSC::DFG::SpeculativeJIT::temporaryRegisterForPutByVal): Deleted. (JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOrStringValueOf): Deleted. (JSC::DFG::getExecutable): Deleted. (JSC::DFG::SpeculativeJIT::compileFunctionToString): Deleted. (JSC::DFG::SpeculativeJIT::compileNumberToStringWithValidRadixConstant): Deleted. (JSC::DFG::SpeculativeJIT::compileNumberToStringWithRadix): Deleted. (JSC::DFG::SpeculativeJIT::compileNewStringObject): Deleted. (JSC::DFG::SpeculativeJIT::compileNewSymbol): Deleted. (JSC::DFG::SpeculativeJIT::compileNewTypedArrayWithSize): Deleted. (JSC::DFG::SpeculativeJIT::emitNewTypedArrayWithSizeInRegister): Deleted. (JSC::DFG::SpeculativeJIT::compileNewRegexp): Deleted. (JSC::DFG::SpeculativeJIT::speculateCellTypeWithoutTypeFiltering): Deleted. (JSC::DFG::SpeculativeJIT::speculateCellType): Deleted. (JSC::DFG::SpeculativeJIT::speculateInt32): Deleted. (JSC::DFG::SpeculativeJIT::speculateNumber): Deleted. (JSC::DFG::SpeculativeJIT::speculateRealNumber): Deleted. (JSC::DFG::SpeculativeJIT::speculateDoubleRepReal): Deleted. (JSC::DFG::SpeculativeJIT::speculateBoolean): Deleted. (JSC::DFG::SpeculativeJIT::speculateCell): Deleted. (JSC::DFG::SpeculativeJIT::speculateCellOrOther): Deleted. (JSC::DFG::SpeculativeJIT::speculateObject): Deleted. (JSC::DFG::SpeculativeJIT::speculateFunction): Deleted. (JSC::DFG::SpeculativeJIT::speculateFinalObject): Deleted. (JSC::DFG::SpeculativeJIT::speculateRegExpObject): Deleted. (JSC::DFG::SpeculativeJIT::speculateArray): Deleted. (JSC::DFG::SpeculativeJIT::speculateProxyObject): Deleted. (JSC::DFG::SpeculativeJIT::speculateDerivedArray): Deleted. (JSC::DFG::SpeculativeJIT::speculatePromiseObject): Deleted. (JSC::DFG::SpeculativeJIT::speculateDateObject): Deleted. (JSC::DFG::SpeculativeJIT::speculateMapObject): Deleted. (JSC::DFG::SpeculativeJIT::speculateSetObject): Deleted. (JSC::DFG::SpeculativeJIT::speculateWeakMapObject): Deleted. (JSC::DFG::SpeculativeJIT::speculateWeakSetObject): Deleted. (JSC::DFG::SpeculativeJIT::speculateDataViewObject): Deleted. (JSC::DFG::SpeculativeJIT::speculateObjectOrOther): Deleted. (JSC::DFG::SpeculativeJIT::speculateString): Deleted. (JSC::DFG::SpeculativeJIT::speculateStringOrOther): Deleted. (JSC::DFG::SpeculativeJIT::speculateStringIdentAndLoadStorage): Deleted. (JSC::DFG::SpeculativeJIT::speculateStringIdent): Deleted. (JSC::DFG::SpeculativeJIT::speculateStringObject): Deleted. (JSC::DFG::SpeculativeJIT::speculateStringOrStringObject): Deleted. (JSC::DFG::SpeculativeJIT::speculateNotStringVar): Deleted. (JSC::DFG::SpeculativeJIT::speculateNotSymbol): Deleted. (JSC::DFG::SpeculativeJIT::speculateSymbol): Deleted. (JSC::DFG::SpeculativeJIT::speculateHeapBigInt): Deleted. (JSC::DFG::SpeculativeJIT::speculateNotCell): Deleted. (JSC::DFG::SpeculativeJIT::speculateNotCellNorBigInt): Deleted. (JSC::DFG::SpeculativeJIT::speculateNotDouble): Deleted. (JSC::DFG::SpeculativeJIT::speculateNeitherDoubleNorHeapBigInt): Deleted. (JSC::DFG::SpeculativeJIT::speculateNeitherDoubleNorHeapBigIntNorString): Deleted. (JSC::DFG::SpeculativeJIT::speculateOther): Deleted. (JSC::DFG::SpeculativeJIT::speculateMisc): Deleted. (JSC::DFG::SpeculativeJIT::speculate): Deleted. (JSC::DFG::SpeculativeJIT::emitSwitchIntJump): Deleted. (JSC::DFG::SpeculativeJIT::emitSwitchImm): Deleted. (JSC::DFG::SpeculativeJIT::emitSwitchCharStringJump): Deleted. (JSC::DFG::SpeculativeJIT::emitSwitchChar): Deleted. (JSC::DFG::SpeculativeJIT::emitBinarySwitchStringRecurse): Deleted. (JSC::DFG::SpeculativeJIT::emitSwitchStringOnString): Deleted. (JSC::DFG::SpeculativeJIT::emitSwitchString): Deleted. (JSC::DFG::SpeculativeJIT::emitSwitch): Deleted. (JSC::DFG::SpeculativeJIT::addBranch): Deleted. (JSC::DFG::SpeculativeJIT::linkBranches): Deleted. (JSC::DFG::SpeculativeJIT::compileStoreBarrier): Deleted. (JSC::DFG::SpeculativeJIT::compilePutAccessorById): Deleted. (JSC::DFG::SpeculativeJIT::compilePutGetterSetterById): Deleted. (JSC::DFG::SpeculativeJIT::compileResolveScope): Deleted. (JSC::DFG::SpeculativeJIT::compileResolveScopeForHoistingFuncDeclInEval): Deleted. (JSC::DFG::SpeculativeJIT::compileGetGlobalVariable): Deleted. (JSC::DFG::SpeculativeJIT::compilePutGlobalVariable): Deleted. (JSC::DFG::SpeculativeJIT::compileGetDynamicVar): Deleted. (JSC::DFG::SpeculativeJIT::compilePutDynamicVar): Deleted. (JSC::DFG::SpeculativeJIT::compileGetClosureVar): Deleted. (JSC::DFG::SpeculativeJIT::compilePutClosureVar): Deleted. (JSC::DFG::SpeculativeJIT::compileGetInternalField): Deleted. (JSC::DFG::SpeculativeJIT::compilePutInternalField): Deleted. (JSC::DFG::SpeculativeJIT::compilePutAccessorByVal): Deleted. (JSC::DFG::SpeculativeJIT::compileGetRegExpObjectLastIndex): Deleted. (JSC::DFG::SpeculativeJIT::compileSetRegExpObjectLastIndex): Deleted. (JSC::DFG::SpeculativeJIT::compileRegExpExec): Deleted. (JSC::DFG::SpeculativeJIT::compileRegExpTest): Deleted. (JSC::DFG::SpeculativeJIT::compileStringReplace): Deleted. (JSC::DFG::SpeculativeJIT::compileRegExpExecNonGlobalOrSticky): Deleted. (JSC::DFG::SpeculativeJIT::compileRegExpMatchFastGlobal): Deleted. (JSC::DFG::SpeculativeJIT::compileRegExpMatchFast): Deleted. (JSC::DFG::SpeculativeJIT::compileLazyJSConstant): Deleted. (JSC::DFG::SpeculativeJIT::compileMaterializeNewObject): Deleted. (JSC::DFG::SpeculativeJIT::compileRecordRegExpCachedResult): Deleted. (JSC::DFG::SpeculativeJIT::compileDefineDataProperty): Deleted. (JSC::DFG::SpeculativeJIT::compileDefineAccessorProperty): Deleted. (JSC::DFG::SpeculativeJIT::emitAllocateButterfly): Deleted. (JSC::DFG::SpeculativeJIT::compileNormalizeMapKey): Deleted. (JSC::DFG::SpeculativeJIT::compileGetMapBucketHead): Deleted. (JSC::DFG::SpeculativeJIT::compileGetMapBucketNext): Deleted. (JSC::DFG::SpeculativeJIT::compileLoadKeyFromMapBucket): Deleted. (JSC::DFG::SpeculativeJIT::compileLoadValueFromMapBucket): Deleted. (JSC::DFG::SpeculativeJIT::compileExtractValueFromWeakMapGet): Deleted. (JSC::DFG::SpeculativeJIT::compileThrow): Deleted. (JSC::DFG::SpeculativeJIT::compileThrowStaticError): Deleted. (JSC::DFG::SpeculativeJIT::compileEnumeratorNextUpdateIndexAndMode): Deleted. (JSC::DFG::SpeculativeJIT::compileEnumeratorNextExtractIndex): Deleted. (JSC::DFG::SpeculativeJIT::compileEnumeratorNextExtractMode): Deleted. (JSC::DFG::SpeculativeJIT::compileEnumeratorNextUpdatePropertyName): Deleted. (JSC::DFG::SpeculativeJIT::compileEnumeratorHasProperty): Deleted. (JSC::DFG::SpeculativeJIT::compileEnumeratorInByVal): Deleted. (JSC::DFG::SpeculativeJIT::compileEnumeratorHasOwnProperty): Deleted. (JSC::DFG::SpeculativeJIT::compilePutByIdFlush): Deleted. (JSC::DFG::SpeculativeJIT::compilePutById): Deleted. (JSC::DFG::SpeculativeJIT::compilePutByIdDirect): Deleted. (JSC::DFG::SpeculativeJIT::compilePutByIdWithThis): Deleted. (JSC::DFG::SpeculativeJIT::compileGetByOffset): Deleted. (JSC::DFG::SpeculativeJIT::compilePutByOffset): Deleted. (JSC::DFG::SpeculativeJIT::compileMatchStructure): Deleted. (JSC::DFG::SpeculativeJIT::compileGetPropertyEnumerator): Deleted. (JSC::DFG::SpeculativeJIT::compileGetExecutable): Deleted. (JSC::DFG::SpeculativeJIT::compileGetGetter): Deleted. (JSC::DFG::SpeculativeJIT::compileGetSetter): Deleted. (JSC::DFG::SpeculativeJIT::compileGetCallee): Deleted. (JSC::DFG::SpeculativeJIT::compileSetCallee): Deleted. (JSC::DFG::SpeculativeJIT::compileGetArgumentCountIncludingThis): Deleted. (JSC::DFG::SpeculativeJIT::compileSetArgumentCountIncludingThis): Deleted. (JSC::DFG::SpeculativeJIT::compileStrCat): Deleted. (JSC::DFG::SpeculativeJIT::compileNewArrayBuffer): Deleted. (JSC::DFG::SpeculativeJIT::compileNewArrayWithSize): Deleted. (JSC::DFG::SpeculativeJIT::compileNewTypedArray): Deleted. (JSC::DFG::SpeculativeJIT::compileToThis): Deleted. (JSC::DFG::SpeculativeJIT::compileObjectKeysOrObjectGetOwnPropertyNames): Deleted. (JSC::DFG::SpeculativeJIT::compileObjectAssign): Deleted. (JSC::DFG::SpeculativeJIT::compileObjectCreate): Deleted. (JSC::DFG::SpeculativeJIT::compileCreateThis): Deleted. (JSC::DFG::SpeculativeJIT::compileCreatePromise): Deleted. (JSC::DFG::SpeculativeJIT::compileCreateInternalFieldObject): Deleted. (JSC::DFG::SpeculativeJIT::compileCreateGenerator): Deleted. (JSC::DFG::SpeculativeJIT::compileCreateAsyncGenerator): Deleted. (JSC::DFG::SpeculativeJIT::compileNewObject): Deleted. (JSC::DFG::SpeculativeJIT::compileNewInternalFieldObjectImpl): Deleted. (JSC::DFG::SpeculativeJIT::compileNewGenerator): Deleted. (JSC::DFG::SpeculativeJIT::compileNewAsyncGenerator): Deleted. (JSC::DFG::SpeculativeJIT::compileNewInternalFieldObject): Deleted. (JSC::DFG::SpeculativeJIT::compileToPrimitive): Deleted. (JSC::DFG::SpeculativeJIT::compileToPropertyKey): Deleted. (JSC::DFG::SpeculativeJIT::compileToNumeric): Deleted. (JSC::DFG::SpeculativeJIT::compileCallNumberConstructor): Deleted. (JSC::DFG::SpeculativeJIT::compileLogShadowChickenPrologue): Deleted. (JSC::DFG::SpeculativeJIT::compileLogShadowChickenTail): Deleted. (JSC::DFG::SpeculativeJIT::compileSetAdd): Deleted. (JSC::DFG::SpeculativeJIT::compileMapSet): Deleted. (JSC::DFG::SpeculativeJIT::compileWeakMapGet): Deleted. (JSC::DFG::SpeculativeJIT::compileWeakSetAdd): Deleted. (JSC::DFG::SpeculativeJIT::compileWeakMapSet): Deleted. (JSC::DFG::SpeculativeJIT::compileGetPrototypeOf): Deleted. (JSC::DFG::SpeculativeJIT::compileIdentity): Deleted. (JSC::DFG::SpeculativeJIT::compileMiscStrictEq): Deleted. (JSC::DFG::SpeculativeJIT::emitInitializeButterfly): Deleted. (JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize): Deleted. (JSC::DFG::SpeculativeJIT::compileHasIndexedProperty): Deleted. (JSC::DFG::SpeculativeJIT::compileExtractCatchLocal): Deleted. (JSC::DFG::SpeculativeJIT::compileClearCatchLocals): Deleted. (JSC::DFG::SpeculativeJIT::compileProfileType): Deleted. (JSC::DFG::SpeculativeJIT::cachedPutById): Deleted. (JSC::DFG::SpeculativeJIT::genericJSValueNonPeepholeCompare): Deleted. (JSC::DFG::SpeculativeJIT::genericJSValuePeepholeBranch): Deleted. (JSC::DFG::SpeculativeJIT::compileHeapBigIntEquality): Deleted. (JSC::DFG::SpeculativeJIT::compileMakeRope): Deleted. (JSC::DFG::SpeculativeJIT::compileEnumeratorGetByVal): Deleted. * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): (JSC::DFG::SpeculativeJIT::compileContiguousPutByVal): Deleted. * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::branchIfEmpty): (JSC::AssemblyHelpers::branchIfNotEmpty): Canonical link: https://commits.webkit.org/244047@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@285530 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Improvements to LLInt offlineasm

…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

[Cocoa] metadata cue endTime may not be updated 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 Canonical link: https://commits.webkit.org/245886.331@safari-613-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-613-branch@291658 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=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, #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, #16383 \n" // LowLevelInterpreter.asm:633 ".loc 1 1518\n" "and x3, x3, x16 \n" // LowLevelInterpreter.asm:1518 ".loc 1 1519\n" "movz x16, #16088 \n" // LowLevelInterpreter.asm:1519 "add x17, x3, x16 \n" "ldr x3, [x17] \n" ... instead of this: ".loc 1 633\n" "movn x17, #16383 \n" // LowLevelInterpreter.asm:633 ".loc 1 1518\n" "and x3, x3, x17 \n" // LowLevelInterpreter.asm:1518 ".loc 1 1519\n" "ldr x3, [x3, #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, #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, #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

RenderElement::addLayers should check for dialog content before inserting 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 Canonical link: https://commits.webkit.org/245886.757@safari-613-branch

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()WebKit#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()WebKit#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*)WebKit#1}::_FUN(void*) (RunLoopGLib.cpp:80) ==3126== by 0x6E55D61: operator() (RunLoopGLib.cpp:53) ==3126== by 0x6E55D61: WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)WebKit#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()WebKit#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

…Encoding() 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 (cherry picked from commit 025cae4)

…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()WebKit#1}::operator()() const (HTMLMediaElement.cpp:1413) ==196== by 0x13D291BD: WTF::Detail::CallableWrapper<WebCore::HTMLMediaElement::selectMediaResource()::{lambda()WebKit#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()WebKit#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()WebKit#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()WebKit#1}::operator()() const (ThreadTimers.cpp:67) ==196== by 0x146E8407: WTF::Detail::CallableWrapper<WebCore::ThreadTimers::setSharedTimer(WebCore::SharedTimer*)::{lambda()WebKit#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*)WebKit#1}::operator()(void*) const (RunLoopGLib.cpp:177) ==196== by 0x110196E8: WTF::RunLoop::TimerBase::TimerBase(WTF::RunLoop&)::{lambda(void*)WebKit#1}::_FUN(void*) (RunLoopGLib.cpp:181) ==196== by 0x11018BFA: WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)WebKit#1}::operator()(_GSource*, int (*)(void*), void*) const (RunLoopGLib.cpp:53) ==196== by 0x11018C48: WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)WebKit#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()WebKit#1}::operator()() const (HTMLMediaElement.cpp:1413) ==196== by 0x13D291BD: WTF::Detail::CallableWrapper<WebCore::HTMLMediaElement::selectMediaResource()::{lambda()WebKit#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()WebKit#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()WebKit#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()WebKit#1}::operator()() const (ThreadTimers.cpp:67) ==196== by 0x146E8407: WTF::Detail::CallableWrapper<WebCore::ThreadTimers::setSharedTimer(WebCore::SharedTimer*)::{lambda()WebKit#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*)WebKit#1}::operator()(void*) const (RunLoopGLib.cpp:177) ==196== by 0x110196E8: WTF::RunLoop::TimerBase::TimerBase(WTF::RunLoop&)::{lambda(void*)WebKit#1}::_FUN(void*) (RunLoopGLib.cpp:181) ==196== by 0x11018BFA: WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)WebKit#1}::operator()(_GSource*, int (*)(void*), void*) const (RunLoopGLib.cpp:53) ==196== by 0x11018C48: WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)WebKit#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

…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: [ WebKit#1 ] [ 20] mov dst:loc9, src:<JSValue()>(const0) ... bb#3 Predecessors: [ WebKit#2 ] [ 29] get_rest_length dst:loc11, numParametersToSkip:1 ... bb#12 Predecessors: [ WebKit#8 WebKit#9 WebKit#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: [ WebKit#15 ] bb#14 Predecessors: [ WebKit#7 WebKit#11 ] [ 176] catch exception:loc10, thrownValue:loc8 [ 180] jmp targetLabel:2(->182) Successors: [ WebKit#15 ] bb#15 Predecessors: [ WebKit#13 WebKit#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, WebKit#32; emitSave <16> 0x115f74990: add x0, x2, x0 <20> 0x115f74994: sturb w1, [x0, WebKit#1] <24> 0x115f74998: ldp fp, lr, [sp], WebKit#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, WebKit#1] <20> 0x121108994: ldp fp, lr, [sp], WebKit#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 WebKit#1 and thus bypassing quirk WebKit#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 WebKit#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

Canvases painted into CG display list image buffers don't ever update 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 Canonical link: https://commits.webkit.org/[email protected]

Fix TypeError in parameter destructuring in async function should be 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: [ WebKit#1 ] [ 20] mov dst:loc9, src:<JSValue()>(const0) ... bb#3 Predecessors: [ WebKit#2 ] [ 29] get_rest_length dst:loc11, numParametersToSkip:1 ... bb#12 Predecessors: [ WebKit#8 WebKit#9 WebKit#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: [ WebKit#15 ] bb#14 Predecessors: [ WebKit#7 WebKit#11 ] [ 176] catch exception:loc10, thrownValue:loc8 [ 180] jmp targetLabel:2(->182) Successors: [ WebKit#15 ] bb#15 Predecessors: [ WebKit#13 WebKit#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 Canonical link: https://commits.webkit.org/252432.994@safari-7614-branch

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 WebKit#1: 0x000000010ec44204 0x10eccc5dc frame WebKit#2: 0x000000010eccc5dc callback#Dwaxn6 [Baseline bc#50](Undefined) frame WebKit#3: 0x000000010ec4ca84 wasm-stub [WasmToJS](Wasm::Instance: 0x10d29da40) frame WebKit#4: 0x000000010ed0c060 <?>.wasm-function[1] [OMG](Wasm::Instance: 0x10d29da40) frame WebKit#5: 0x000000010ed100d0 jsToWasm#CWTx6k [FTL bc#22](Cell[JSModuleEnvironment]: 0x12f524540, Cell[WebAssemblyFunction]: 0x10d06a3a8, 1, 2, 3) frame WebKit#6: 0x000000010ec881b0 #D5ymZE [Baseline bc#733](Undefined, Cell[Generator]: 0x12f55c180, 1, Cell[Object]: 0x12f69dfc0, 0, Cell[JSLexicalEnvironment]: 0x12f52cee0) frame WebKit#7: 0x000000010ec3c008 asyncFunctionResume#A4ayYg [LLInt bc#49](Undefined, Cell[Generator]: 0x12f55c180, Cell[Object]: 0x12f69dfc0, 0) frame WebKit#8: 0x000000010ec3c008 promiseReactionJobWithoutPromise#D0yDF1 [LLInt bc#25](Undefined, Cell[Function]: 0x12f44f3c0, Cell[Object]: 0x12f69dfc0, Cell[Generator]: 0x12f55c180) frame WebKit#9: 0x000000010ec80ec0 promiseReactionJob#EdShZz [Baseline bc#74](Undefined, Undefined, Cell[Function]: 0x12f44f3c0, Cell[Object]: 0x12f69dfc0, Cell[Generator]: 0x12f55c180) frame WebKit#10: 0x000000010ec3c728 frame WebKit#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 WebKit#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 WebKit#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 WebKit#14: 0x00000001039dfc54 JavaScriptCore`JSC::VM::drainMicrotasks() (.cold.1) at VM.cpp:0:9 [opt] frame WebKit#15: 0x00000001035e58a4 JavaScriptCore`JSC::VM::drainMicrotasks() [inlined] JSC::MicrotaskQueue::dequeue(this=<unavailable>) at VM.cpp:0:9 [opt] frame WebKit#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

@0

https://bugs.webkit.org/show_bug.cgi?id=253907 rdar://102754257 Reviewed by Keith Miller and Justin Michaud. iterator_next and iterator_open can create a graph of DFG nodes. But this is problematic for OSR exit node liveness tracking. We have phantom insertion phase to keep uses of instructions alive properly. But that analysis has an assumption that one instruction cannot create a graph. As a result, the phase does block local analysis, and if the local is not used on that basic block, we do not insert phantoms. Let's see Block #0 @0 GetLocal(local0) @1 Use(@0) @2 Jump(WebKit#1) Block WebKit#1 @3 ForceOSRExit In WebKit#1, we do not know that local0 needs to be kept alive even if local0 is alive in bytecode. And phantom insertion phase cannot insert phantoms to keep them alive since local0 operand in WebKit#1 is not filled. This patch adds keepUsesOfCurrentInstructionAlive helper function and call it in the prologue of newly created basic block for one instruction. This inserts all the uses of the instruction explicitly via GetLocal. Block #0 @0 GetLocal(local0) @1 Use(@0) @2 Jump(WebKit#1) Block WebKit#1 @3 GetLocal(local0) @4 ForceOSRExit With this function, we insert @3 for local0, and now phatom insertion phase will see operand for local0 is filled in WebKit#1, and appropriately insert Phantom into WebKit#1 too. * JSTests/stress/iterator-next-osr-exit-dead-1.js: Added. * JSTests/stress/iterator-next-osr-exit-dead-2.js: Added. (i.i.switch): * Source/JavaScriptCore/bytecode/BytecodeUseDef.cpp: (JSC::computeUsesForBytecodeIndexImpl): * Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::keepUsesOfCurrentInstructionAlive): (JSC::DFG::ByteCodeParser::parseBlock): Canonical link: https://commits.webkit.org/261668@main

https://bugs.webkit.org/show_bug.cgi?id=254666 Reviewed by Antti Koivisto. Consider the following case: <containing-block> <layout-boundary> Inline-content <out-of-flow-box> </layout-boundary> </containing-block> e.g. <div style="overflow: hidden"> some text <div style="position: absolute"></div> </div> 1. "inline content" gets mutated and the associated renderers are marked dirty. During #1 we climb the ancestor chain and mark containing blocks dirty to ensure the subsequent layout has a correct entry point. We either (most of the time) stop at the ICB (RenderView) during this walk or at a layout-boundary. 2. Subsequent layout is initiated starting at layout-boundary. The geometry of the freshly laid out inline-content may affect the out-of-flow-box's static position. In inline layout code (both legacy and IFC) at this point we only set the "static" position assuming that layout eventually reaches the out-of-flow-box's containing block which would set the final top/left coords. However since this layout is bound to layout-boundary's subtree, we never get to the containing-block. While this is an invalidation bug where we fail to mark the containing-block dirty (by not stopping at layout-boundary), it's expensive to figure out if there's a descendent of the layout-boundary with an ancestor containing block (outside of layout-boundary's subtree). Instead set the out-of-flow-box's coordinates here at inline layout and let the containing block update it as part of the normal layout flow (when we actually get to the containing block). This is technically correct since this renderer's position is its static position until the containing block updates it as applicable (and the special "static position" handling could be considered as a render tree artifact). * LayoutTests/fast/block/positioning/static_out_of_flow_inside_layout_boundary-expected.html: Added. * LayoutTests/fast/block/positioning/static_out_of_flow_inside_layout_boundary.html: Added. * Source/WebCore/layout/integration/inline/LayoutIntegrationLineLayout.cpp: (WebCore::LayoutIntegration::LineLayout::updateRenderTreePositions): Canonical link: https://commits.webkit.org/262470@main

…r/backspace/enter combo in long text https://bugs.webkit.org/show_bug.cgi?id=254989 <rdar://problem/108215532> Reviewed by Antti Koivisto. This bugs caused by an incorrectly computed (damaged) line index which caused us exiting inline layout too early (and not producing content for the new newline). With partial layout we 1. first compute the damaged line index which is the entry point for the subsequent inline layout. 2. run inline layout until we see no change in generated display boxes anymore (in many cases the damage only affects a range of lines and not the full set) With the following content: First line 1\n Second line 2\n Third line 3\n When a new \n is inserted between the last \n and [3], we compute the damage position by looking at the _start_ of the previous sibling. In this case the previous sibling is "First line 1\nSecond line 2\nThird line 3\n" which means we damage the content starting from line #0. The subsequent inline layout starts generating display boxes starting from line #0 and bails out at the end of line #1 since the set of display boxes are getting generated match what we had before. This fix ensures that when we insert some content, the damaged line index is computed based on the insertion point (end of the previous sibling). * Source/WebCore/layout/formattingContexts/inline/invalidation/InlineInvalidation.cpp: (WebCore::Layout::damagedLineIndex): (WebCore::Layout::inlineItemPositionForDamagedContentPosition): (WebCore::Layout::InlineInvalidation::textInserted): (WebCore::Layout::InlineInvalidation::inlineLevelBoxInserted): Canonical link: https://commits.webkit.org/263113@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

Fix typo in domain.endsWith() check for hulu.com

06a0abc

Missing period before the subdomain.

JonWBedard closed this Feb 17, 2021

gezalore pushed a commit to gezalore/WebKit that referenced this pull request Jan 17, 2022

Merge pull request WebKit#1 from gezalore/wasm32-asm-improvements

647a83c

Improvements to LLInt offlineasm

brandonmcconnell mentioned this pull request Dec 9, 2022

CSS ::marker does not support defining CSS variables #7376

Merged

MenloDorian mentioned this pull request Aug 2, 2023

[JSC] Add op_call_ignore_result #15127

Merged

alanbaradlay mentioned this pull request Jan 15, 2024

Replaced elements avoid floats, including check boxes and radio boxes when turned into block box #22762

Merged

alanbaradlay mentioned this pull request Feb 14, 2024

[content-visibility] Improve performance of grid based perf tests #18401

Open

alanbaradlay mentioned this pull request Apr 8, 2024

Interaction Regions generation should get geometry from the RenderTree #26971

Merged

jesxilin mentioned this pull request Oct 10, 2024

gmail.com: [iPad] Tapping the file icon when composing an email brings up the keyboard #34957

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Fix typo in domain.endsWith() check for hulu.com#1

Fix typo in domain.endsWith() check for hulu.com#1
berelig wants to merge 1 commit into
WebKit:mainfrom
berelig:patch-1

berelig commented Feb 17, 2021 •

edited

Loading

Uh oh!

JonWBedard commented Feb 17, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

berelig commented Feb 17, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

JonWBedard commented Feb 17, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

berelig commented Feb 17, 2021 •

edited

Loading