Always display the custom channel name in the article list view #42

Closed
opened 2026-07-03 07:55:54 -07:00 by serrebi · 1 comment
Owner

It is required to address the inconsistent behavior in the article list view where the channel name column does not reliably show the user‑defined custom name. Currently, in the ListView displaying articles (which includes multiple columns), the fourth column is intended to show the channel name. However, for some channels, the system displays the original feed title from the <title> tag instead of the custom name configured by the user. This inconsistency appears to stem from differing logic applied across various feed formats.

Impact and Rationale

The current behavior undermines the user’s organizational workflow:

  • The original feed title may be excessively long, potentially breaking the UI layout or requiring truncation.
  • It may be uninformative or generic (e.g., “News Feed” or the site name), failing to reflect the user’s categorization logic.
  • It can conflict with the user’s personal cataloging scheme, making it harder to quickly identify and manage feeds.

Proposed Solution

It is proposed to enforce a unified rule for the channel name display in the article list: the fourth column must always show the custom channel name as set by the user, regardless of the feed format or the content of the original <title> tag. The original title should be retained internally (for metadata or optional tooltips) but must not override the custom name in the main list view.

Expected Behavior

After implementation, the following behavior is expected:

Display Logic
  • In the article ListView, the fourth column shall exclusively display the custom channel name defined by the user in the channel settings.
  • This rule shall apply uniformly to all channels, irrespective of the feed type (RSS, Atom, etc.) or the structure of the source data.
Edge Cases
  • If a custom name has not been explicitly set by the user, the application may fall back to displaying the original <title> tag value.
  • Once a custom name is provided, it must take precedence in all subsequent displays, including after feed refreshes or application restarts.
UI Consistency
  • No conditional logic based on feed format should influence which title is shown; the priority order must be strictly: custom name → original title.
  • Any existing code paths that selectively render the original title instead of the custom name must be identified and corrected.

Additional Notes

  • The change should not affect other areas of the UI unless they similarly exhibit inconsistent title handling; this issue specifically targets the article list’s fourth column.
  • Testing should include feeds in different formats (RSS 2.0, RSS 1.0, Atom) and channels with both custom names and default titles to confirm consistent behavior.
It is required to address the inconsistent behavior in the article list view where the channel name column does not reliably show the user‑defined custom name. Currently, in the ListView displaying articles (which includes multiple columns), the fourth column is intended to show the channel name. However, for some channels, the system displays the original feed title from the `<title>` tag instead of the custom name configured by the user. This inconsistency appears to stem from differing logic applied across various feed formats. #### Impact and Rationale The current behavior undermines the user’s organizational workflow: - The original feed title may be excessively long, potentially breaking the UI layout or requiring truncation. - It may be uninformative or generic (e.g., “News Feed” or the site name), failing to reflect the user’s categorization logic. - It can conflict with the user’s personal cataloging scheme, making it harder to quickly identify and manage feeds. #### Proposed Solution It is proposed to enforce a unified rule for the channel name display in the article list: the fourth column must always show the custom channel name as set by the user, regardless of the feed format or the content of the original `<title>` tag. The original title should be retained internally (for metadata or optional tooltips) but must not override the custom name in the main list view. #### Expected Behavior After implementation, the following behavior is expected: ##### Display Logic - In the article ListView, the fourth column shall exclusively display the custom channel name defined by the user in the channel settings. - This rule shall apply uniformly to all channels, irrespective of the feed type (RSS, Atom, etc.) or the structure of the source data. ##### Edge Cases - If a custom name has not been explicitly set by the user, the application may fall back to displaying the original `<title>` tag value. - Once a custom name is provided, it must take precedence in all subsequent displays, including after feed refreshes or application restarts. ##### UI Consistency - No conditional logic based on feed format should influence which title is shown; the priority order must be strictly: custom name → original title. - Any existing code paths that selectively render the original title instead of the custom name must be identified and corrected. #### Additional Notes - The change should not affect other areas of the UI unless they similarly exhibit inconsistent title handling; this issue specifically targets the article list’s fourth column. - Testing should include feeds in different formats (RSS 2.0, RSS 1.0, Atom) and channels with both custom names and default titles to confirm consistent behavior. <!-- forgejo-github-sync: issue github=serrebidev/BlindRSS#43 -->
Author
Owner

Fixed in v1.77.5.

Good diagnosis on the symptom — though it turned out the feed format was never actually the trigger. The Feed column always shows the stored channel name; the problem was that refresh was reverting custom names back to the feed's <title> for channels renamed in older versions of BlindRSS (before the custom-name flag existed, February 2026). Channels whose feeds had no parsable title didn't revert, which made it look format-dependent.

What changed:

  • BlindRSS now tracks the feed-provided title separately from your channel name (the "retained internally" original title you suggested).
  • Refresh only auto-updates the visible name while it still matches what the feed itself last reported. Anything else is treated as your rename and preserved permanently — priority is strictly: custom name → original title, everywhere, for every feed format.
  • Your existing renamed channels self-heal automatically: after one refresh on v1.77.5 they're flagged as custom and will never revert again.
  • Bonus: Reset Title to Feed Default in the channel context menu now takes effect immediately instead of waiting for the next refresh.

Thanks for the report!

Fixed in [v1.77.5](https://github.com/serrebidev/BlindRSS/releases/tag/v1.77.5). Good diagnosis on the symptom — though it turned out the feed format was never actually the trigger. The Feed column always shows the stored channel name; the problem was that **refresh** was reverting custom names back to the feed's `<title>` for channels renamed in older versions of BlindRSS (before the custom-name flag existed, February 2026). Channels whose feeds had no parsable title didn't revert, which made it look format-dependent. What changed: - BlindRSS now tracks the feed-provided title separately from your channel name (the "retained internally" original title you suggested). - Refresh only auto-updates the visible name while it still matches what the feed itself last reported. Anything else is treated as your rename and preserved permanently — priority is strictly: custom name → original title, everywhere, for every feed format. - Your existing renamed channels self-heal automatically: after one refresh on v1.77.5 they're flagged as custom and will never revert again. - Bonus: **Reset Title to Feed Default** in the channel context menu now takes effect immediately instead of waiting for the next refresh. Thanks for the report! <!-- forgejo-github-sync: comment github=serrebidev/BlindRSS#43/4877699333 -->
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
serrebi/BlindRSS#42
No description provided.