2006783 - Reload loop in services page of Cockpit's portal

Status: RESOLVED WORKSFORME

(Web Compatibility :: Site Reports, defect, P3)

Description

[Carol Ouellet]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:146.0) Gecko/20100101 Firefox/146.0

Steps to reproduce:

• Login to any Cockpit (Redhat) portal
• Go to Services page

Actual results:

The Services page is stuck in a reloading loop that never ends.
All other pages are fine.

Expected results:

The Services page should load once and be usable

Comment 1

[Gurenko Alex]

Same on account page in cockpit, both on Red Hat shipped version and upstream version in Fedora repo, including latest update from 18.12.2025.

Console shows following repeating error:

Content-Security-Policy: Ignoring ‘block-all-mixed-content’ because mixed content display upgrading makes block-all-mixed-content obsolete. index.html
downloadable font: download failed (font-family: "Red Hat Display" style:normal weight:400..700 stretch:100 src index:0): status=2152398850 source: https://<hostname>:9090/cockpit/static/fonts/RedHatDisplay/RedHatDisplayVF.woff2

Comment 2

[James Graham [:jgraham]]

I could reproduce this with a local install. It seems like there's a js-triggered reload for some reason. Given that Firefox is a supported browser it seems like it might be worth filing a bug in https://github.com/cockpit-project/cockpit/issues.

Comment 3

[Carol Ouellet]

Thank James, I've opened a bug on Firefox's side

Comment 4

[Carol Ouellet]

