Add PR Status Indicators in Gitea Browser Tab

[VinothKumar-Ganesan]

Feature Description

Hi Team,

I’ve noticed that in GitHub, the browser tab dynamically updates to show PR statuses (e.g., yellow dot for pending checks, green for passed, red for failed). This provides a quick visual cue when monitoring pull requests during code review or CI runs.

Currently, Gitea does not support this feature out-of-the-box. I’d like to explore the possibility of implementing a similar experience in our Gitea instance.

🔍 Idea Summary:
Add visual indicators (dot icons or status-based favicon) to the browser tab when viewing pull requests.

This could reflect the latest CI/CD check status (pending, success, failure).

Options:

Use a custom JavaScript snippet to modify the favicon dynamically based on API responses.

Create a browser userscript (e.g., via Tampermonkey).

Modify Gitea’s frontend templates to support this natively (less preferred unless we maintain a fork).

✅ Benefits:
Quickly track CI status without switching tabs.

Improves developer workflow during code reviews.

Aligns the UX closer to what developers expect from platforms like GitHub.

Screenshots

[silverwind]

It is possible to dynamically replace the favicon both from backend and frontend, but the problem is that the favicon is customizable via custom/favicon.svg replacement file and I think quite a few users do this. So I suggest to not enable the replacement mechanism when a custom favicon is detected.

[a1012112796]

It is possible to dynamically replace the favicon both from backend and frontend, but the problem is that the favicon is customizable via custom/favicon.svg replacement file and I think quite a few users do this. So I suggest to not enable the replacement mechanism when a custom favicon is detected.

user can add them also, example custom/favicon_success.svg and so on.

[silverwind]

Hmm yeah, we can support such variants, good idea. We should check for existance of a full set of the status icons in the custom folder, if they are only there partially, it's better to not mix ours and the users custom icons.

[silverwind]

So I'd suggest:

• favicon.svg existing icon, unchanged
• favicon-success.svg
• favicon-warning.svg
• favicon-error.svg

The implementation could be backend-only and only for pull requests and possibly actions pages, e.g. deliver a dynamic icon in the HTML templates, maybe with a template context variable like FaviconVariant=success.

For customization, only use the icons from the custom folder if all variants are present. If some files in custom are missing, use custom/favicon.svg in all cases.

[lunny]

There should be three statuses success, failure and pending. This will be aligned with Github.

[silverwind]

I'd rather have the icons named by intent instead of any concrete status because then they can be used in all places. They will be used in at least commit status and workflow status, and IIRC, those have different status names.

Another benefit is we don't need to add new icons when new statuses are introduced, we can just map status to icon.

[lunny]

Yes, I also think there should be icons. I have sent #34562 to standardize all merged statuses to only success, failure, and pending, which aligns with GitHub’s implementation for consistency.

After that PR merged, I think we can have the four icons.

• favicon.svg existing icon, unchanged as fallback icon
• favicon-success.svg success status
• favicon-pending.svg pending status
• favicon-failure.svg failure status

[silverwind]

Will these names work on all action pages as well? Do workflows and jobs all use the same status names? I just want to ensure we can re-use these icons in the future. For all I care, the names could even be favicon-red-dot, favicon-yellow-dot etc. I just want to avoid tying the names to one use case.

[silverwind]

Oh and I think as long as we support PNG favicon fallbacks (I think they are still needed for Safari as per this), we have to generate the PNGs. Should be possible to extend make generate-images to include the new files.

[silverwind]

Will these names work on all action pages as well? Do workflows and jobs all use the same status names? I just want to ensure we can re-use these icons in the future. For all I care, the names could even be favicon-red-dot, favicon-yellow-dot etc. I just want to avoid tying the names to one use case.

Actually scheme favicon-pending might be ok, assuming we can map down the action-related statuses to these. favicon-yellow-dot is actually a bad idea because maybe later we want to replace the dot with a hourglass, so a descriptive name is better.

[lunny]

There is a convert function to convert actions status to status. I think we can do that when rendering the icons.

[silverwind]

Sounds good, but I would even go a step further and name it "status" instead of "commit status".