{"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:1715429456.0","currentOid":""},"activityList":{"items":[{"before":null,"after":"a764879afe32c059b4432b598f619149aa81f697","ref":"refs/heads/eng/GTK-2-45-1-Fails-to-build-on-big-endian-machines-due-to-lack-of-support-in-Skia","pushedAt":"2024-05-11T12:10:56.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] [2.45.1] Fails to build on big-endian machines due to lack of support in Skia\nhttps://bugs.webkit.org/show_bug.cgi?id=274032\n\nReviewed by NOBODY (OOPS!).\n\nDon't use skia on big endian architectures.\n\n* Source/cmake/OptionsGTK.cmake:\n* Source/cmake/OptionsWPE.cmake:","shortMessageHtmlLink":"[GTK] [2.45.1] Fails to build on big-endian machines due to lack of s…"}},{"before":"a16353a2cec5beba9ac9922b57b1242adb98918d","after":"e4580b83827141b83a6625ee5527c4a9552e2c94","ref":"refs/heads/main","pushedAt":"2024-05-11T12:10:25.000Z","pushType":"push","commitsCount":20,"pusher":{"login":"mcatanzaro","name":"Michael Catanzaro","path":"/mcatanzaro","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1424966?s=80&v=4"},"commit":{"message":"Fix PlayStation build following 278635@main\nhttps://bugs.webkit.org/show_bug.cgi?id=274031\n\nUnreviewed build fix.\n\n278635@main introduced the first usage of `consteval` into the codebase;\napparently this works correctly in clang 9-10 and clang 15+, but not in clang 11-14.\n\nPresumably we should introduce a macro in Compiler.h to allow us to use `consteval` where possible,\nbut for the moment, this patch just fixes the build by reverting `consteval` to `constexpr`.\n\n* Source/WebCore/css/parser/CSSPropertyParserConsumer+RawTypes.h:\n(WebCore::computeMinimumValue):\n\nCanonical link: https://commits.webkit.org/278650@main","shortMessageHtmlLink":"Fix PlayStation build following 278635@main"}},{"before":"2b13ffc716c6ee62903a8753e5e6739b2a0474b7","after":"08a76068f2a6f74b19f71a1507a9b60d79328637","ref":"refs/heads/eng/WPEGTK-createNewPage-in-WebKitUIClient-cpp-needs-some-hooking-up-of-the-APIPageConfiguration","pushedAt":"2024-05-10T22:16:06.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] createNewPage in WebKitUIClient.cpp needs some hooking up of the API::PageConfiguration\nhttps://bugs.webkit.org/show_bug.cgi?id=273975\n\nReviewed by NOBODY (OOPS!).\n\nThis resolves a FIXME where the API::PageConfiguration gets ignored when\ncreating a new related web view. The control flow isn't obvious unless\nyou're familiar with GTK/WPE ports, but the WebKitWebView emits the\nWebKitWebView::create signal, then the application using WebKit is\nsupposed to create a new web view using\nwebkit_web_view_new_with_related_view().\n\nNote that some members of the PageConfiguration are always taken from\nthe related view rather than the PageConfiguration we receive.\n\n* Source/WebKit/UIProcess/API/glib/WebKitUIClient.cpp:\n* Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp:\n(webkitWebViewConstructed):\n(webkitWebViewCreateNewPage):\n* Source/WebKit/UIProcess/API/glib/WebKitWebViewPrivate.h:","shortMessageHtmlLink":"[WPE][GTK] createNewPage in WebKitUIClient.cpp needs some hooking up …"}},{"before":"268766c7de0d0900b5c389d62be961065c6ea3dc","after":"a16353a2cec5beba9ac9922b57b1242adb98918d","ref":"refs/heads/main","pushedAt":"2024-05-10T22:15:51.000Z","pushType":"push","commitsCount":22,"pusher":{"login":"mcatanzaro","name":"Michael Catanzaro","path":"/mcatanzaro","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1424966?s=80&v=4"},"commit":{"message":"[ews] Add Windows port layout tests status-bubble to PRs\nhttps://bugs.webkit.org/show_bug.cgi?id=273986\n\nReviewed by Jonathan Bedard.\n\nAdded a new 'wincairo-tests' status bubble.\n\n* Tools/CISupport/ews-app/ews/common/buildbot.py:\n* Tools/CISupport/ews-app/ews/common/github.py:\n* Tools/CISupport/ews-app/ews/views/statusbubble.py:\n\nCanonical link: https://commits.webkit.org/278630@main","shortMessageHtmlLink":"[ews] Add Windows port layout tests status-bubble to PRs"}},{"before":null,"after":"48c72c6743d4584a15fe455a414c95c661c65015","ref":"refs/heads/eng/Need-to-change-the-method-for-determining-the-number-of-CPUs-on-Linux","pushedAt":"2024-05-10T14:11:46.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":"Need to change the method for determining the number of CPUs on Linux\nhttps://bugs.webkit.org/show_bug.cgi?id=273675\n\nReviewed by NOBODY (OOPS!).\n\nnproc is unreliable, so remove it and rely on the fallback that greps\n/proc/cpuinfo instead. This looks a little bit fragile (e.g. it would\nfail if my AMD Ryzen \"Processor\" were instead an AMD Ryzen \"processor\")\nbut surely an improvement.\n\n* Tools/Scripts/webkitdirs.pm:\n(determineNumberOfCPUs):","shortMessageHtmlLink":"Need to change the method for determining the number of CPUs on Linux"}},{"before":"98c351128f7e2568a553e42cbe198fb58d89d271","after":"268766c7de0d0900b5c389d62be961065c6ea3dc","ref":"refs/heads/main","pushedAt":"2024-05-10T14:11:31.000Z","pushType":"push","commitsCount":15,"pusher":{"login":"mcatanzaro","name":"Michael Catanzaro","path":"/mcatanzaro","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1424966?s=80&v=4"},"commit":{"message":"Make setupTransitionPseudoElements end in an up-to-date render tree\nhttps://bugs.webkit.org/show_bug.cgi?id=273962\n\nReviewed by Tim Nguyen.\n\nIt is important for setupTransitionPseudoElements to end in an up-to-date render tree,\nafter potentially invaliding the document element, since updatePseudoElementStyles expects\nthat for copying element properties.\n\n* LayoutTests/fast/css/view-transition-pseudo-element-styles-crash-expected.txt: Added.\n* LayoutTests/fast/css/view-transition-pseudo-element-styles-crash.html: Added.\n* Source/WebCore/dom/ViewTransition.cpp:\n(WebCore::ViewTransition::setupTransitionPseudoElements):\n\nCanonical link: https://commits.webkit.org/278608@main","shortMessageHtmlLink":"Make setupTransitionPseudoElements end in an up-to-date render tree"}},{"before":"06e829600202c67633270739f36536e2c8eebfa8","after":"2b13ffc716c6ee62903a8753e5e6739b2a0474b7","ref":"refs/heads/eng/WPEGTK-createNewPage-in-WebKitUIClient-cpp-needs-some-hooking-up-of-the-APIPageConfiguration","pushedAt":"2024-05-09T23:04:00.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] createNewPage in WebKitUIClient.cpp needs some hooking up of the API::PageConfiguration\nhttps://bugs.webkit.org/show_bug.cgi?id=273975\n\nReviewed by NOBODY (OOPS!).\n\nThis resolves a FIXME where the API::PageConfiguration gets ignored when\ncreating a new related web view. The control flow isn't obvious unless\nyou're familiar with GTK/WPE ports, but the WebKitWebView emits the\nWebKitWebView::create signal, then the application using WebKit is\nsupposed to create a new web view using\nwebkit_web_view_new_with_related_view().\n\nNote that some members of the PageConfiguration are always taken from\nthe related view rather than the PageConfiguration we receive.\n\n* Source/WebKit/UIProcess/API/glib/WebKitUIClient.cpp:\n* Source/WebKit/UIProcess/API/glib/WebKitWebContext.cpp:\n* Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp:\n(webkitWebViewCreateNewPage):\n(webkitWebViewGetConfigurationForNextRelatedView):\n* Source/WebKit/UIProcess/API/glib/WebKitWebViewPrivate.h:","shortMessageHtmlLink":"[WPE][GTK] createNewPage in WebKitUIClient.cpp needs some hooking up …"}},{"before":null,"after":"06e829600202c67633270739f36536e2c8eebfa8","ref":"refs/heads/eng/WPEGTK-createNewPage-in-WebKitUIClient-cpp-needs-some-hooking-up-of-the-APIPageConfiguration","pushedAt":"2024-05-09T22:37:31.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":"[WPE][GTK] createNewPage in WebKitUIClient.cpp needs some hooking up of the API::PageConfiguration\nhttps://bugs.webkit.org/show_bug.cgi?id=273975\n\nReviewed by NOBODY (OOPS!).\n\nThis resolves a FIXME where the API::PageConfiguration gets ignored when\ncreating a new related web view. The control flow isn't obvious unless\nyou're familiar with GTK/WPE ports, but the WebKitWebView emits the\nWebKitWebView::create signal, then the application using WebKit is\nsupposed to create a new web view using\nwebkit_web_view_new_with_related_view().\n\nNote that some members of the PageConfiguration are always taken from\nthe related view rather than the PageConfiguration we receive.\n\n* Source/WebKit/UIProcess/API/glib/WebKitUIClient.cpp:\n* Source/WebKit/UIProcess/API/glib/WebKitWebContext.cpp:\n* Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp:\n(webkitWebViewCreateNewPage):\n(webkitWebViewGetConfigurationForNextRelatedView):\n* Source/WebKit/UIProcess/API/glib/WebKitWebViewPrivate.h:","shortMessageHtmlLink":"[WPE][GTK] createNewPage in WebKitUIClient.cpp needs some hooking up …"}},{"before":"bdfd69d30eda08279f8f3cc1bd7e622b6af34d74","after":"98c351128f7e2568a553e42cbe198fb58d89d271","ref":"refs/heads/main","pushedAt":"2024-05-09T22:37:18.000Z","pushType":"push","commitsCount":132,"pusher":{"login":"mcatanzaro","name":"Michael Catanzaro","path":"/mcatanzaro","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1424966?s=80&v=4"},"commit":{"message":"[webkitscmpy] Fix setting title in mock Bitbucket server\nhttps://bugs.webkit.org/show_bug.cgi?id=273884\nrdar://127751416\n\nReviewed by Dewei Zhu.\n\n* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/mocks/remote/bitbucket.py:\n(BitBucket.request): Allow underdefined 'fromRef' and 'toRef'.\n* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/test/pull_request_unittest.py:\n(TestNetworkPullRequestGitHub.test_title):\n(TestNetworkPullRequestBitBucket.test_title):\n\nCanonical link: https://commits.webkit.org/278593@main","shortMessageHtmlLink":"[webkitscmpy] Fix setting title in mock Bitbucket server"}},{"before":"890ee27a8f67bb55dc252d0c7f91c61defbd1ee5","after":"5034eecac6edc9e4785b36156c19322ec26399bb","ref":"refs/heads/eng/REGRESSION276079main-GTK-Web-view-content-disappears-after-backforward-navigation","pushedAt":"2024-05-07T18:02:58.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 276079@main (7c138c8)\nhttps://bugs.webkit.org/show_bug.cgi?id=273792\n\nREGRESSION(276079@main): [GTK] Web view content disappears after back/forward navigation\n\nReverted change:\n\n    [CoordinatedGraphics] Setting `LocalFrameView`'s content size should not require relayout\n    https://bugs.webkit.org/show_bug.cgi?id=270445\n    276079@main (7c138c8)\n\nThis is causing web view content to disappear after a history\nnavigation.\n\nCanonical link: https://commits.webkit.org/278469@main","shortMessageHtmlLink":"Unreviewed, reverting 276079@main (<a class=\"commit-link\" data-hovercard-type=\"commit\" data-hovercard-url=\"https://github.com/mcatanzaro/WebKit/commit/7c138c89f181e0a39ee64cd986ef11a848793575/hovercard\" href=\"https://github.com/mcatanzaro/WebKit/commit/7c138c89f181e0a39ee64cd986ef11a848793575\"><tt>7c138c8</tt></a>)"}},{"before":"b9f897e702f2228b7173300276d70e14fd77e231","after":"890ee27a8f67bb55dc252d0c7f91c61defbd1ee5","ref":"refs/heads/eng/REGRESSION276079main-GTK-Web-view-content-disappears-after-backforward-navigation","pushedAt":"2024-05-07T18:01:14.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 276079@main (7c138c8)\nhttps://bugs.webkit.org/show_bug.cgi?id=273792\n\nREGRESSION(276079@main): [GTK] Web view content disappears after back/forward navigation\n\nReverted change:\n\n    [CoordinatedGraphics] Setting `LocalFrameView`'s content size should not require relayout\n    https://bugs.webkit.org/show_bug.cgi?id=270445\n    276079@main (7c138c8)\n\nThis is causing web view content to disappear after a history\nnavigation.\n\nCanonical link: https://commits.webkit.org/278462@main","shortMessageHtmlLink":"Unreviewed, reverting 276079@main (<a class=\"commit-link\" data-hovercard-type=\"commit\" data-hovercard-url=\"https://github.com/mcatanzaro/WebKit/commit/7c138c89f181e0a39ee64cd986ef11a848793575/hovercard\" href=\"https://github.com/mcatanzaro/WebKit/commit/7c138c89f181e0a39ee64cd986ef11a848793575\"><tt>7c138c8</tt></a>)"}},{"before":null,"after":"b9f897e702f2228b7173300276d70e14fd77e231","ref":"refs/heads/eng/REGRESSION276079main-GTK-Web-view-content-disappears-after-backforward-navigation","pushedAt":"2024-05-07T15:54:05.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 276079@main (7c138c8)\nhttps://bugs.webkit.org/show_bug.cgi?id=273792\n\nREGRESSION(276079@main): [GTK] Web view content disappears after back/forward navigation\n\nReverted change:\n\n    [CoordinatedGraphics] Setting `LocalFrameView`'s content size should not require relayout\n    https://bugs.webkit.org/show_bug.cgi?id=270445\n    276079@main (7c138c8)\n\nThis is causing web view content to disappear after a history\nnavigation.","shortMessageHtmlLink":"Unreviewed, reverting 276079@main (<a class=\"commit-link\" data-hovercard-type=\"commit\" data-hovercard-url=\"https://github.com/mcatanzaro/WebKit/commit/7c138c89f181e0a39ee64cd986ef11a848793575/hovercard\" href=\"https://github.com/mcatanzaro/WebKit/commit/7c138c89f181e0a39ee64cd986ef11a848793575\"><tt>7c138c8</tt></a>)"}},{"before":"b98c84d7c4a00d2a516edec6ee696695724087f2","after":"bdfd69d30eda08279f8f3cc1bd7e622b6af34d74","ref":"refs/heads/main","pushedAt":"2024-05-07T15:53:51.000Z","pushType":"push","commitsCount":44,"pusher":{"login":"mcatanzaro","name":"Michael Catanzaro","path":"/mcatanzaro","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1424966?s=80&v=4"},"commit":{"message":"repeatedly running css3/flexbox/image-percent-max-height.html is failing\nhttps://bugs.webkit.org/show_bug.cgi?id=267562\n\nReviewed by Alan Baradlay.\n\nCurrently, we check if recalculating the preferred logical width\nof a flex item is needed only if the style of the flexbox itself\nhas changed and will cause relayout.\n\nBut flexbox relayout can be caused by other reasons e.g. when its\nsize is relative to its parent and the parent size has changed.\n\nThis patch moves the check from `RenderFlexibleBox::styleDidChange()`\nto `RenderFlexibleBox::constructFlexItem()`.\n\n* LayoutTests/platform/mac/TestExpectations:\n* Source/WebCore/rendering/RenderFlexibleBox.cpp:\n(WebCore::RenderFlexibleBox::styleDidChange):\n(WebCore::RenderFlexibleBox::constructFlexItem):\n\nCanonical link: https://commits.webkit.org/278461@main","shortMessageHtmlLink":"repeatedly running css3/flexbox/image-percent-max-height.html is failing"}},{"before":"076edd4f62cf021f50b46d6624e984a5a6e57ecb","after":"48d82b12d119cf146e3c0127410fa6677581f2b7","ref":"refs/heads/eng/GTK-Consider-keycode-when-activating-application-accelerators","pushedAt":"2024-05-07T12:34:40.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] Consider keycode when activating application accelerators\nhttps://bugs.webkit.org/show_bug.cgi?id=273780\n\nReviewed by Carlos Garcia Campos.\n\nSince Epiphany 46, keyboard shortcuts no longer work when using\nnon-Latin keyboard layouts, like Ukranian or Hebrew. Currently we only\nconsider the keyval when activating application accelerators. We need to\nconsider the raw keycode as well. E.g. on a Hebrew keyboard pressing\nCtrl+א should open a new tab, because the same key is used for both א\nand T.\n\nFortunately, GTK can do the hard work of deciding which accelerator to\nactivate for us. All we need to do is pass along the keycode.\n\n(This bug was *sort of* a regression from 273922@main. In practice, the\nregression probably only affected Epiphany, because this codepath only\nmatters if the application allows the web view to process key events\nbefore it allows its GtkWindow to do so. That has to be done manually.\nOtherwise, this code will never be reached, because the GtkWindow would\nhave already determined the key event matches an accelerator and handled\nit before the web view ever gets a chance to see it.)\n\n* Source/WebKit/UIProcess/API/gtk/WebKitWebViewBase.cpp:\n(webkitWebViewBaseProcessAcceleratorsForKeyPressEvent):\n\nCanonical link: https://commits.webkit.org/278456@main","shortMessageHtmlLink":"[GTK] Consider keycode when activating application accelerators"}},{"before":"8d7d9d09f7b3469565670a7955cb8e3e1376e964","after":"fed5ccb3371d25640d8cbb705aa1ce454b16c3c9","ref":"refs/heads/eng/Always-log-internal-loader-errors","pushedAt":"2024-05-06T19:55:09.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":"Always log internal loader errors to stderr\nhttps://bugs.webkit.org/show_bug.cgi?id=273662\n\nReviewed by NOBODY (OOPS!).\n\nCurrently when WebKit encounters an internal error during loading, we\nrelease log a stacktrace showing the location of the error. However,\nthere are several downsides:\n\n * Release stacktraces are generally very poor quality, so this is\n   effectively useless. (On Linux, better backtraces are available if\n   built with libbacktrace enabled, but libbacktrace has no releases, so\n   I believe no Linux distros do this.)\n\n * The stacktrace is only logged to the system journal, not to stderr,\n   so it's unlikely to actually be noticed.\n\n * I think it's only logged by default on Linux, because the journald\n   implementation of WTFReleaseLogStackTrace ignores whether log\n   channels are enabled. (I believe this is a bug in the Linux\n   implementation of WTFReleaseLogStackTrace.)\n\n * Otherwise, release logging has to be enabled manually (using the\n   defaults database on macOS, or environment variables on Linux), so\n   naturally it won't ever be enabled when needed.\n\nRELEASE_LOG_BACKTRACE is used from only two places:\nResourceErrorBase.cpp, when logging an internal error, and\nPixelBufferConformerCV.cpp, which isn't built on Linux. This commit\nremoves the use of RELEASE_LOG_BACKTRACE from ResourceErrorBase.cpp.\nSince there are no other remaining uses of RELEASE_LOG_BACKTRACE, and\nsince I don't like it, let's move the implementation to\nPixelBufferConformerCV.cpp to discourage further use. This allows\nsimplifying it to assume use of os_log.\n\nWebKit internal loader errors are bugs and worth printing more visibly\nso we have a better chance to debug problems, especially sporadic or\nunexpected problems that will naturally never occur when we are looking\nfor them with release logging manually enabled. The backtrace is\nprobably not really needed here anyway; it's probably generally\nsufficient to just log the source file location. Here is what a sample\nerror message looks like for a fake error that I introduced for test\npurposes:\n\nERROR: WebKit encountered an internal error. This is a WebKit bug.\n/home/mcatanzaro/Projects/WebKit/Source/WebKit/WebProcess/gtk/WebProcessMainGtk.cpp(75) : virtual bool WebKit::WebProcessMainGtk::platformInitialize()\n\nIn contrast, the release backtrace that I found in my system journal\nafter encountering an internal error yesterday only tells me that the\nproblem lies somewhere in libwebkitgtk-6.0.so.4, which is not useful.\n\n* Source/WTF/wtf/Assertions.cpp:\n* Source/WTF/wtf/Assertions.h:\n* Source/WebCore/platform/graphics/cv/PixelBufferConformerCV.cpp:\n(WebCore::logStackTrace):\n* Source/WebCore/platform/network/ResourceErrorBase.cpp:\n(WebCore::createInternalError):\n(WebCore::internalError): Deleted.\n* Source/WebCore/platform/network/ResourceErrorBase.h:","shortMessageHtmlLink":"Always log internal loader errors to stderr"}},{"before":"cb961ed9a3dff2f5e59e1281ac1ea78af1d99b6f","after":"b98c84d7c4a00d2a516edec6ee696695724087f2","ref":"refs/heads/main","pushedAt":"2024-05-06T19:54:56.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":"[UnifiedPDF] Context menu item \"Previous Page\" appears on the first page in Two Page view layouts\nhttps://bugs.webkit.org/show_bug.cgi?id=273745\nrdar://127442932\n\nReviewed by Simon Fraser.\n\nThis patch makes the logic to mark the \"Previous/Next Page\" context menu\nitems as active more versatile. It does so by:\n\n1. Passing the page index where the context menu event was fired to\n   navigationContextMenuItems, instead of trying to infer the view's page\n   index through indexForCurrentPageInView.\n\n2. Taking into account the fact that for 2up display modes, we want the\n   first pair of pages to have an inactive \"Previous Page\" item.\n\n3. Computing an effective last page index, below which the \"Next Page\"\n   context menu item is active for all pages.\n\n* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:\n* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:\n(WebKit::UnifiedPDFPlugin::createContextMenu const):\n(WebKit::UnifiedPDFPlugin::navigationContextMenuItemsForPageAtIndex const):\n(WebKit::UnifiedPDFPlugin::navigationContextMenuItems const): Deleted.\n\nCanonical link: https://commits.webkit.org/278417@main","shortMessageHtmlLink":"[UnifiedPDF] Context menu item \"Previous Page\" appears on the first p…"}},{"before":"c82887a7de2fe4dcaa4fbee875c248d2f8d3e041","after":"8d7d9d09f7b3469565670a7955cb8e3e1376e964","ref":"refs/heads/eng/Always-log-internal-loader-errors","pushedAt":"2024-05-06T19:40:38.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":"Always log internal loader errors to stderr\nhttps://bugs.webkit.org/show_bug.cgi?id=273662\n\nReviewed by NOBODY (OOPS!).\n\nCurrently when WebKit encounters an internal error during loading, we\nrelease log a stacktrace showing the location of the error. However,\nthere are several downsides:\n\n * Release stacktraces are generally very poor quality, so this is\n   effectively useless. (On Linux, better backtraces are available if\n   built with libbacktrace enabled, but libbacktrace has no releases, so\n   I believe no Linux distros do this.)\n\n * The stacktrace is only logged to the system journal, not to stderr,\n   so it's unlikely to actually be noticed.\n\n * I think it's only logged by default on Linux, because the journald\n   implementation of WTFReleaseLogStackTrace ignores whether log\n   channels are enabled. (I believe this is a bug in the Linux\n   implementation of WTFReleaseLogStackTrace.)\n\n * Otherwise, release logging has to be enabled manually (using the\n   defaults database on macOS, or environment variables on Linux), so\n   naturally it won't ever be enabled when needed.\n\nRELEASE_LOG_BACKTRACE is used from only two places:\nResourceErrorBase.cpp, when logging an internal error, and\nPixelBufferConformerCV.cpp, which isn't built on Linux. This commit\nremoves the use of RELEASE_LOG_BACKTRACE from ResourceErrorBase.cpp.\nSince there are no other remaining uses of RELEASE_LOG_BACKTRACE, and\nsince I don't like it, let's move the implementation to\nPixelBufferConformerCV.cpp to discourage further use. This allows\nsimplifying it to assume use of os_log.\n\nWebKit internal loader errors are bugs and worth printing more visibly\nso we have a better chance to debug problems, especially sporadic or\nunexpected problems that will naturally never occur when we are looking\nfor them with release logging manually enabled. The backtrace is\nprobably not really needed here anyway; it's probably generally\nsufficient to just log the source file location. Here is what a sample\nerror message looks like for a fake error that I introduced for test\npurposes:\n\nERROR: WebKit encountered an internal error. This is a WebKit bug.\n/home/mcatanzaro/Projects/WebKit/Source/WebKit/WebProcess/gtk/WebProcessMainGtk.cpp(75) : virtual bool WebKit::WebProcessMainGtk::platformInitialize()\n\nIn contrast, the release backtrace that I found in my system journal\nafter encountering an internal error yesterday only tells me that the\nproblem lies somewhere in libwebkitgtk-6.0.so.4, which is not useful.\n\n* Source/WTF/wtf/Assertions.cpp:\n* Source/WTF/wtf/Assertions.h:\n* Source/WebCore/platform/graphics/cv/PixelBufferConformerCV.cpp:\n(WebCore::logStackTrace):\n* Source/WebCore/platform/network/ResourceErrorBase.cpp:\n(WebCore::createInternalError):\n(WebCore::internalError): Deleted.\n* Source/WebCore/platform/network/ResourceErrorBase.h:","shortMessageHtmlLink":"Always log internal loader errors to stderr"}},{"before":"803a4e01df61ad093f83ef7d6fde92f87ac04fff","after":"cb961ed9a3dff2f5e59e1281ac1ea78af1d99b6f","ref":"refs/heads/main","pushedAt":"2024-05-06T19:40:24.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":"Versioning.\n\nWebKit-7619.1.13\n\nCanonical link: https://commits.webkit.org/278416@main","shortMessageHtmlLink":"Versioning."}},{"before":"f344830c9aa5df8457f8a53101694f2c3364af4b","after":"c82887a7de2fe4dcaa4fbee875c248d2f8d3e041","ref":"refs/heads/eng/Always-log-internal-loader-errors","pushedAt":"2024-05-06T18:43:10.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":"Always log internal loader errors to stderr\nhttps://bugs.webkit.org/show_bug.cgi?id=273662\n\nReviewed by NOBODY (OOPS!).\n\nCurrently when WebKit encounters an internal error during loading, we\nrelease log a stacktrace showing the location of the error. However,\nthere are several downsides:\n\n * Release stacktraces are generally very poor quality, so this is\n   effectively useless. (On Linux, better backtraces are available if\n   built with libbacktrace enabled, but libbacktrace has no releases, so\n   I believe no Linux distros do this.)\n\n * The stacktrace is only logged to the system journal, not to stderr,\n   so it's unlikely to actually be noticed.\n\n * I think it's only logged by default on Linux, because the journald\n   implementation of WTFReleaseLogStackTrace ignores whether log\n   channels are enabled. (I believe this is a bug in the Linux\n   implementation of WTFReleaseLogStackTrace.)\n\n * Otherwise, release logging has to be enabled manually (using the\n   defaults database on macOS, or environment variables on Linux), so\n   naturally it won't ever be enabled when needed.\n\nRELEASE_LOG_BACKTRACE is used from only two places:\nResourceErrorBase.cpp, when logging an internal error, and\nPixelBufferConformerCV.cpp, which isn't built on Linux. This commit\nremoves the use of RELEASE_LOG_BACKTRACE from ResourceErrorBase.cpp.\nSince there are no other remaining uses of RELEASE_LOG_BACKTRACE, and\nsince I don't like it, let's move the implementation to\nPixelBufferConformerCV.cpp to discourage further use. This allows\nsimplifying it to assume use of os_log.\n\nWebKit internal loader errors are bugs and worth printing more visibly\nso we have a better chance to debug problems, especially sporadic or\nunexpected problems that will naturally never occur when we are looking\nfor them with release logging manually enabled. The backtrace is\nprobably not really needed here anyway; it's probably generally\nsufficient to just log the source file location. Here is what a sample\nerror message looks like for a fake error that I introduced for test\npurposes:\n\nERROR: WebKit encountered an internal error. This is a WebKit bug.\n/home/mcatanzaro/Projects/WebKit/Source/WebKit/WebProcess/gtk/WebProcessMainGtk.cpp(75) : virtual bool WebKit::WebProcessMainGtk::platformInitialize()\n\nIn contrast, the release backtrace that I found in my system journal\nafter encountering an internal error yesterday only tells me that the\nproblem lies somewhere in libwebkitgtk-6.0.so.4, which is not useful.\n\n* Source/WTF/wtf/Assertions.cpp:\n* Source/WTF/wtf/Assertions.h:\n* Source/WebCore/platform/graphics/cv/PixelBufferConformerCV.cpp:\n(WebCore::logStackTrace):\n* Source/WebCore/platform/network/ResourceErrorBase.cpp:\n(WebCore::internalError):\n* Source/WebCore/platform/network/ResourceErrorBase.h:","shortMessageHtmlLink":"Always log internal loader errors to stderr"}},{"before":"b45457bcf81870e70faced7a27046c290563f265","after":"803a4e01df61ad093f83ef7d6fde92f87ac04fff","ref":"refs/heads/main","pushedAt":"2024-05-06T18:42:35.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":"Revert \"Assert hit in WebKit::RemoteImageBuffer::getShareableBitmap\"\nrdar://127422298\n\nReviewed by Simon Fraser.\n\nThis reverts commit 393949a1c17caf79bfdab86b7b0a5fc9cf603ea9.\n\nIt caused bad rendering on NYT.\n\nCanonical link: https://commits.webkit.org/278413@main","shortMessageHtmlLink":"Revert \"Assert hit in WebKit::RemoteImageBuffer::getShareableBitmap\""}},{"before":null,"after":"076edd4f62cf021f50b46d6624e984a5a6e57ecb","ref":"refs/heads/eng/GTK-Consider-keycode-when-activating-application-accelerators","pushedAt":"2024-05-06T17:44:31.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] Consider keycode when activating application accelerators\nhttps://bugs.webkit.org/show_bug.cgi?id=273780\n\nReviewed by NOBODY (OOPS!).\n\nSince Epiphany 46, keyboard shortcuts no longer work when using\nnon-Latin keyboard layouts, like Ukranian or Hebrew. Currently we only\nconsider the keyval when activating application accelerators. We need to\nconsider the raw keycode as well. E.g. on a Hebrew keyboard pressing\nCtrl+א should open a new tab, because the same key is used for both א\nand T.\n\nFortunately, GTK can do the hard work of deciding which accelerator to\nactivate for us. All we need to do is pass along the keycode.\n\n(This bug was *sort of* a regression from 273922@main. In practice, the\nregression probably only affected Epiphany, because this codepath only\nmatters if the application allows the web view to process key events\nbefore it allows its GtkWindow to do so. That has to be done manually.\nOtherwise, this code will never be reached, because the GtkWindow would\nhave already determined the key event matches an accelerator and handled\nit before the web view ever gets a chance to see it.)\n\n* Source/WebKit/UIProcess/API/gtk/WebKitWebViewBase.cpp:\n(webkitWebViewBaseProcessAcceleratorsForKeyPressEvent):","shortMessageHtmlLink":"[GTK] Consider keycode when activating application accelerators"}},{"before":"afc7f08b0bc00f060f01e3a5c5eeabe2b89733b6","after":"b45457bcf81870e70faced7a27046c290563f265","ref":"refs/heads/main","pushedAt":"2024-05-06T17:44:17.000Z","pushType":"push","commitsCount":117,"pusher":{"login":"mcatanzaro","name":"Michael Catanzaro","path":"/mcatanzaro","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1424966?s=80&v=4"},"commit":{"message":"Use simde\nhttps://bugs.webkit.org/show_bug.cgi?id=273755\nrdar://127585228\n\nReviewed by Keith Miller.\n\nThis patch imports simd-everywhere[1]. This implements almost all of ARM64 NEON intriniscs\non any platforms so that we can just globally use ARM64 NEON SIMD. We enabled ARM64-exclusively written SIMD code for x64 too.\nRight now, we are not enabling SIMD for x64 yet. We do that in a separate patch.\nNote that Apple OSS approval ID is OSS-14094.\n\n[1]: https://github.com/simd-everywhere/simde\n\n* Source/WTF/LICENSE-simde.txt: Added.\n* Source/WTF/WTF.xcodeproj/project.pbxproj:\n* Source/WTF/wtf/CMakeLists.txt:\n* Source/WTF/wtf/simde/arm/neon.h: Added.\n* Source/WTF/wtf/text/StringCommon.cpp:\n(WTF::find16AlignedImpl):\n(WTF::find32AlignedImpl):\n(WTF::find64AlignedImpl):\n(WTF::findFloatAlignedImpl):\n(WTF::findDoubleAlignedImpl):\n(WTF::find8NonASCIIAlignedImpl):\n(WTF::find16NonASCIIAlignedImpl):\n* Source/WTF/wtf/text/StringCommon.h:\n\nCanonical link: https://commits.webkit.org/278410@main","shortMessageHtmlLink":"Use simde"}},{"before":"094d2cdf8bf9dc855b9724ffbc1cd3870d897cfb","after":"f344830c9aa5df8457f8a53101694f2c3364af4b","ref":"refs/heads/eng/Always-log-internal-loader-errors","pushedAt":"2024-05-03T01:20:48.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":"Always log internal loader errors to stderr\nhttps://bugs.webkit.org/show_bug.cgi?id=273662\n\nReviewed by NOBODY (OOPS!).\n\nCurrently when WebKit encounters an internal error during loading, we\nrelease log a stacktrace showing the location of the error. However,\nthere are several downsides:\n\n * Release stacktraces are generally very poor quality, so this is\n   effectively useless. (On Linux, better backtraces are available if\n   built with libbacktrace enabled, but libbacktrace has no releases, so\n   I believe no Linux distros do this.)\n\n * The stacktrace is only logged to the system journal, not to stderr,\n   so it's unlikely to actually be noticed.\n\n * I think it's only logged by default on Linux, because the journald\n   implementation of WTFReleaseLogStackTrace ignores whether log\n   channels are enabled. (I believe this is a bug in the Linux\n   implementation of WTFReleaseLogStackTrace.)\n\n * Otherwise, release logging has to be enabled manually (using the\n   defaults database on macOS, or environment variables on Linux), so\n   naturally it won't ever be enabled when needed.\n\nRELEASE_LOG_BACKTRACE is used from only two places:\nResourceErrorBase.cpp, when logging an internal error, and\nPixelBufferConformerCV.cpp, which isn't built on Linux. This commit\nremoves the use of RELEASE_LOG_BACKTRACE from ResourceErrorBase.cpp.\nSince there are no other remaining uses of RELEASE_LOG_BACKTRACE, and\nsince I don't like it, let's move the implementation to\nPixelBufferConformerCV.cpp to discourage further use. This allows\nsimplifying it to assume use of os_log.\n\nWebKit internal loader errors are bugs and worth printing more visibly\nso we have a better chance to debug problems, especially sporadic or\nunexpected problems that will naturally never occur when we are looking\nfor them with release logging manually enabled. The backtrace is\nprobably not really needed here anyway; it's probably generally\nsufficient to just log the source file location. Here is what a sample\nerror message looks like for a fake error that I introduced for test\npurposes:\n\nERROR: WebKit encountered an internal error. This is a WebKit bug.\n/home/mcatanzaro/Projects/WebKit/Source/WebKit/WebProcess/gtk/WebProcessMainGtk.cpp(75) : virtual bool WebKit::WebProcessMainGtk::platformInitialize()\n\nIn contrast, the release backtrace that I found in my system journal\nafter encountering an internal error yesterday only tells me that the\nproblem lies somewhere in libwebkitgtk-6.0.so.4, which is not useful.\n\n* Source/WTF/wtf/Assertions.cpp:\n* Source/WTF/wtf/Assertions.h:\n* Source/WebCore/platform/graphics/cv/PixelBufferConformerCV.cpp:\n(WebCore::logStackTrace):\n* Source/WebCore/platform/network/ResourceErrorBase.cpp:\n(WebCore::internalError):\n* Source/WebCore/platform/network/ResourceErrorBase.h:","shortMessageHtmlLink":"Always log internal loader errors to stderr"}},{"before":"df37193a08ae565c630e17b04f9b2995eeedd70a","after":"afc7f08b0bc00f060f01e3a5c5eeabe2b89733b6","ref":"refs/heads/main","pushedAt":"2024-05-03T01:20:34.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":"Remove StringBuilder calls in CacheStorageDiskStore\nhttps://bugs.webkit.org/show_bug.cgi?id=273657\nrdar://127461376\n\nReviewed by Sihui Liu.\n\nThere are some dead stores to StringBuilder in CacheStorageDiskStore that should be removed.\n\n* Source/WebKit/NetworkProcess/storage/CacheStorageDiskStore.cpp:\n(WebKit::encodeRecord):\n\nCanonical link: https://commits.webkit.org/278293@main","shortMessageHtmlLink":"Remove StringBuilder calls in CacheStorageDiskStore"}},{"before":"a1df7add84e10fce0a08174320586243fc8ce3b3","after":"094d2cdf8bf9dc855b9724ffbc1cd3870d897cfb","ref":"refs/heads/eng/Always-log-internal-loader-errors","pushedAt":"2024-05-03T01:08: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":"Always log internal loader errors to stderr\nhttps://bugs.webkit.org/show_bug.cgi?id=273662\n\nReviewed by NOBODY (OOPS!).\n\nCurrently when WebKit encounters an internal error during loading, we\nrelease log a stacktrace showing the location of the error. However,\nthere are several downsides:\n\n * Release stacktraces are generally very poor quality, so this is\n   effectively useless. (On Linux, better backtraces are available if\n   built with libbacktrace enabled, but libbacktrace has no releases, so\n   I believe no Linux distros do this.)\n\n * The stacktrace is only logged to the system journal, not to stderr,\n   so it's unlikely to actually be noticed.\n\n * I think it's only logged by default on Linux, because the journald\n   implementation of WTFReleaseLogStackTrace ignores whether log\n   channels are enabled. (I believe this is a bug in the Linux\n   implementation of WTFReleaseLogStackTrace.)\n\n * Otherwise, release logging has to be enabled manually (using the\n   defaults database on macOS, or environment variables on Linux), so\n   naturally it won't ever be enabled when needed.\n\nRELEASE_LOG_BACKTRACE is used from only two places:\nResourceErrorBase.cpp, when logging an internal error, and\nPixelBufferConformerCV.cpp, which isn't built on Linux. This commit\nremoves the use of RELEASE_LOG_BACKTRACE from ResourceErrorBase.cpp.\nSince there are no other remaining uses of RELEASE_LOG_BACKTRACE, and\nsince I don't like it, let's move the implementation to\nPixelBufferConformerCV.cpp to discourage further use. This allows\nsimplifying it to assume use of os_log.\n\nWebKit internal loader errors are bugs and worth printing more visibly\nso we have a better chance to debug problems, especially sporadic or\nunexpected problems that will naturally never occur when we are looking\nfor them with release logging manually enabled. The backtrace is\nprobably not really needed here anyway; it's probably generally\nsufficient to just log the source file location. Here is what a sample\nerror message looks like for a fake error that I introduced for test\npurposes:\n\nERROR: WebKit encountered an internal error. This is a WebKit bug.\n/home/mcatanzaro/Projects/WebKit/Source/WebKit/WebProcess/gtk/WebProcessMainGtk.cpp(75) : virtual bool WebKit::WebProcessMainGtk::platformInitialize()\n\nIn contrast, the release backtrace that I found in my system journal\nafter encountering an internal error yesterday only tells me that the\nproblem lies somewhere in libwebkitgtk-6.0.so.4, which is not useful.\n\n* Source/WTF/wtf/Assertions.cpp:\n* Source/WTF/wtf/Assertions.h:\n* Source/WebCore/platform/graphics/cv/PixelBufferConformerCV.cpp:\n(logStackTrace):\n* Source/WebCore/platform/network/ResourceErrorBase.cpp:\n(WebCore::internalError):\n* Source/WebCore/platform/network/ResourceErrorBase.h:","shortMessageHtmlLink":"Always log internal loader errors to stderr"}},{"before":"9edfaaaf5fb29baa7a9dde02f6f0788e3046d1ee","after":"a1df7add84e10fce0a08174320586243fc8ce3b3","ref":"refs/heads/eng/Always-log-internal-loader-errors","pushedAt":"2024-05-03T01:06:27.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":"Always log internal loader errors to stderr\nhttps://bugs.webkit.org/show_bug.cgi?id=273662\n\nReviewed by NOBODY (OOPS!).\n\nCurrently when WebKit encounters an internal error during loading, we\nrelease log a stacktrace showing the location of the error. However,\nthere are several downsides:\n\n * Release stacktraces are generally very poor quality, so this is\n   effectively useless. (On Linux, better backtraces are available if\n   built with libbacktrace enabled, but libbacktrace has no releases, so\n   I believe no Linux distros do this.)\n\n * The stacktrace is only logged to the system journal, not to stderr,\n   so it's unlikely to actually be noticed.\n\n * I think it's only logged by default on Linux, because the journald\n   implementation of WTFReleaseLogStackTrace ignores whether log\n   channels are enabled. (I believe this is a bug in the Linux\n   implementation of WTFReleaseLogStackTrace.)\n\n * Otherwise, release logging has to be enabled manually (using the\n   defaults database on macOS, or environment variables on Linux), so\n   naturally it won't ever be enabled when needed.\n\nRELEASE_LOG_BACKTRACE is used from only two places:\nResourceErrorBase.cpp, when logging an internal error, and\nPixelBufferConformerCV.cpp, which isn't built on Linux. This commit\nremoves the use of RELEASE_LOG_BACKTRACE from ResourceErrorBase.cpp.\nSince there are no other remaining uses of RELEASE_LOG_BACKTRACE, and\nsince I don't like it, let's move the implementation to\nPixelBufferConformerCV.cpp to discourage further use. This allows\nsimplifying it to assume use of os_log.\n\nWebKit internal loader errors are bugs and worth printing more visibly\nso we have a better chance to debug problems, especially sporadic or\nunexpected problems that will naturally never occur when we are looking\nfor them with release logging manually enabled. The backtrace is\nprobably not really needed here anyway; it's probably generally\nsufficient to just log the source file location. Here is what a sample\nerror message looks like for a fake error that I introduced for test\npurposes:\n\nERROR: WebKit encountered an internal error. This is a WebKit bug.\n/home/mcatanzaro/Projects/WebKit/Source/WebKit/WebProcess/gtk/WebProcessMainGtk.cpp(75) : virtual bool WebKit::WebProcessMainGtk::platformInitialize()\n\nIn contrast, the release backtrace that I found in my system journal\nafter encountering an internal error yesterday only tells me that the\nproblem lies somewhere in libwebkitgtk-6.0.so.4, which is not useful.\n\n* Source/WTF/wtf/Assertions.cpp:\n* Source/WTF/wtf/Assertions.h:\n* Source/WebCore/platform/graphics/cv/PixelBufferConformerCV.cpp:\n(logStackTrace):\n* Source/WebCore/platform/network/ResourceErrorBase.cpp:\n(WebCore::internalError):\n* Source/WebCore/platform/network/ResourceErrorBase.h:","shortMessageHtmlLink":"Always log internal loader errors to stderr"}},{"before":"4717bf604b180fae1f857b07ea8c12659db74376","after":"df37193a08ae565c630e17b04f9b2995eeedd70a","ref":"refs/heads/main","pushedAt":"2024-05-03T01:06:13.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":"Rename some \"forceRepaint\" functions for clarity\nhttps://bugs.webkit.org/show_bug.cgi?id=273596\nrdar://127396058\n\nReviewed by Tim Horton.\n\nRename forceRepaint functions in WebKit to reduce the confusion about what \"force repaint\" really means.\nIn layout code we use \"repaint\" to mean \"invalidate for painting\", but these \"forceRepaint\" functions\ndo the invalidation, and then they trigger a rendering update, so call them \"updateRenderingWithForcedRepaint\".\n\n* Source/WebKit/UIProcess/API/C/WKPage.cpp:\n(WKPageForceRepaint):\n* Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp:\n* Source/WebKit/UIProcess/ViewGestureController.cpp:\n(WebKit::ViewGestureController::forceRepaintIfNeeded):\n* Source/WebKit/UIProcess/WebPageProxy.cpp:\n(WebKit::WebPageProxy::updateRenderingWithForcedRepaint):\n(WebKit::WebPageProxy::forceRepaint): Deleted.\n* Source/WebKit/UIProcess/WebPageProxy.h:\n* Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm:\n(-[WKFullScreenWindowController enterFullScreen:]):\n(-[WKFullScreenWindowController _completedExitFullScreen]):\n* Source/WebKit/UIProcess/mac/WKFullScreenWindowController.mm:\n(-[WKFullScreenWindowController finishedExitFullScreenAnimationAndExitImmediately:]):\n* Source/WebKit/WebProcess/InjectedBundle/API/c/WKBundlePage.cpp:\n(WKBundlePageForceRepaint):\n* Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.cpp:\n(WebKit::DrawingAreaCoordinatedGraphics::updateRenderingWithForcedRepaint):\n(WebKit::DrawingAreaCoordinatedGraphics::updateRenderingWithForcedRepaintAsync):\n(WebKit::DrawingAreaCoordinatedGraphics::forceRepaint): Deleted.\n(WebKit::DrawingAreaCoordinatedGraphics::forceRepaintAsync): Deleted.\n* Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.h:\n* Source/WebKit/WebProcess/WebPage/DrawingArea.h:\n(WebKit::DrawingArea::updateRenderingWithForcedRepaint):\n(WebKit::DrawingArea::forceRepaint): Deleted.\n* Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.h:\n* Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.mm:\n(WebKit::RemoteLayerTreeDrawingArea::updateRenderingWithForcedRepaint):\n(WebKit::RemoteLayerTreeDrawingArea::updateRenderingWithForcedRepaintAsync):\n(WebKit::RemoteLayerTreeDrawingArea::forceRepaintAsync): Deleted.\n(WebKit::RemoteLayerTreeDrawingArea::forceRepaint): Deleted.\n* Source/WebKit/WebProcess/WebPage/WebPage.cpp:\n(WebKit::WebPage::updateRenderingWithForcedRepaintWithoutCallback):\n(WebKit::WebPage::updateRenderingWithForcedRepaint):\n(WebKit::WebPage::forceRepaintWithoutCallback): Deleted.\n(WebKit::WebPage::forceRepaint): Deleted.\n* Source/WebKit/WebProcess/WebPage/WebPage.h:\n* Source/WebKit/WebProcess/WebPage/WebPage.messages.in:\n* Source/WebKit/WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.h:\n* Source/WebKit/WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm:\n(WebKit::TiledCoreAnimationDrawingArea::updateRenderingWithForcedRepaint):\n(WebKit::TiledCoreAnimationDrawingArea::updateRenderingWithForcedRepaintAsync):\n(WebKit::TiledCoreAnimationDrawingArea::forceRepaint): Deleted.\n(WebKit::TiledCoreAnimationDrawingArea::forceRepaintAsync): Deleted.\n* Source/WebKit/WebProcess/WebPage/wc/DrawingAreaWC.cpp:\n(WebKit::DrawingAreaWC::updateRenderingWithForcedRepaintAsync):\n(WebKit::DrawingAreaWC::forceRepaintAsync): Deleted.\n* Source/WebKit/WebProcess/WebPage/wc/DrawingAreaWC.h:\n\nCanonical link: https://commits.webkit.org/278292@main","shortMessageHtmlLink":"Rename some \"forceRepaint\" functions for clarity"}},{"before":null,"after":"9edfaaaf5fb29baa7a9dde02f6f0788e3046d1ee","ref":"refs/heads/eng/Always-log-internal-loader-errors","pushedAt":"2024-05-03T00:52:38.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":"Always log internal loader errors to stderr\nhttps://bugs.webkit.org/show_bug.cgi?id=273662\n\nReviewed by NOBODY (OOPS!).\n\nCurrently when WebKit encounters an internal error during loading, we release log a stacktrace showing the location of the error. However, there are several downsides:\n\n * Release stacktraces are generally very poor quality, so this is effectively useless\n * The stacktrace is only logged to the system journal, not to stderr, so it's unlikely to be noticed\n * I think it's only logged by default on Linux, because the journald implementation of WTFReleaseLogStackTrace ignores whether log channels are enabled\n * Otherwise, release logging has to be enabled manually (using the defaults database on macOS, or environment variables on Linux), so naturally it won't ever be enabled when needed\n\nI'm pretty sure the failure to respect the log channel enablement is a bug in the Linux implementation of WTFReleaseLogStackTrace, but I don't think it's worth fixing because it's used from only two places: ResourceErrorBase.cpp, when logging an internal error, and PixelBufferConformerCV.cpp, which isn't built on Linux.\n\nWebKit internal errors are bugs and worth printing more visibly. Let's always print an error message to stderr using WTFReportError so we have a better chance to debug it. This includes source file location to make it easier to see where the error is coming from; it's less precise than a good backtrace, but a lot better than a useless backtrace. Here is a sample of what this looks like for a fake error:\n\nERROR: WebKit encountered an internal error. This is a WebKit bug.\n/home/mcatanzaro/Projects/WebKit/Source/WebKit/WebProcess/gtk/WebProcessMainGtk.cpp(75) : virtual bool WebKit::WebProcessMainGtk::platformInitialize()\n\nCompare to the previous logging:\n\nMay 01 07:08:54 dreamyard WebKitWebProcess[8210]: 1   0x7f484818fce4 WTFGetBacktrace\nMay 01 07:08:54 dreamyard WebKitWebProcess[8210]: 2   0x7f484815f53c WTFReleaseLogStackTrace\nMay 01 07:08:54 dreamyard WebKitWebProcess[8210]: 3   0x7f484b2f654f /usr/lib/x86_64-linux-gnu/libwebkitgtk-6.0.so.4(+0x2af654f) [0x7f484b2f654f]\nMay 01 07:08:54 dreamyard WebKitWebProcess[8210]: 4   0x7f48495e82ea /usr/lib/x86_64-linux-gnu/libwebkitgtk-6.0.so.4(+0xde82ea) [0x7f48495e82ea]\nMay 01 07:08:54 dreamyard WebKitWebProcess[8210]: 5   0x7f48481f2915 /usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-6.0.so.1(+0x15f2915) [0x7f48481f2915]\nMay 01 07:08:54 dreamyard WebKitWebProcess[8210]: 6   0x7f48481f1c61 /usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-6.0.so.1(+0x15f1c61) [0x7f48481f1c61]\nMay 01 07:08:54 dreamyard WebKitWebProcess[8210]: 7   0x7f4844409767 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x60767) [0x7f4844409767]\nMay 01 07:08:54 dreamyard WebKitWebProcess[8210]: 8   0x7f484440b907 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x62907) [0x7f484440b907]\nMay 01 07:08:54 dreamyard WebKitWebProcess[8210]: 9   0x7f484440c3a7 g_main_loop_run\nMay 01 07:08:54 dreamyard WebKitWebProcess[8210]: 10  0x7f48481f2241 WTF::RunLoop::run()\nMay 01 07:08:54 dreamyard WebKitWebProcess[8210]: 11  0x7f48496c8b32 /usr/lib/x86_64-linux-gnu/libwebkitgtk-6.0.so.4(+0xec8b32) [0x7f48496c8b32]\nMay 01 07:08:54 dreamyard WebKitWebProcess[8210]: 12  0x7f484cecd08a /usr/lib/x86_64-linux-gnu/libc.so.6(+0x2808a) [0x7f484cecd08a]\nMay 01 07:08:54 dreamyard WebKitWebProcess[8210]: 13  0x7f484cecd14b __libc_start_main\nMay 01 07:08:54 dreamyard WebKitWebProcess[8210]: 14  0x55eabee2a085 /usr/libexec/webkitgtk-6.0/WebKitWebProcess(+0x1085) [0x55eabee2a085]\n\n(This backtrace would be better if I had built with libbacktrace enabled, but no Linux distros do that because there are no releases of libbacktrace.)\n\nSince there are no other remaining uses of RELEASE_LOG_BACKTRACE outside PixelBufferConformerCV.cpp, and since I don't like it, let's move the implementation to that file to discourage further use. This allows simplifying it to assume use of os_log.\n\n* Source/WTF/wtf/Assertions.cpp:\n* Source/WTF/wtf/Assertions.h:\n* Source/WebCore/platform/graphics/cv/PixelBufferConformerCV.cpp:\n(logStackTrace):\n* Source/WebCore/platform/network/ResourceErrorBase.cpp:\n(WebCore::internalError):\n* Source/WebCore/platform/network/ResourceErrorBase.h:","shortMessageHtmlLink":"Always log internal loader errors to stderr"}},{"before":"d453f6b4c0b8ec8f5bf958942762edc466364b56","after":"4717bf604b180fae1f857b07ea8c12659db74376","ref":"refs/heads/main","pushedAt":"2024-05-03T00:52:24.000Z","pushType":"push","commitsCount":104,"pusher":{"login":"mcatanzaro","name":"Michael Catanzaro","path":"/mcatanzaro","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1424966?s=80&v=4"},"commit":{"message":"Unreviewed, ASSERTION FAILED: cellsToMark.isEmpty() and crashes on 'neowin.net'\nhttps://bugs.webkit.org/show_bug.cgi?id=273659\nrdar://127462893\n\nThis assertion is no longer true. Just remove it.\n\n* Source/JavaScriptCore/bytecode/InlineCacheCompiler.cpp:\n(JSC::InlineCacheCompiler::regenerate):\n\nCanonical link: https://commits.webkit.org/278291@main","shortMessageHtmlLink":"Unreviewed, ASSERTION FAILED: cellsToMark.isEmpty() and crashes on 'n…"}},{"before":"b4d20d2fee481448aaaf7df91964f490b1a758ea","after":"96dfbcd4fcdde14852f87c77c564d9b718d5d8db","ref":"refs/heads/eng/GTK-Paste-primary-selection-on-button-release-not-on-button-press","pushedAt":"2024-04-30T21:40:08.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] Paste primary selection on button release, not on button press\nhttps://bugs.webkit.org/show_bug.cgi?id=247375\n\nReviewed by NOBODY (OOPS!).\n\nThis changes how middle click paste works. Let's paste on mouse button\nup (released) rather than button down (pressed).\n\nThis is inconsistent with GTK's behavior, but it matches all other\nplatforms and is superior because it allows Epiphany to process mouse\ngestures first and handle the event before WebKit pastes anything.\n\n* Source/WebCore/page/EventHandler.cpp:\n(WebCore::EventHandler::handleMousePressEventSingleClick):\n(WebCore::EventHandler::handleMouseReleaseEvent):\n(WebCore::EventHandler::handlePasteGlobalSelection):\n* Source/WebCore/page/EventHandler.h:","shortMessageHtmlLink":"[GTK] Paste primary selection on button release, not on button press"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAERznBAQA","startCursor":null,"endCursor":null}},"title":"Activity · mcatanzaro/WebKit"}