github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-12 02:24:21 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

Add PR Status Indicators in Gitea Browser Tab #14543

New Issue
Open
opened 2025-11-02 11:15:46 -06:00 by GiteaMirror · 13 comments
GiteaMirror commented 2025-11-02 11:15:46 -06:00
Owner
Copy Link

Originally created by @VinothKumar-Ganesan on GitHub (Jun 4, 2025).

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

Image

Originally created by @VinothKumar-Ganesan on GitHub (Jun 4, 2025). ### 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 ![Image](https://github.com/user-attachments/assets/5ed3e204-3137-4969-95bf-dbf89e6c7f83)
GiteaMirror added the proposal/acceptedtype/proposal labels 2025-11-02 11:15:46 -06:00
GiteaMirror commented 2025-11-02 11:15:47 -06:00
Author
Owner
Copy Link

@silverwind commented on GitHub (Jun 4, 2025):

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.

@silverwind commented on GitHub (Jun 4, 2025): 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.
GiteaMirror commented 2025-11-02 11:15:47 -06:00
Author
Owner
Copy Link

@a1012112796 commented on GitHub (Jun 4, 2025):

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.

@a1012112796 commented on GitHub (Jun 4, 2025): > 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.
GiteaMirror commented 2025-11-02 11:15:48 -06:00
Author
Owner
Copy Link

@silverwind commented on GitHub (Jun 4, 2025):

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 commented on GitHub (Jun 4, 2025): 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.
GiteaMirror commented 2025-11-02 11:15:48 -06:00
Author
Owner
Copy Link

@silverwind commented on GitHub (Jun 4, 2025):

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.

@silverwind commented on GitHub (Jun 4, 2025): 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.
GiteaMirror commented 2025-11-02 11:15:48 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Jun 4, 2025):

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

@lunny commented on GitHub (Jun 4, 2025): There should be three statuses `success`, `failure` and `pending`. This will be aligned with Github.
GiteaMirror commented 2025-11-02 11:15:48 -06:00
Author
Owner
Copy Link

@silverwind commented on GitHub (Jun 5, 2025):

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.

@silverwind commented on GitHub (Jun 5, 2025): 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.
GiteaMirror commented 2025-11-02 11:15:49 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Jun 5, 2025):

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
@lunny commented on GitHub (Jun 5, 2025): 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
GiteaMirror commented 2025-11-02 11:15:49 -06:00
Author
Owner
Copy Link

@silverwind commented on GitHub (Jun 6, 2025):

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 commented on GitHub (Jun 6, 2025): 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.
GiteaMirror commented 2025-11-02 11:15:49 -06:00
Author
Owner
Copy Link

@silverwind commented on GitHub (Jun 6, 2025):

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 commented on GitHub (Jun 6, 2025): Oh and I think as long as we support PNG favicon fallbacks (I think they are still needed for Safari as per [this](https://caniuse.com/link-icon-svg)), we have to generate the PNGs. Should be possible to extend `make generate-images` to include the new files.
GiteaMirror commented 2025-11-02 11:15:49 -06:00
Author
Owner
Copy Link

@silverwind commented on GitHub (Jun 6, 2025):

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.

@silverwind commented on GitHub (Jun 6, 2025): > 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.
GiteaMirror commented 2025-11-02 11:15:49 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Jun 6, 2025):

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

@lunny commented on GitHub (Jun 6, 2025): There is a convert function to convert actions status to status. I think we can do that when rendering the icons.
GiteaMirror commented 2025-11-02 11:15:49 -06:00
Author
Owner
Copy Link

@silverwind commented on GitHub (Jun 6, 2025):

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

@silverwind commented on GitHub (Jun 6, 2025): Sounds good, but I would even go a step further and name it "status" instead of "commit status".
GiteaMirror commented 2025-11-02 11:15:50 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Jun 9, 2025):

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

Now, it's ready since #34562 is merged.

@lunny commented on GitHub (Jun 9, 2025): > Yes, I also think there should be icons. I have sent [#34562](https://github.com/go-gitea/gitea/pull/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 Now, it's ready since #34562 is merged.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label proposal/accepted type/proposal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#14543
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?