(In reply to Carol Ouellet from comment #3)

Thank James, I've opened a bug on Firefox's side

I meant Cockpit project's side.

Comment 5

[Milan]

I have the same issue.

Comment 6

[Valentin Gosu [:valentin] {{PTO until Nov 1st}}]

Hi Carol,

The patch at https://github.com/cockpit-project/cockpit/pull/22731/changes states this is fixed in Firefox 148.
Could you run https://mozilla.github.io/mozregression/quickstart.html to figure out what introduced the bug, and ideally what fixed it, so we can try to uplift to a dot release if possible, but otherwise 148 will be out on 24 feb

Comment 7

[Carol Ouellet]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #6)

Hi Carol,

The patch at https://github.com/cockpit-project/cockpit/pull/22731/changes states this is fixed in Firefox 148.
Could you run https://mozilla.github.io/mozregression/quickstart.html to figure out what introduced the bug, and ideally what fixed it, so we can try to uplift to a dot release if possible, but otherwise 148 will be out on 24 feb

Hi Valentin
I've tried to test out the different versions by release numbers and by dates and no mater which I take from the nightlys, they never have any issue with the Cockpit website.

So no matter which version between 145 and 148, they are all working fine, while my current Firefox release 147.01 still has the issue.

I also tried using my current release's profile as well which made no difference.

Any idea?

Comment 8

[Carol Ouellet]

to add to my previous comment:
I've installed Firefox Beta 148.0b8 on a freshly created Windows 11 VM, the infinite reload bug is still present.

It would seem that there is some process in the nightly version which removes that bug. How could that be?

Comment 9

[Gurenko Alex]

For me Enchanced Tracking Protection is what restores the functionality. Does not matter which state it's in, cycling it works until cache expires or ctrl+F5 reload. Then same trick works. That's on 147.0.x: https://e.pcloud.link/publink/show?code=XZrFMaZY65Wwzudwgbeg4eHGn54F7wf60QX (screen recording with ctrl+F5 in between)

Comment 10

[Carol Ouellet]

I think this is because the Enhanced Tracking Protection will do a simple refresh (F5).
You could also just do F5 when it started auto refreshing like that. It works for me anyway.

Comment 11

[Valentin Gosu [:valentin] {{PTO until Nov 1st}}]

Hi Carol, could you help us with a some HTTP logging?

Load this URL: about:logging?modules=timestamp%2Csync%2CnsHttp%3A5%2Ccache2%3A5%2CnsSocketTransport%3A5%2CnsHostResolver%3A5%2CEarlyHint%3A5%2CnsSecureBrowserUI%3A5&output=profiler&profilerstacks=&javascriptTracing=&profiler-preset=networking - Click start logging. Reproduce the issue with the reload, then Click stop logging and upload profile (top right of the page).

That should show us what's triggering the reload.
Thanks!

Comment 12

[Carol Ouellet]

Hi Valentin

I finally got some time to do this. I had to downgrade cockpit to 351 because starting on 354 they have put some workaround.
I've uploaded the logging https://share.firefox.dev/40cKdSS
Let me know if you want me to redo it. I'm keeping version 351 until this is fixed.

Comment 13

[Valentin Gosu [:valentin] {{PTO until Nov 1st}}]

Thank you for that.

I can see that the navigation has this stack trace:

Stack:

    set Location.hash
    gohttps://enki.pierrenoir.app:9090/cockpit/@localhost/base1/cockpit.js:6:5391
    onOptionsChangedhttps://enki.pierrenoir.app:9090/cockpit/@localhost/system/services.js:24:2784
    js::RunScript
    IN/<https://enki.pierrenoir.app:9090/cockpit/@localhost/system/services.js:24:11801
    js::RunScript
    Ndhttps://enki.pierrenoir.app:9090/cockpit/@localhost/system/services.js:8:24282
    zihttps://enki.pierrenoir.app:9090/cockpit/@localhost/system/services.js:8:41591
...

While I don't have access to the actual JS files, services.js::onLocationOptionsChanged
does have this: https://github.com/cockpit-project/cockpit/blob/952dfb66c8a8cfdc3d00c59b98f04a5b6821dbd3/pkg/systemd/services.jsx#L264

        cockpit.location.replace(cockpit.location.path, currentOptions);

Which brings me to:
https://github.com/cockpit-project/cockpit/blob/952dfb66c8a8cfdc3d00c59b98f04a5b6821dbd3/pkg/lib/cockpit/_internal/location.ts#L159

    replace(path: Path, options?: Options) {
        if (this.#hash_changed)
            return;
        const href = this.#href_for_go_or_replace(path, options);
        window.location.replace(window.location.pathname + '#' + href);
    }

Normally this shouldn't actually cause a navigation, if the pathname is the same, but it's possible that it's happening (will possibly be fixed by bug 1733797)

Carol, could you capture a profile again, this time with this link? (I added NavigationAPI:5)
about:logging?modules=timestamp%2Csync%2CNavigationAPI%3A5%2CnsHttp%3A5%2Ccache2%3A5%2CnsSocketTransport%3A5%2CnsHostResolver%3A5%2CEarlyHint%3A5%2CnsSecureBrowserUI%3A5&output=profiler&profilerstacks=&javascriptTracing=&profiler-preset=networking

Comment 14

[Carol Ouellet]

Hi Valentin

Great details, thank you.
See the new recorded profile https://share.firefox.dev/46ierYf

Comment 15

[Valentin Gosu [:valentin] {{PTO until Nov 1st}}]

Thanks for the profile. Seems pretty clear this is going through location.hash

LogMessages
Module:
NavigationAPI
Name:
Fire navigate cancelable reload https://enki.pierrenoir.app:9090/cockpit/@localhost/system/services.html#/
Track:
https://pierrenoir.app
Stack:

    set Location.hash
    gohttps://enki.pierrenoir.app:9090/cockpit/@localhost/base1/cockpit.js:6:5391
    onOptionsChangedhttps://enki.pierrenoir.app:9090/cockpit/@localhost/system/services.js:24:2784
    IN/<https://enki.pierrenoir.app:9090/cockpit/@localhost/system/services.js:24:11801
    Ndhttps://enki.pierrenoir.app:9090/cockpit/@localhost/system/services.js:8:24282
    zihttps://enki.pierrenoir.app:9090/cockpit/@localhost/system/services.js:8:41591
    nwhttps://enki.pierrenoir.app:9090/cockpit/@localhost/system/services.js:8:36845
    Oahttps://enki.pierrenoir.app:9090/cockpit/@localhost/system/services.js:6:3179
    OThttps://enki.pierrenoir.app:9090/cockpit/@localhost/system/services.js:8:40593
    flhttps://enki.pierrenoir.app:9090/cockpit/@localhost/system/services.js:8:40529
    Y0https://enki.pierrenoir.app:9090/cockpit/@localhost/system/services.js:8:35951
    mghttps://enki.pierrenoir.app:9090/cockpit/@localhost/system/services.js:1:8753
    cghttps://enki.pierrenoir.app:9090/cockpit/@localhost/system/services.js:1:9357
    EventHandlerNonNull

Comment 16

[Chris Peterson [:cpeterson]]

Normally this shouldn't actually cause a navigation, if the pathname is the same, but it's possible that it's happening (will possibly be fixed by bug 1733797)

A fix for bug 1733797 landed in Firefox Nightly 150.0a1 to prevent navigation when location.hash is set to the same hash string. Perhaps that will fix this Cockpit issue.

Comment 17

[Valentin Gosu [:valentin] {{PTO until Nov 1st}}]

Hi Carol, do you mind checking again with the latest Nightly?

Comment 18

[Wayne]

I know this is is an older report but I am posting this in case it might help someone else that may encounter this.
I am running Ubuntu server 24.4.4 LTS with Cockpit 314-1. I have been able to resolve this issue by turning off 'Enhanced tracking protection' in the address bar for my local URL.

Comment 19

[Wayne]

(In reply to Wayne from comment #18)

I know this is is an older report but I am posting this in case it might help someone else that may encounter this.
I am running Ubuntu server 24.04.4 LTS with Cockpit 314-1. I have been able to resolve this issue by turning off 'Enhanced tracking protection' in the address bar for my local URL.

Comment 20

[BugBot [:suhaib / :marco]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.

Comment 21

[Gurenko Alex]

It's been working for me for quite some time now, maybe this should be closed as fixed?

Comment 22

[Carol Ouellet]

Indeed this was resolved since release 150.
Again, I can't pinpoint exactly which push was the issue as there is no bug in any of the Nightly releases.

Thank you for the fix! :)

Comment 23

[Valentin Gosu [:valentin] {{PTO until Nov 1st}}]

Thank you for helping us with the investigation.