openQA testing of the Firefox 146 updates showed that it does not load the Cockpit 'Services' page properly. It seems to get stuck in a loop - the page loads correctly very briefly, then goes back to showing "Loading... Listing units", then loads briefly, then goes back to "Loading... Listing units", and so on. This is the case on both arches (x86_64 and aarch64) and across all releases (42, 43, 44). A commenter on one of the updates suggested it's having problems loading a font, I haven't checked that myself. At mstransky's request I have dropped the Services page check from the openQA test for now so the updates could go out, as they were required to address security issues. But Cockpit functionality is part of our Server release criteria so we should not allow this to remain broken for long.
Looked at it yesterday. I see the reload loop on service page. Investigated logs etc. and looks like a problem in cockpit itself as it keeps to reload the page after GET failure / permission failure or so. But it's Fedora only. Tried various things - disabled Firefox sandbox,SELinux. So looks like cockpit itself keeps the page reloading (for some reason) but not sure why. Tentatively moving to cockpit for further investigation. I don't say it's cockpit bug but I need an insight from cockpit devs here.
I can reproduce this effortlessly with upstream Firefox 146 download.
Also reproducible with 146.0.1, this isn't limited to the services page but also happens on the accounts page (/users). What I see locally is: GET https://127.0.0.2:9092/cockpit/@localhost/users/index.html fail with NS_BINDING_ABORTED
Reproducible here with 146.0.1 (aarch64) on macOS. Cockpit version 337-1. Tested on both a generic Debian 13 system and Raspberry Pi running Raspberry Pi OS (which is essentially another Debian 13 system!). Cockpit issue happens on both Accounts and Services page. Confirmed NOT an issue in Safari Version 26.2 (21623.1.14.11.9). Workaround I stumbled on for Firefox: 1. Navigate to Services or Accounts page and you get the loop issue 2. Navigate back to Overview 3. Refresh page 4. Navigate to Services or Accounts page again and it will load normally I am not a web dev so my knowledge is pretty limited. In web console the following errors flood constantly GET https://[redacted]/cockpit/@localhost/system/assets/fonts/RedHatDisplay/RedHatDisplayVF.woff2 [HTTP/2 404 2ms] downloadable font: download failed (font-family: "Red Hat Text" style:normal weight:400..500 stretch:100 src index:0): status=2147746065 source: https://[redacted]/cockpit/@localhost/system/assets/fonts/RedHatText/RedHatTextVF.woff2 downloadable font: download failed (font-family: "Red Hat Display" style:normal weight:400..700 stretch:100 src index:0): status=2147746065 source: https://[redacted]/cockpit/@localhost/system/assets/fonts/RedHatDisplay/RedHatDisplayVF.woff2 I did notice when I tried to load the font manually by going to the url https://[redacted]/cockpit/@localhost/system/assets/fonts/RedHatDisplay/RedHatDisplayVF.woff2 I got a Cockpit specific "(!) Not Authorised" page not a generic web server 403 or whatever you would normally see. Hopefully the is maybe helpful to someone? Also I am accessing from bying an Nginx reverse proxy (NPM) however directly access via http://ip:9090 and the same problem happens so I don't think it is anything related to the reverse proxy - although I could be wrong, again not a web dev :)
*** Bug 2426763 has been marked as a duplicate of this bug. ***
"Fun" -- this *does* smell like a Firefox bug. Curiously, when our CI updated Firefox to 146, we ran into loads of crashes via the BiDi API, see https://github.com/cockpit-project/cockpit/pull/22720#issuecomment-3701568895 . I worked around that in https://github.com/cockpit-project/cockpituous/pull/681 by updating our CI to Firefox nightly (148.0a1), as even the current beta (147.0b9) crashed. Sadly it's some kind of race, I wasn't able to create a standalone BiDi reproducer (i.e. even the most complex one didn't fail). Now I see exactly the same versions/pattern with this bug: The Services and Users keep crashing with 146 and 147, and nightly (148) works fine again. I'll spend some more time to investigate this on the cockpit side, perhaps I can boil this down to a more manageable reproducer. At least the bug is fixed upstream, we "just" need to find it to backport it..
Force-reloading a page with iframes serving gzipped/chunked content causes those iframes to enter an infinite reload loop: Firefox itself repeatedly reloads the iframe regardless of JavaScript code, with each reload triggering an unload event. This only happens on force-reload (not initial load), only with minified/gzipped content (not dev mode), and only when the page is loaded in an iframe (accessing the URL directly works fine). The shell's iframe management code is listening to these unload events and calling teardown_iframe() followed by setup_iframe(), which registered new unload listeners, creating a resource-wasting feedback loop even though Firefox would reload anyway. This can be fixed by detecting reload loops in the shell and marking pages as "permanently broken". This stops the shell from participating in the loop, though Firefox 146 continues reloading the iframe internally due to that bug. Sadly, there are no useful console messages about this. We can just observe the various effects of aborting the JS code and reloading the page, but not any error message about the root cause. Developer notes: This can be more efficiently be investigated by running the web server out of the build tree, without authentication: # can be run out of tree with some gymnastics, but not necessary for now sudo dnf install cockpit-bridge # succeeds with devel build NODE_ENV=production ./build.js XDG_DATA_DIRS=`pwd` ./cockpit-ws --no-tls --local-session=cockpit-bridge Then open http://localhost:9090/users (which works for me) and force-reload, then it enters the reload loop. Direct pages work, i.e. no embedded iframes: http://localhost:9090/cockpit/@localhost/system/services.html#/ http://localhost:9090/cockpit/@localhost/users/index.html#/
See https://github.com/cockpit-project/cockpit/commit/92741dd1297e2e214e215ceacb1e1ef285551f74 which stops the Cockpit shell from participating in the reload loop. But Firefox still does the reloading entirely on its own, we can't stop that. That's the Firefox bug, and it's apparently fixed in 148. I now tried to progressively disable/remove code from the users page to see what exactly triggers this. Disabling large chunks of the initialization and rendering doesn't change the bug. I suspect it's less about the particular code that runs, and more about the shape/size of users.js.gz, as this seems related to loading chunked gzipped files? With the change below, users.js.gz shrinks 165K → 59K, which makes the reload bug go away: --- pkg/users/users.js +++ pkg/users/users.js @@ -32,8 +32,12 @@ import { usePageLocation, useLoggedInUser, useFile, useInit } from "hooks.js"; import { etc_passwd_syntax, etc_group_syntax, etc_shells_syntax } from "pam_user_parser.js"; import { EmptyStatePanel } from "cockpit-components-empty-state.jsx"; -import { AccountsMain } from "./accounts-list.js"; -import { AccountDetails, AccountNotFound } from "./account-details.js"; +// Temporarily commented out for debugging +// import { AccountsMain } from "./accounts-list.js"; +// import { AccountDetails, AccountNotFound } from "./account-details.js"; +const AccountsMain = () => <div>AccountsMain disabled for debugging</div>; +const AccountDetails = () => <div>AccountDetails disabled for debugging</div>; +const AccountNotFound = () => <div>Not found</div>; import "./users.scss"; import { fsinfo } from 'cockpit/fsinfo'; Other changes, like adding large string constants, didn't help (165K → 166K). Now, other pages are much larger than that, so it's somehow related to the chunk size. I was experimenting with getting sizes around 64K (slightly lower or higher), but no conclusive results.
Pages for individual accounts work, ".../users#/root", for example.
The page with the group and account lists uses two highly suspect useEffect hooks that accidentally trigger on every render. On the first render, the hook navigates to the current URL. This used to be ignored, but now triggers an actual page reload, which starts this whole process again. A quick fix is to supress our navigation requests if the URL wouldn't actually change: diff --git a/pkg/users/accounts-list.js b/pkg/users/accounts-list.js index a652990970..3d8c64b802 100644 --- a/pkg/users/accounts-list.js +++ b/pkg/users/accounts-list.js @@ -49,6 +49,7 @@ import { GroupActions } from "./group-actions.jsx"; import { usePageLocation } from "hooks"; import { KebabDropdown } from "cockpit-components-dropdown"; +import { dequal } from 'dequal/lite'; const _ = cockpit.gettext; @@ -250,7 +251,10 @@ const GroupsList = ({ groups, accounts, isExpanded, setIsExpanded, min_gid, max_ } else { delete newOptions.group; } - cockpit.location.go([], newOptions); + if (!dequal(options, newOptions)) { + console.log("GO", options, newOptions); + cockpit.location.go([], newOptions); + } } else { setCurrentTextFilter(options.group || ""); } @@ -370,7 +374,10 @@ const AccountsList = ({ accounts, current_user, groups, min_uid, max_uid, shells } else { delete newOptions.user; } - cockpit.location.go([], newOptions); + if (!dequal(options, newOptions)) { + console.log("GO", options, newOptions); + cockpit.location.go([], newOptions); + } } else { setCurrentTextFilter(options.user || ""); } A better fix would be to get rid of the useEffect hooks and do the necessary actions in the change handler for the search input. I can work on that. I haven't looked at the services page yet.
> I haven't looked at the services page yet. It has a similar useEffect hook that triggers too often, and which ultimately calls cockpit.location.go. I now think we should change cockpit.location.go to catch no-op navigation requests. I'll make a PR if that works out. The useEffect hook uses are still "wrong" and should be fixed, but we might not want to find them all with urgency right now.
> that accidentally trigger on every render. Just to be fair: not on every render, but clearly too often.
> I now think we should change cockpit.location.go to catch no-op navigation requests. https://github.com/cockpit-project/cockpit/pull/22731 Also, the services and accounts pages should probably use cockpit.location.replace instead of c.l.go. The former doesn't trigger the looping bug and also doesn't put an entry into the browsing history for each key press in the search input. Also, even with the looping bug fixed, each legitimate change of window.location.hash would still trigger a full page reload, so typing into the search input would reload the page after each key press with Firefox 146 and 147.
https://github.com/cockpit-project/cockpit/pull/22731 landed and will be in the next release. That's all the bandaid/workaround that we can do on the Cockpit side. Firefox 148 should release end of Feb (https://whattrainisitnow.com/calendar/)
FEDORA-2026-257a6ebef0 (cockpit-354-1.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-257a6ebef0
Thanks. I guess we'll want it for F42 and F43 too. I'll tweak openQA to check if the test passes now.
FEDORA-2026-3c4cf60c3f (cockpit-354-1.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2026-3c4cf60c3f
FEDORA-2026-339716978c (cockpit-354-1.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2026-339716978c
Adam: just submitted. Fun timing conspiracy with "major breakage", "happened over the holidays", and "have to do the whole release manually because packit failure". Thanks for re-testing!
FEDORA-2026-257a6ebef0 (cockpit-354-1.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.
Confirmed the disabled test section passes again now, so I've re-enabled it. Thanks for the work on this.
Cheers Adam! Would you mind +1'ing the F43/42 updates, so that they can land faster than 2 weeks? Thanks!
FEDORA-2026-3c4cf60c3f has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-3c4cf60c3f` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-3c4cf60c3f See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-339716978c (cockpit-354-1.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.