{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":480821329,"defaultBranch":"main","name":"WebKit","ownerLogin":"mcatanzaro","currentUserCanPush":false,"isFork":true,"isEmpty":false,"createdAt":"2022-04-12T13:25:25.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/1424966?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1726158428.0","currentOid":""},"activityList":{"items":[{"before":"466645a2ea42d073d5ef94f1a2b12170bf4d49f7","after":"7fc0633735e48f1067d6f3e8be078417b056b36d","ref":"refs/heads/eng/GTK-webkit_settings_set_enable_2d_canvas_acceleration-fails-on-s390x","pushedAt":"2024-09-13T15:54:29.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mcatanzaro","name":"Michael Catanzaro","path":"/mcatanzaro","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1424966?s=80&v=4"},"commit":{"message":"[GTK] webkit_settings_set_enable_2d_canvas_acceleration fails on s390x\nhttps://bugs.webkit.org/show_bug.cgi?id=279220\n\nReviewed by NOBODY (OOPS!).\n\nCairo doesn't support hardware acceleration. (Too bad for Windows and\nPlayStation and s390x!) So this setting only makes sense when Skia is\nused, or on Apple platforms.\n\n* Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml:","shortMessageHtmlLink":"[GTK] webkit_settings_set_enable_2d_canvas_acceleration fails on s390x"}},{"before":"e4d5fc8e99945e2e1e6aed054d54fddb399c1a47","after":"d73923de96990ce46d3ed5fdde2fdf113a189443","ref":"refs/heads/main","pushedAt":"2024-09-13T15:54:25.000Z","pushType":"push","commitsCount":52,"pusher":{"login":"mcatanzaro","name":"Michael Catanzaro","path":"/mcatanzaro","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1424966?s=80&v=4"},"commit":{"message":"[JSC] Make double constant materialization better\nhttps://bugs.webkit.org/show_bug.cgi?id=279615\nrdar://135908300\n\nReviewed by Keith Miller.\n\nThis change is preparation for the further FP related optimizations, but\nlet's first clean up things to make them better. This patch makes double\nconstant materialization better for our CPUs.\n\n* Source/JavaScriptCore/assembler/ARM64Assembler.h:\n(JSC::ARM64Assembler::canEncodeFPImm):\n(JSC::ARM64Assembler::encodeFPImm):\n* Source/JavaScriptCore/assembler/AbstractMacroAssembler.h:\n* Source/JavaScriptCore/assembler/AssemblerCommon.h:\n(JSC::ARM64FPImmediate::create64):\n(JSC::ARM64FPImmediate::isValid const):\n(JSC::ARM64FPImmediate::value const):\n(JSC::ARM64FPImmediate::ARM64FPImmediate):\n* Source/JavaScriptCore/assembler/MacroAssembler.h:\n(JSC::MacroAssembler::move32ToFloat):\n(JSC::MacroAssembler::move64ToDouble):\n* Source/JavaScriptCore/assembler/MacroAssemblerARM64.h:\n(JSC::MacroAssemblerARM64::move64ToDouble):\n(JSC::MacroAssemblerARM64::move32ToFloat):\n* Source/JavaScriptCore/assembler/MacroAssemblerARMv7.h:\n(JSC::MacroAssemblerARMv7::move32ToFloat):\n(JSC::MacroAssemblerARMv7::move64ToDouble):\n* Source/JavaScriptCore/assembler/MacroAssemblerRISCV64.h:\n(JSC::MacroAssemblerRISCV64::move32ToFloat):\n(JSC::MacroAssemblerRISCV64::move64ToDouble):\n* Source/JavaScriptCore/assembler/MacroAssemblerX86_64.h:\n(JSC::MacroAssemblerX86_64::absDouble):\n(JSC::MacroAssemblerX86_64::move32ToFloat):\n(JSC::MacroAssemblerX86_64::move64ToDouble):\n* Source/JavaScriptCore/b3/B3LowerToAir.cpp:\n* Source/JavaScriptCore/b3/B3MoveConstants.cpp:\n* Source/JavaScriptCore/b3/air/AirArg.cpp:\n(JSC::B3::Air::Arg::jsHash const):\n(JSC::B3::Air::Arg::dump const):\n(WTF::printInternal):\n* Source/JavaScriptCore/b3/air/AirArg.h:\n(JSC::B3::Air::Arg::fpImm32):\n(JSC::B3::Air::Arg::fpImm64):\n(JSC::B3::Air::Arg::isFPImm32 const):\n(JSC::B3::Air::Arg::isFPImm64 const):\n(JSC::B3::Air::Arg::isSomeImm const):\n(JSC::B3::Air::Arg::isGP const):\n(JSC::B3::Air::Arg::isFP const):\n(JSC::B3::Air::Arg::isValidFPImm32Form):\n(JSC::B3::Air::Arg::isValidFPImm64Form):\n(JSC::B3::Air::Arg::isValidForm const):\n(JSC::B3::Air::Arg::asTrustedImm32 const):\n(JSC::B3::Air::Arg::asTrustedImm64 const):\n* Source/JavaScriptCore/b3/air/AirOpcode.opcodes:\n* Source/JavaScriptCore/b3/air/opcode_generator.rb:\n* Source/JavaScriptCore/b3/testb3.h:\n* Source/JavaScriptCore/b3/testb3_1.cpp:\n(run):\n* Source/JavaScriptCore/b3/testb3_7.cpp:\n(testSimpleTuplePairUnused):\n* Source/JavaScriptCore/b3/testb3_8.cpp:\n(testConstDoubleMove):\n(testConstFloatMove):\n* Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp:\n(JSC::DFG::SpeculativeJIT::silentFillImpl):\n(JSC::DFG::SpeculativeJIT::compileDoubleRep):\n(JSC::DFG::compileClampDoubleToByte):\n* Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp:\n(JSC::DFG::SpeculativeJIT::compileGetByVal):\n(JSC::DFG::SpeculativeJIT::compileDateGet):\n(JSC::DFG::SpeculativeJIT::compileDateSet):\n* Source/JavaScriptCore/jit/AssemblyHelpers.cpp:\n(JSC::AssemblyHelpers::purifyNaN):\n* Source/JavaScriptCore/jit/ThunkGenerators.cpp:\n(JSC::roundThunkGenerator):\n* Source/JavaScriptCore/wasm/WasmBBQJIT64.cpp:\n(JSC::Wasm::BBQJITImpl::BBQJIT::emitMoveConst):\n\nCanonical link: https://commits.webkit.org/283626@main","shortMessageHtmlLink":"[JSC] Make double constant materialization better"}},{"before":"3e57fce257b087a820536bb5a33d63e3a0ab42d7","after":"82ac7fe3f7c58086b0b2c9a7b051fdce1872cbac","ref":"refs/heads/eng/Breaks-debugedit-on-ppc64le","pushedAt":"2024-09-12T20:12:22.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mcatanzaro","name":"Michael Catanzaro","path":"/mcatanzaro","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1424966?s=80&v=4"},"commit":{"message":"REGRESSION(282934@main): Breaks debugedit when built with GCC\nhttps://bugs.webkit.org/show_bug.cgi?id=279360\n\nReviewed by NOBODY (OOPS!).\n\nThis change breaks distro builds with GCC, but doesn't seem to cause\nproblems with Clang for unknown reason. So let's try limiting it to\nClang for now.\n\n* Source/cmake/WebKitCompilerFlags.cmake:","shortMessageHtmlLink":"REGRESSION(282934@main): Breaks debugedit when built with GCC"}},{"before":"89e4e8c7ae470b1d75956ad73036fd7702e29a55","after":"e4d5fc8e99945e2e1e6aed054d54fddb399c1a47","ref":"refs/heads/main","pushedAt":"2024-09-12T20:12:18.000Z","pushType":"push","commitsCount":18,"pusher":{"login":"mcatanzaro","name":"Michael Catanzaro","path":"/mcatanzaro","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1424966?s=80&v=4"},"commit":{"message":"[scroll-animations] Move some functions from DocumentTimeline to AnimationTimeline\nhttps://bugs.webkit.org/show_bug.cgi?id=279466\nrdar://135748611\n\nReviewed by Antoine Quint.\n\nMove some functions on DocumentTimeline to the AnimationTimeline superclass.\n\n* Source/WebCore/animation/AnimationTimeline.cpp:\n(WebCore::AnimationTimeline::detachFromDocument):\n(WebCore::AnimationTimeline::suspendAnimations):\n(WebCore::AnimationTimeline::resumeAnimations):\n(WebCore::AnimationTimeline::animationsAreSuspended const):\n* Source/WebCore/animation/AnimationTimeline.h:\n(WebCore::AnimationTimeline::documentWillUpdateAnimationsAndSendEvents):\n(WebCore::AnimationTimeline::controller const):\n* Source/WebCore/animation/DocumentTimeline.cpp:\n(WebCore::DocumentTimeline::detachFromDocument):\n(WebCore::DocumentTimeline::suspendAnimations):\n(WebCore::DocumentTimeline::resumeAnimations):\n(WebCore::DocumentTimeline::animationsAreSuspended const): Deleted.\n* Source/WebCore/animation/DocumentTimeline.h:\n* Source/WebCore/animation/ScrollTimeline.cpp:\n(WebCore::ScrollTimeline::ScrollTimeline):\n(WebCore::ScrollTimeline::controller const):\n* Source/WebCore/animation/ScrollTimeline.h:\n* Source/WebCore/animation/ViewTimeline.cpp:\n(WebCore::ViewTimeline::ViewTimeline):\n\nCanonical link: https://commits.webkit.org/283574@main","shortMessageHtmlLink":"[scroll-animations] Move some functions from DocumentTimeline to Anim…"}},{"before":null,"after":"466645a2ea42d073d5ef94f1a2b12170bf4d49f7","ref":"refs/heads/eng/GTK-webkit_settings_set_enable_2d_canvas_acceleration-fails-on-s390x","pushedAt":"2024-09-12T16:27:08.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"mcatanzaro","name":"Michael Catanzaro","path":"/mcatanzaro","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1424966?s=80&v=4"},"commit":{"message":"[GTK] webkit_settings_set_enable_2d_canvas_acceleration fails on s390x\nhttps://bugs.webkit.org/show_bug.cgi?id=279220\n\nReviewed by NOBODY (OOPS!).\n\nCairo doesn't support hardware acceleration. (Too bad for Windows and\nPlayStation and s390x!) So this setting only makes sense when Skia is\nused, or on Apple platforms.\n\n* Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml:","shortMessageHtmlLink":"[GTK] webkit_settings_set_enable_2d_canvas_acceleration fails on s390x"}},{"before":"1f3590659941050bfd206da7714d34209ce4309a","after":"89e4e8c7ae470b1d75956ad73036fd7702e29a55","ref":"refs/heads/main","pushedAt":"2024-09-12T16:27:04.000Z","pushType":"push","commitsCount":125,"pusher":{"login":"mcatanzaro","name":"Michael Catanzaro","path":"/mcatanzaro","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1424966?s=80&v=4"},"commit":{"message":"Remove local `autofocus` tests in favor of WPT\nhttps://bugs.webkit.org/show_bug.cgi?id=279590\nrdar://135867353\n\nReviewed by Antoine Quint.\n\nThis patch removes local tests which were uploaded to WPT by Blink / Chromium,\nin following commits [1] & [2]:\n\n[1] https://github.com/web-platform-tests/wpt/pull/22133\n[2] https://chromium-review.googlesource.com/c/chromium/src/+/2094058\n\nThe test replacing below is named `no-autofocus-on-changing-input-type.html`,\nit is present in our tree and passes on all platforms.\n\n* LayoutTests/fast/forms/autofocus-focus-only-once-expected.txt: Removed.\n* LayoutTests/fast/forms/autofocus-focus-only-once.html: Removed.\n* LayoutTests/fast/forms/autofocus-opera-001-expected.txt: Removed.\n* LayoutTests/fast/forms/autofocus-opera-001.html: Removed.\n* LayoutTests/fast/forms/autofocus-opera-006-expected.txt: Removed.\n* LayoutTests/fast/forms/autofocus-opera-006.html: Removed.\n* LayoutTests/fast/forms/autofocus-opera-008-expected.txt: Removed.\n* LayoutTests/fast/forms/autofocus-opera-008.html: Removed.\n\nCanonical link: https://commits.webkit.org/283556@main","shortMessageHtmlLink":"Remove local <code>autofocus</code> tests in favor of WPT"}},{"before":"4e4f3ee106b780688cce1bb754af44a3a7d00bbb","after":"3e57fce257b087a820536bb5a33d63e3a0ab42d7","ref":"refs/heads/eng/Breaks-debugedit-on-ppc64le","pushedAt":"2024-09-10T18:56:40.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mcatanzaro","name":"Michael Catanzaro","path":"/mcatanzaro","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1424966?s=80&v=4"},"commit":{"message":"REGRESSION(282934@main): Breaks debugedit on ppc64le\nhttps://bugs.webkit.org/show_bug.cgi?id=279360\n\nReviewed by NOBODY (OOPS!).\n\nThis change breaks distro builds with GCC, but doesn't seem to cause\nproblems with Clang for unknown reason. So let's try limiting it to\nClang for now.\n\n* Source/cmake/WebKitCompilerFlags.cmake:","shortMessageHtmlLink":"REGRESSION(282934@main): Breaks debugedit on ppc64le"}},{"before":"cf8f5f540b30716eb35ed55b7ea1fc6ca78534c1","after":"1f3590659941050bfd206da7714d34209ce4309a","ref":"refs/heads/main","pushedAt":"2024-09-10T18:56:37.000Z","pushType":"push","commitsCount":17,"pusher":{"login":"mcatanzaro","name":"Michael Catanzaro","path":"/mcatanzaro","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1424966?s=80&v=4"},"commit":{"message":"Fix the compilation error for appletv simulator in intel-based mac\nhttps://bugs.webkit.org/show_bug.cgi?id=278905\n\nReviewed by Elliott Williams.\n\nexclude files related to SSE feature for appletv simulator build\n\n* Source/ThirdParty/libwebrtc/Configurations/Base-libvpx.xcconfig:\n* Source/ThirdParty/libwebrtc/Configurations/libaom.xcconfig:\n* Source/ThirdParty/libwebrtc/Configurations/libvpx.xcconfig:\n* Source/ThirdParty/libwebrtc/Configurations/opus.xcconfig:\n\nCanonical link: https://commits.webkit.org/283431@main","shortMessageHtmlLink":"Fix the compilation error for appletv simulator in intel-based mac"}},{"before":"fed652453c69e9411a127f046e22e381552ced40","after":"adb151280709f971608c6d55c946aceb96222401","ref":"refs/heads/eng/Crash-when-running-under-flatpak-without-installed-flatpak-as-by-run-minibrowser-script","pushedAt":"2024-09-10T15:58:31.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"webkit-commit-queue","name":"Commit Queue","path":"/webkit-commit-queue","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/77073439?s=80&v=4"},"commit":{"message":"Unreviewed, reverting 283361@main (9fc6b8810c52)\nhttps://bugs.webkit.org/show_bug.cgi?id=279446\n\nCrash when running under flatpak without installed flatpak, as by run-minibrowser script\n\nI was hoping our scripts don't do this anymore. Wrong.\n\nReverted change:\n\n    [WPE][GTK] when flatpak sandbox unavailable, processes are run unsandboxed with no warning\n    https://bugs.webkit.org/show_bug.cgi?id=278578\n    283361@main (9fc6b8810c52)\n\nCanonical link: https://commits.webkit.org/283415@main","shortMessageHtmlLink":"Unreviewed, reverting 283361@main (<a class=\"commit-link\" data-hovercard-type=\"commit\" data-hovercard-url=\"https://github.com/mcatanzaro/WebKit/commit/9fc6b8810c5244dc3acfe90ee9962b9706b637cb/hovercard\" href=\"https://github.com/mcatanzaro/WebKit/commit/9fc6b8810c5244dc3acfe90ee9962b9706b637cb\"><tt>9fc6b88</tt></a>)"}},{"before":null,"after":"fed652453c69e9411a127f046e22e381552ced40","ref":"refs/heads/eng/Crash-when-running-under-flatpak-without-installed-flatpak-as-by-run-minibrowser-script","pushedAt":"2024-09-10T15:56:07.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"mcatanzaro","name":"Michael Catanzaro","path":"/mcatanzaro","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1424966?s=80&v=4"},"commit":{"message":"Unreviewed, reverting 283361@main (9fc6b8810c52)\nhttps://bugs.webkit.org/show_bug.cgi?id=279446\n\nCrash when running under flatpak without installed flatpak, as by run-minibrowser script\n\nI was hoping our scripts don't do this anymore. Wrong.\n\nReverted change:\n\n    [WPE][GTK] when flatpak sandbox unavailable, processes are run unsandboxed with no warning\n    https://bugs.webkit.org/show_bug.cgi?id=278578\n    283361@main (9fc6b8810c52)","shortMessageHtmlLink":"Unreviewed, reverting 283361@main (<a class=\"commit-link\" data-hovercard-type=\"commit\" data-hovercard-url=\"https://github.com/mcatanzaro/WebKit/commit/9fc6b8810c5244dc3acfe90ee9962b9706b637cb/hovercard\" href=\"https://github.com/mcatanzaro/WebKit/commit/9fc6b8810c5244dc3acfe90ee9962b9706b637cb\"><tt>9fc6b88</tt></a>)"}},{"before":"f5cd6dd027cac497f6bb2035a093b66f6234a257","after":"cf8f5f540b30716eb35ed55b7ea1fc6ca78534c1","ref":"refs/heads/main","pushedAt":"2024-09-10T15:56:03.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"mcatanzaro","name":"Michael Catanzaro","path":"/mcatanzaro","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1424966?s=80&v=4"},"commit":{"message":"REGRESSION(281488@main): [WPE][GTK] Process launching is slow\nhttps://bugs.webkit.org/show_bug.cgi?id=279026\n\nReviewed by Carlos Garcia Campos and Adrian Perez de Castro.\n\nProcessLauncher is already designed to support asynchronous process\nlaunching, but the GLib implementation ignores this and does everything\nsynchronously. Previously this was OK because\nProcessLauncher::launchProcess would return immediately after the\nsubprocess is spawned, without waiting for any code to execute in the\nsubprocess. Apparently that's fast enough in practice. But after my\nchanges in 281488@main, we now additionally wait for the subprocess to\nsend credentials to the parent via a socket. That turns out to be\ndrastically slower than actually spawning the process.\n\nThe blocking is unnecessary because the code was already carefully\nstructured to allow asynchronicity. I just failed to take advantage of\nit.\n\nInstead, return immediately after spawning the subprocess. Then, wait\nuntil the socket is ready before reading the pid from it. Now the read\ncan complete instantaneously instead of blocking the UI process.\n\n* Source/WebKit/UIProcess/Launcher/ProcessLauncher.h:\n* Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp:\n(WebKit::ProcessLauncher::launchProcess):\n\nCanonical link: https://commits.webkit.org/283414@main","shortMessageHtmlLink":"REGRESSION(281488@main): [WPE][GTK] Process launching is slow"}},{"before":"9fc6b8810c5244dc3acfe90ee9962b9706b637cb","after":null,"ref":"refs/heads/eng/WPEGTK-when-flatpak-sandbox-unavailable-processes-are-run-unsandboxed-with-no-warning","pushedAt":"2024-09-10T15:30:19.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"mcatanzaro","name":"Michael Catanzaro","path":"/mcatanzaro","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1424966?s=80&v=4"}},{"before":"57684499be6f0e67461b7958db031759f4d56798","after":"cf8f5f540b30716eb35ed55b7ea1fc6ca78534c1","ref":"refs/heads/eng/REGRESSION281488main-Process-launching-is-slow-under-flatpak","pushedAt":"2024-09-10T15:29:29.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"webkit-commit-queue","name":"Commit Queue","path":"/webkit-commit-queue","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/77073439?s=80&v=4"},"commit":{"message":"REGRESSION(281488@main): [WPE][GTK] Process launching is slow\nhttps://bugs.webkit.org/show_bug.cgi?id=279026\n\nReviewed by Carlos Garcia Campos and Adrian Perez de Castro.\n\nProcessLauncher is already designed to support asynchronous process\nlaunching, but the GLib implementation ignores this and does everything\nsynchronously. Previously this was OK because\nProcessLauncher::launchProcess would return immediately after the\nsubprocess is spawned, without waiting for any code to execute in the\nsubprocess. Apparently that's fast enough in practice. But after my\nchanges in 281488@main, we now additionally wait for the subprocess to\nsend credentials to the parent via a socket. That turns out to be\ndrastically slower than actually spawning the process.\n\nThe blocking is unnecessary because the code was already carefully\nstructured to allow asynchronicity. I just failed to take advantage of\nit.\n\nInstead, return immediately after spawning the subprocess. Then, wait\nuntil the socket is ready before reading the pid from it. Now the read\ncan complete instantaneously instead of blocking the UI process.\n\n* Source/WebKit/UIProcess/Launcher/ProcessLauncher.h:\n* Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp:\n(WebKit::ProcessLauncher::launchProcess):\n\nCanonical link: https://commits.webkit.org/283414@main","shortMessageHtmlLink":"REGRESSION(281488@main): [WPE][GTK] Process launching is slow"}},{"before":"d95ef65e3ac291b732f66b460e4b6bb0e1888b22","after":"57684499be6f0e67461b7958db031759f4d56798","ref":"refs/heads/eng/REGRESSION281488main-Process-launching-is-slow-under-flatpak","pushedAt":"2024-09-10T14:58:13.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mcatanzaro","name":"Michael Catanzaro","path":"/mcatanzaro","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1424966?s=80&v=4"},"commit":{"message":"REGRESSION(281488@main): [WPE][GTK] Process launching is slow\nhttps://bugs.webkit.org/show_bug.cgi?id=279026\n\nReviewed by NOBODY (OOPS!).\n\nProcessLauncher is already designed to support asynchronous process\nlaunching, but the GLib implementation ignores this and does everything\nsynchronously. Previously this was OK because\nProcessLauncher::launchProcess would return immediately after the\nsubprocess is spawned, without waiting for any code to execute in the\nsubprocess. Apparently that's fast enough in practice. But after my\nchanges in 281488@main, we now additionally wait for the subprocess to\nsend credentials to the parent via a socket. That turns out to be\ndrastically slower than actually spawning the process.\n\nThe blocking is unnecessary because the code was already carefully\nstructured to allow asynchronicity. I just failed to take advantage of\nit.\n\nInstead, return immediately after spawning the subprocess. Then, wait\nuntil the socket is ready before reading the pid from it. Now the read\ncan complete instantaneously instead of blocking the UI process.\n\n* Source/WebKit/UIProcess/Launcher/ProcessLauncher.h:\n* Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp:\n(WebKit::ProcessLauncher::launchProcess):","shortMessageHtmlLink":"REGRESSION(281488@main): [WPE][GTK] Process launching is slow"}},{"before":"b885e58db7caa2dda66424b9eca8476f58ea0cbe","after":"f5cd6dd027cac497f6bb2035a093b66f6234a257","ref":"refs/heads/main","pushedAt":"2024-09-10T14:58:09.000Z","pushType":"push","commitsCount":61,"pusher":{"login":"mcatanzaro","name":"Michael Catanzaro","path":"/mcatanzaro","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1424966?s=80&v=4"},"commit":{"message":"[GStreamer] Build fails with GST_DISABLE_GST_DEBUG and -Werror=unused\nhttps://bugs.webkit.org/show_bug.cgi?id=279435\n\nReviewed by Philippe Normand.\n\nAdd [[maybe_unused]]'s and #ifndef guards where missing.\n\n* Source/WebCore/Modules/mediastream/gstreamer/GStreamerDataChannelHandler.cpp:\n(WebCore::GStreamerDataChannelHandler::onMessageData):\n* Source/WebCore/Modules/mediastream/gstreamer/GStreamerPeerConnectionBackend.cpp:\n(WebCore::GStreamerPeerConnectionBackend::GStreamerPeerConnectionBackend):\n(WebCore::GStreamerPeerConnectionBackend::~GStreamerPeerConnectionBackend):\n* Source/WebCore/platform/audio/gstreamer/AudioDecoderGStreamer.cpp:\n(WebCore::GStreamerInternalAudioDecoder::decode):\n* Source/WebCore/platform/audio/gstreamer/AudioDestinationGStreamer.cpp:\n(WebCore::AudioDestinationGStreamer::notifyStartupResult):\n(WebCore::AudioDestinationGStreamer::notifyStopResult):\n* Source/WebCore/platform/audio/gstreamer/PlatformRawAudioDataGStreamer.cpp:\n(WebCore::PlatformRawAudioData::copyTo):\n* Source/WebCore/platform/graphics/gstreamer/GStreamerCommon.cpp:\n(WebCore::webkitGstSetElementStateSynchronously):\n* Source/WebCore/platform/graphics/gstreamer/GStreamerRegistryScanner.cpp:\n(WebCore::GStreamerRegistryScanner::isCodecSupported const):\n(WebCore::GStreamerRegistryScanner::configurationNameForLogging const):\n(WebCore::GStreamerRegistryScanner::isConfigurationSupported const):\n* Source/WebCore/platform/graphics/gstreamer/GStreamerRegistryScanner.h:\n* Source/WebCore/platform/graphics/gstreamer/GStreamerSinksWorkarounds.cpp:\n(WebCore::AppSinkFlushCapsWorkaroundProbe::probe):\n* Source/WebCore/platform/graphics/gstreamer/GStreamerVideoSinkCommon.cpp:\n(WebKitVideoSinkProbe::doProbe):\n(webKitVideoSinkSetMediaPlayerPrivate):\n* Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:\n(WebCore::MediaPlayerPrivateGStreamer::MediaPlayerPrivateGStreamer):\n(WebCore::MediaPlayerPrivateGStreamer::mediaPlayerWillBeDestroyed):\n(WebCore::MediaPlayerPrivateGStreamer::updateTracks):\n(WebCore::MediaPlayerPrivateGStreamer::handleMessage):\n(WebCore::MediaPlayerPrivateGStreamer::updateVideoOrientation):\n(WebCore::MediaPlayerPrivateGStreamer::attemptToDecryptWithInstance):\n(WebCore::MediaPlayerPrivateGStreamer::attemptToDecryptWithLocalInstance):\n(WebCore::MediaPlayerPrivateGStreamer::supportsKeySystem):\n* Source/WebCore/platform/graphics/gstreamer/VideoEncoderGStreamer.cpp:\n(WebCore::retrieveTemporalIndex):\n* Source/WebCore/platform/graphics/gstreamer/WebKitWebSourceGStreamer.cpp:\n(webkitWebSrcReset):\n(stopLoaderIfNeeded):\n(CachedResourceStreamingClient::dataReceived):\n* Source/WebCore/platform/graphics/gstreamer/mse/AppendPipeline.cpp:\n(WebCore::AppendPipeline::handleErrorSyncMessage):\n(WebCore::AppendPipeline::consumeAppsinksAvailableSamples):\n(WebCore::createOptionalParserForFormat):\n(WebCore::appendPipelineAppsinkPadEventProbe):\n(WebCore::appendPipelineDemuxerBlackHolePadProbe):\n* Source/WebCore/platform/graphics/gstreamer/mse/MediaPlayerPrivateGStreamerMSE.cpp:\n* Source/WebCore/platform/graphics/gstreamer/mse/MediaPlayerPrivateGStreamerMSE.h:\n* Source/WebCore/platform/graphics/gstreamer/mse/WebKitMediaSourceGStreamer.cpp:\n(dumpPipeline):\n(webKitMediaSrcActivateMode):\n(webKitMediaSrcLoop):\n* Source/WebCore/platform/gstreamer/GStreamerElementHarness.cpp:\n(WebCore::GStreamerElementHarness::GStreamerElementHarness):\n* Source/WebCore/platform/gstreamer/VideoEncoderPrivateGStreamer.cpp:\n(videoEncoderFindForFormat):\n* Source/WebCore/platform/mediarecorder/MediaRecorderPrivateGStreamer.cpp:\n(WebCore::MediaRecorderPrivateBackend::preparePipeline):\n* Source/WebCore/platform/mediastream/gstreamer/GStreamerMediaStreamSource.cpp:\n(webkitMediaStreamSrcPadProbeCb):\n(webkitMediaStreamSrcCharacteristicsChanged):\n* Source/WebCore/platform/mediastream/gstreamer/GStreamerMockDevice.cpp:\n(webkitMockDeviceCreateElement):\n* Source/WebCore/platform/mediastream/gstreamer/GStreamerMockDeviceProvider.cpp:\n(webkitMockDeviceProviderProbe):\n\nCanonical link: https://commits.webkit.org/283413@main","shortMessageHtmlLink":"[GStreamer] Build fails with GST_DISABLE_GST_DEBUG and -Werror=unused"}},{"before":"f17f9b371c865ee9d2460705cba488257e2eb67d","after":"9fc6b8810c5244dc3acfe90ee9962b9706b637cb","ref":"refs/heads/eng/WPEGTK-when-flatpak-sandbox-unavailable-processes-are-run-unsandboxed-with-no-warning","pushedAt":"2024-09-09T20:25:21.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"webkit-commit-queue","name":"Commit Queue","path":"/webkit-commit-queue","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/77073439?s=80&v=4"},"commit":{"message":"[WPE][GTK] when flatpak sandbox unavailable, processes are run unsandboxed with no warning\nhttps://bugs.webkit.org/show_bug.cgi?id=278578\n\nReviewed by Carlos Garcia Campos.\n\nIf we're running under flatpak, but flatpak-spawn doesn't work, it's\nprobably better to crash rather than continue to run unsandboxed. This\nprobably indicates a developer is experimenting, but it could be serious\nif it happens by accident for an end user.\n\n* Source/WebKit/UIProcess/Launcher/glib/FlatpakLauncher.cpp:\n(WebKit::isFlatpakSpawnUsable):\n(WebKit::flatpakSpawn):\n* Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp:\n(WebKit::ProcessLauncher::launchProcess):\n(WebKit::isFlatpakSpawnUsable): Deleted.\n\nCanonical link: https://commits.webkit.org/283361@main","shortMessageHtmlLink":"[WPE][GTK] when flatpak sandbox unavailable, processes are run unsand…"}},{"before":"1aad9402dadf1d2d525b348905652a49080f6023","after":"f17f9b371c865ee9d2460705cba488257e2eb67d","ref":"refs/heads/eng/WPEGTK-when-flatpak-sandbox-unavailable-processes-are-run-unsandboxed-with-no-warning","pushedAt":"2024-09-09T18:22:16.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mcatanzaro","name":"Michael Catanzaro","path":"/mcatanzaro","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1424966?s=80&v=4"},"commit":{"message":"[WPE][GTK] when flatpak sandbox unavailable, processes are run unsandboxed with no warning\nhttps://bugs.webkit.org/show_bug.cgi?id=278578\n\nReviewed by NOBODY (OOPS!).\n\nIf we're running under flatpak, but flatpak-spawn doesn't work, it's\nprobably better to crash rather than continue to run unsandboxed. This\nprobably indicates a developer is experimenting, but it could be serious\nif it happens by accident for an end user.\n\n* Source/WebKit/UIProcess/Launcher/glib/FlatpakLauncher.cpp:\n(WebKit::isFlatpakSpawnUsable):\n(WebKit::flatpakSpawn):\n* Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp:\n(WebKit::ProcessLauncher::launchProcess):\n(WebKit::isFlatpakSpawnUsable): Deleted.","shortMessageHtmlLink":"[WPE][GTK] when flatpak sandbox unavailable, processes are run unsand…"}},{"before":"dc2ff129ed4c2566fdfe85d717fd73c34eb048e8","after":"b885e58db7caa2dda66424b9eca8476f58ea0cbe","ref":"refs/heads/main","pushedAt":"2024-09-09T18:22:12.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"mcatanzaro","name":"Michael Catanzaro","path":"/mcatanzaro","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1424966?s=80&v=4"},"commit":{"message":"[GTK][l10n] Updated Polish translation of WebKitGTK for 2.46\nhttps://bugs.webkit.org/show_bug.cgi?id=279369\n\nUnreviewed translation update.\n\n* Source/WebCore/platform/gtk/po/pl.po:\n\nCanonical link: https://commits.webkit.org/283352@main","shortMessageHtmlLink":"[GTK][l10n] Updated Polish translation of WebKitGTK for 2.46"}},{"before":"265db9b58637dc8df9bb65e764fd9dc0dd2d7792","after":"b885e58db7caa2dda66424b9eca8476f58ea0cbe","ref":"refs/heads/eng/GTKl10n-Updated-Polish-translation-of-WebKitGTK-for-2-46","pushedAt":"2024-09-09T18:05:25.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"webkit-commit-queue","name":"Commit Queue","path":"/webkit-commit-queue","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/77073439?s=80&v=4"},"commit":{"message":"[GTK][l10n] Updated Polish translation of WebKitGTK for 2.46\nhttps://bugs.webkit.org/show_bug.cgi?id=279369\n\nUnreviewed translation update.\n\n* Source/WebCore/platform/gtk/po/pl.po:\n\nCanonical link: https://commits.webkit.org/283352@main","shortMessageHtmlLink":"[GTK][l10n] Updated Polish translation of WebKitGTK for 2.46"}},{"before":null,"after":"265db9b58637dc8df9bb65e764fd9dc0dd2d7792","ref":"refs/heads/eng/GTKl10n-Updated-Polish-translation-of-WebKitGTK-for-2-46","pushedAt":"2024-09-09T18:03:09.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"mcatanzaro","name":"Michael Catanzaro","path":"/mcatanzaro","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1424966?s=80&v=4"},"commit":{"message":"[GTK][l10n] Updated Polish translation of WebKitGTK for 2.46\nhttps://bugs.webkit.org/show_bug.cgi?id=279369\n\nUnreviewed translation update.\n\n* Source/WebCore/platform/gtk/po/pl.po:","shortMessageHtmlLink":"[GTK][l10n] Updated Polish translation of WebKitGTK for 2.46"}},{"before":"3e491ebe446c1e012371e2180a4d63ae01b20df4","after":"dc2ff129ed4c2566fdfe85d717fd73c34eb048e8","ref":"refs/heads/main","pushedAt":"2024-09-09T18:03:05.000Z","pushType":"push","commitsCount":8,"pusher":{"login":"mcatanzaro","name":"Michael Catanzaro","path":"/mcatanzaro","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1424966?s=80&v=4"},"commit":{"message":"Remove HAVE_UNNOTIFICATIONICON\nhttps://bugs.webkit.org/show_bug.cgi?id=279367\nrdar://135553724\n\nReviewed by Ben Nham.\n\nHAVE(UNNOTIFICATIONICON) is not in use any more. Also remove a duplicate HAVE(FULL_FEATURED_USER_NOTIFICATIONS) since\nthe whole function is guarded.\n\n* Source/WTF/wtf/PlatformHave.h:\n* Source/WebKit/webpushd/WebPushDaemon.mm:\n(WebPushD::WebPushDaemon::showNotification):\n\nCanonical link: https://commits.webkit.org/283351@main","shortMessageHtmlLink":"Remove HAVE_UNNOTIFICATIONICON"}},{"before":"f210f5ec5989c3504e77c1941c06d968f44c6ab5","after":"d95ef65e3ac291b732f66b460e4b6bb0e1888b22","ref":"refs/heads/eng/REGRESSION281488main-Process-launching-is-slow-under-flatpak","pushedAt":"2024-09-09T15:54:23.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mcatanzaro","name":"Michael Catanzaro","path":"/mcatanzaro","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1424966?s=80&v=4"},"commit":{"message":"REGRESSION(281488@main): [WPE][GTK] Process launching is slow\nhttps://bugs.webkit.org/show_bug.cgi?id=279026\n\nReviewed by NOBODY (OOPS!).\n\nProcessLauncher is already designed to support asynchronous process\nlaunching, but the GLib implementation ignores this and does everything\nsynchronously. Previously this was OK because\nProcessLauncher::launchProcess would return immediately after the\nsubprocess is spawned, without waiting for any code to execute in the\nsubprocess. Apparently that's fast enough in practice. But after my\nchanges in 281488@main, we now additionally wait for the subprocess to\nsend credentials to the parent via a socket. That turns out to be\ndrastically slower than actually spawning the process.\n\nThe blocking is unnecessary because the code was already carefully\nstructured to allow asynchronicity. I just failed to take advantage of\nit.\n\nInstead, return immediately after spawning the subprocess. Then, wait\nuntil the socket is ready before reading the pid from it. Now the read\ncan complete instantaneously instead of blocking the UI process.\n\n* Source/WebKit/UIProcess/Launcher/ProcessLauncher.h:\n* Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp:\n(WebKit::ProcessLauncher::launchProcess):","shortMessageHtmlLink":"REGRESSION(281488@main): [WPE][GTK] Process launching is slow"}},{"before":"5b689e6770dcfa551c1f493bcf9d1bee7c79c95c","after":"3e491ebe446c1e012371e2180a4d63ae01b20df4","ref":"refs/heads/main","pushedAt":"2024-09-09T15:54:19.000Z","pushType":"push","commitsCount":3,"pusher":{"login":"mcatanzaro","name":"Michael Catanzaro","path":"/mcatanzaro","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1424966?s=80&v=4"},"commit":{"message":"[Grid][Replaced] Invalidate replaced element grid items when their intrinsic size changes.\nhttps://bugs.webkit.org/show_bug.cgi?id=277093\nrdar://problem/132512032\n\nReviewed by Alan Baradlay.\n\nCurrently we do not invalidate replaced elements which are grid items\nif they are \"constrained.\" Constrained here means that they have a\nspecific width and height along with non-intrinsic min-width and\nmin-height.\n\nFor grid this may not be correct since grid's track sizing algorithm\nmay be influenced by a grid item's intrinsic sizes. The result of the\ngrid track sizing with the updated intrinsic sizes may have an impact\non the final geometry of the grid item.\n\nTo try and recover from this state we can invalidate the renderer and\nits containing block chain so that we rerun layout even if it is\nconstrained.\n\n* LayoutTests/imported/w3c/web-platform-tests/css/css-grid/img-src-changes-expected.html: Added.\n* LayoutTests/imported/w3c/web-platform-tests/css/css-grid/img-src-changes.html: Added.\n* Source/WebCore/rendering/RenderReplaced.cpp:\n(WebCore::RenderReplaced::setNeedsLayoutIfNeededAfterIntrinsicSizeChange):\n\nCanonical link: https://commits.webkit.org/283343@main","shortMessageHtmlLink":"[Grid][Replaced] Invalidate replaced element grid items when their in…"}},{"before":null,"after":"4e4f3ee106b780688cce1bb754af44a3a7d00bbb","ref":"refs/heads/eng/Breaks-debugedit-on-ppc64le","pushedAt":"2024-09-09T14:05:21.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"mcatanzaro","name":"Michael Catanzaro","path":"/mcatanzaro","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1424966?s=80&v=4"},"commit":{"message":"Unreviewed, reverting 282934@main (d2f23775f2b2)\nhttps://bugs.webkit.org/show_bug.cgi?id=279360\n\nBreaks debugedit on ppc64le\n\nReverted change:\n\n    [GTK][WPE] Avoid linker relocation errors on Debug/RelWithDebInfo builds\n    https://bugs.webkit.org/show_bug.cgi?id=278861\n    282934@main (d2f23775f2b2)\n\nPlease see: https://bugzilla.redhat.com/show_bug.cgi?id=2310828","shortMessageHtmlLink":"Unreviewed, reverting 282934@main (<a class=\"commit-link\" data-hovercard-type=\"commit\" data-hovercard-url=\"https://github.com/mcatanzaro/WebKit/commit/d2f23775f2b2a232b47b84123930ef7d3beac391/hovercard\" href=\"https://github.com/mcatanzaro/WebKit/commit/d2f23775f2b2a232b47b84123930ef7d3beac391\"><tt>d2f2377</tt></a>)"}},{"before":"c36b50dac0bc42ba7b8722b1d9fef3f24f19a5da","after":"5b689e6770dcfa551c1f493bcf9d1bee7c79c95c","ref":"refs/heads/main","pushedAt":"2024-09-09T14:05:17.000Z","pushType":"push","commitsCount":55,"pusher":{"login":"mcatanzaro","name":"Michael Catanzaro","path":"/mcatanzaro","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1424966?s=80&v=4"},"commit":{"message":"CSS counter-* should not eagerly evaluate calc()\nhttps://bugs.webkit.org/show_bug.cgi?id=279326\n\nReviewed by Darin Adler.\n\nReplaces eager evaluation of calc() in counter-set, counter-increment, and\ncounter-reset, with storing the primitive value for resolution at style\nbuilding time.\n\nAlso took opportunity to move CSS List and CSS Counter Style consumers\nto their own files.\n\n* LayoutTests/imported/w3c/web-platform-tests/css/css-lists/parsing/counter-increment-valid-expected.txt:\n* LayoutTests/imported/w3c/web-platform-tests/css/css-lists/parsing/counter-increment-valid.html:\n* LayoutTests/imported/w3c/web-platform-tests/css/css-lists/parsing/counter-reset-valid-expected.txt:\n* LayoutTests/imported/w3c/web-platform-tests/css/css-lists/parsing/counter-reset-valid.html:\n* LayoutTests/imported/w3c/web-platform-tests/css/css-lists/parsing/counter-set-valid-expected.txt:\n* LayoutTests/imported/w3c/web-platform-tests/css/css-lists/parsing/counter-set-valid.html:\n* Source/WebCore/Sources.txt:\n* Source/WebCore/WebCore.xcodeproj/project.pbxproj:\n* Source/WebCore/css/CSSCounterStyle.cpp:\n* Source/WebCore/css/CSSCounterStyleRule.cpp:\n* Source/WebCore/css/parser/CSSParserImpl.cpp:\n* Source/WebCore/css/parser/CSSPropertyParserConsumer+CounterStyles.cpp: Added.\n* Source/WebCore/css/parser/CSSPropertyParserConsumer+CounterStyles.h: Added.\n* Source/WebCore/css/parser/CSSPropertyParserConsumer+Lists.cpp: Added.\n* Source/WebCore/css/parser/CSSPropertyParserConsumer+Lists.h: Added.\n* Source/WebCore/css/parser/CSSPropertyParserHelpers.cpp:\n* Source/WebCore/css/parser/CSSPropertyParserHelpers.h:\n* Source/WebCore/css/process-css-properties.py:\n\nCanonical link: https://commits.webkit.org/283340@main","shortMessageHtmlLink":"CSS counter-* should not eagerly evaluate calc()"}},{"before":"77d59360be5946f1f328d3d535c40003cae9767e","after":"f210f5ec5989c3504e77c1941c06d968f44c6ab5","ref":"refs/heads/eng/REGRESSION281488main-Process-launching-is-slow-under-flatpak","pushedAt":"2024-09-07T00:21:42.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mcatanzaro","name":"Michael Catanzaro","path":"/mcatanzaro","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1424966?s=80&v=4"},"commit":{"message":"REGRESSION(281488@main): [WPE][GTK] Process launching is slow\nhttps://bugs.webkit.org/show_bug.cgi?id=279026\n\nReviewed by NOBODY (OOPS!).\n\nProcessLauncher is already designed to support asynchronous process\nlaunching, but the GLib implementation ignores this and does everything\nsynchronously. Previously this was OK because\nProcessLauncher::launchProcess would return immediately after the\nsubprocess is spawned, without waiting for any code to execute in the\nsubprocess. Apparently that's fast enough in practice. But after my\nchanges in 281488@main, we now additionally wait for the subprocess to\nsend credentials to the parent via a socket. That turns out to be\ndrastically slower than actually spawning the process.\n\nThe blocking is unnecessary because the code was already carefully\nstructured to allow asynchronicity. I just failed to take advantage of\nit.\n\nInstead, return immediately after spawning the subprocess. Then, wait\nuntil the socket is ready before reading the pid from it. Now the read\ncan complete instantaneously instead of blocking the UI process.\n\n* Source/WebKit/UIProcess/Launcher/ProcessLauncher.h:\n* Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp:\n(WebKit::ProcessLauncher::launchProcess):","shortMessageHtmlLink":"REGRESSION(281488@main): [WPE][GTK] Process launching is slow"}},{"before":"7ac32942fc9f834f88dcad3d4389a69ce7bf6b0a","after":"77d59360be5946f1f328d3d535c40003cae9767e","ref":"refs/heads/eng/REGRESSION281488main-Process-launching-is-slow-under-flatpak","pushedAt":"2024-09-07T00:17:42.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mcatanzaro","name":"Michael Catanzaro","path":"/mcatanzaro","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1424966?s=80&v=4"},"commit":{"message":"REGRESSION(281488@main): [WPE][GTK] Process launching is slow\nhttps://bugs.webkit.org/show_bug.cgi?id=279026\n\nReviewed by NOBODY (OOPS!).\n\nProcessLauncher is already designed to support asynchronous process\nlaunching, but the GLib implementation ignores this and does everything\nsynchronously. Previously this was OK because\nProcessLauncher::launchProcess would return immediately after the\nsubprocess is spawned, without waiting for any code to execute in the\nsubprocess. Apparently that's fast enough in practice. But after my\nchanges in 281488@main, we now additionally wait for the subprocess to\nsend credentials to the parent via a socket. That turns out to be\ndrastically slower than actually spawning the process.\n\nThe blocking is unnecessary because the code was already carefully\nstructured to allow asynchronicity. I just failed to take advantage of\nit.\n\nInstead, return immediately after spawning the subprocess. Then, wait\nuntil the socket is ready before reading the pid from it. Now the read\ncan complete instantaneously instead of blocking the UI process.\n\n* Source/WebKit/UIProcess/Launcher/ProcessLauncher.h:\n* Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp:\n(WebKit::ProcessLauncher::launchProcess):","shortMessageHtmlLink":"REGRESSION(281488@main): [WPE][GTK] Process launching is slow"}},{"before":"68a3b45e05acd500f4035ac8b89bc5afd7aefac0","after":"7ac32942fc9f834f88dcad3d4389a69ce7bf6b0a","ref":"refs/heads/eng/REGRESSION281488main-Process-launching-is-slow-under-flatpak","pushedAt":"2024-09-07T00:16:54.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mcatanzaro","name":"Michael Catanzaro","path":"/mcatanzaro","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1424966?s=80&v=4"},"commit":{"message":"REGRESSION(281488@main): Process launching is slow\nhttps://bugs.webkit.org/show_bug.cgi?id=279026\n\nReviewed by NOBODY (OOPS!).\n\nProcessLauncher is already designed to support asynchronous process\nlaunching, but the GLib implementation ignores this and does everything\nsynchronously. Previously this was OK because\nProcessLauncher::launchProcess would return immediately after the\nsubprocess is spawned, without waiting for any code to execute in the\nsubprocess. Apparently that's fast enough in practice. But after my\nchanges in 281488@main, we now additionally wait for the subprocess to\nsend credentials to the parent via a socket. That turns out to be\ndrastically slower than actually spawning the process.\n\nThe blocking is unnecessary because the code was already carefully\nstructured to allow asynchronicity. I just failed to take advantage of\nit.\n\nInstead, return immediately after spawning the subprocess. Then, wait\nuntil the socket is ready before reading the pid from it. Now the read\ncan complete instantaneously instead of blocking the UI process.\n\n* Source/WebKit/UIProcess/Launcher/ProcessLauncher.h:\n* Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp:\n(WebKit::ProcessLauncher::launchProcess):","shortMessageHtmlLink":"REGRESSION(281488@main): Process launching is slow"}},{"before":null,"after":"68a3b45e05acd500f4035ac8b89bc5afd7aefac0","ref":"refs/heads/eng/REGRESSION281488main-Process-launching-is-slow-under-flatpak","pushedAt":"2024-09-07T00:16:11.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"mcatanzaro","name":"Michael Catanzaro","path":"/mcatanzaro","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1424966?s=80&v=4"},"commit":{"message":"REGRESSION(281488@main): Process launching is slow under flatpak\nhttps://bugs.webkit.org/show_bug.cgi?id=279026\n\nReviewed by NOBODY (OOPS!).\n\nProcessLauncher is already designed to support asynchronous process\nlaunching, but the GLib implementation ignores this and does everything\nsynchronously. Previously this was OK because\nProcessLauncher::launchProcess would return immediately after the\nsubprocess is spawned, without waiting for any code to execute in the\nsubprocess. Apparently that's fast enough in practice. But after my\nchanges in 281488@main, we now additionally wait for the subprocess to\nsend credentials to the parent via a socket. That turns out to be\ndrastically slower than actually spawning the process.\n\nThe blocking is unnecessary because the code was already carefully\nstructured to allow asynchronicity. I just failed to take advantage of\nit.\n\nInstead, return immediately after spawning the subprocess. Then, wait\nuntil the socket is ready before reading the pid from it. Now the read\ncan complete instantaneously instead of blocking the UI process.\n\n* Source/WebKit/UIProcess/Launcher/ProcessLauncher.h:\n* Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp:\n(WebKit::ProcessLauncher::launchProcess):","shortMessageHtmlLink":"REGRESSION(281488@main): Process launching is slow under flatpak"}},{"before":"c482824aa7fdab2efa87f41a8e811fe22d42c144","after":"c36b50dac0bc42ba7b8722b1d9fef3f24f19a5da","ref":"refs/heads/main","pushedAt":"2024-09-07T00:16:08.000Z","pushType":"push","commitsCount":19,"pusher":{"login":"mcatanzaro","name":"Michael Catanzaro","path":"/mcatanzaro","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1424966?s=80&v=4"},"commit":{"message":"[Part 4] All numeric CSSPrimitiveValue resolvers need to take CSSToLengthConversionData: grid-area\nhttps://bugs.webkit.org/show_bug.cgi?id=279211\n\nReviewed by Darin Adler.\n\nPass conversion data to integer resolver for grid-area's integer value.\n\nAlso fixes up CSS grid BuilderConverter code a bit to:\n    - Pass BuilderState as the first parameter\n    - Use std::optional return type rather than an out parameter + bool for createGridTrackList.\n      With that done, the entire builder implementation of GridTemplateColumns/GridTemplateRows\n      could be replaced with generated conditional-converter code.\n    - Use a normal return type rather than out parameter + bool for createGridPosition. It always\n      return true, so it is also no longer a conditional-converter.\n    - Use a normal return type for createImplicitNamedGridLinesFromGridArea. There was no reason\n      for these to be out parameters.\n\n* LayoutTests/imported/w3c/web-platform-tests/css/css-grid/parsing/grid-area-computed-expected.txt:\n* LayoutTests/imported/w3c/web-platform-tests/css/css-grid/parsing/grid-area-computed.html:\n* Source/WebCore/css/CSSProperties.json:\n* Source/WebCore/rendering/style/RenderStyle.h:\n* Source/WebCore/rendering/style/RenderStyleInlines.h:\n(WebCore::initialGridColumnList):\n(WebCore::initialGridRowList):\n* Source/WebCore/style/StyleBuilderConverter.h:\n(WebCore::Style::BuilderConverter::convertToRadiusLength):\n(WebCore::Style::BuilderConverter::convertRadius):\n(WebCore::Style::BuilderConverter::createGridTrackBreadth):\n(WebCore::Style::BuilderConverter::createGridTrackSize):\n(WebCore::Style::BuilderConverter::createGridTrackList):\n(WebCore::Style::BuilderConverter::createGridPosition):\n(WebCore::Style::BuilderConverter::createImplicitNamedGridLinesFromGridArea):\n(WebCore::Style::BuilderConverter::convertGridTrackSize):\n(WebCore::Style::BuilderConverter::convertGridTrackList):\n(WebCore::Style::BuilderConverter::convertGridPosition):\n* Source/WebCore/style/StyleBuilderCustom.h:\n(WebCore::Style::BuilderCustom::applyValueGridTemplateAreas):\n(WebCore::Style::BuilderCustom::applyInitialGridTemplateColumns): Deleted.\n(WebCore::Style::BuilderCustom::applyInheritGridTemplateColumns): Deleted.\n(WebCore::Style::BuilderCustom::applyValueGridTemplateColumns): Deleted.\n(WebCore::Style::BuilderCustom::applyInitialGridTemplateRows): Deleted.\n(WebCore::Style::BuilderCustom::applyInheritGridTemplateRows): Deleted.\n(WebCore::Style::BuilderCustom::applyValueGridTemplateRows): Deleted.\n\nCanonical link: https://commits.webkit.org/283285@main","shortMessageHtmlLink":"[Part 4] All numeric CSSPrimitiveValue resolvers need to take CSSToLe…"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"Y3Vyc29yOnYyOpK7MjAyNC0wOS0xM1QxNTo1NDoyOS4wMDAwMDBazwAAAAS1qR0k","startCursor":"Y3Vyc29yOnYyOpK7MjAyNC0wOS0xM1QxNTo1NDoyOS4wMDAwMDBazwAAAAS1qR0k","endCursor":"Y3Vyc29yOnYyOpK7MjAyNC0wOS0wN1QwMDoxNjowOC4wMDAwMDBazwAAAASvZmFn"}},"title":"Activity · mcatanzaro/WebKit"}