https://bugs.kde.org/show_bug.cgi?id=525223
Bug ID: 525223
Summary: Renamed tab stops painting its label when a program in
it changes the terminal title
Classification: Applications
Product: konsole
Version First 26.08.0
Reported In:
Platform: Fedora RPMs
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: tabbar
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
DESCRIPTION
Once a Konsole tab has been renamed through the "Rename Tab" dialog
(`Ctrl+Alt+S`),
its label stops being painted as soon as a program running inside that tab
changes
the terminal title while the tab is inactive. The tab becomes visually empty -
only the close button is left - even though Konsole still holds the correct
title
internally.
Switching to the affected tab repaints the label correctly, and switching away
keeps it visible until the program issues its next title change, at which point
it blanks again. Tabs that were never renamed are unaffected and display titles
from the same programs normally.
The defect appears to be in painting the tab label specifically, not in the tab
widget or the stored title: the tab's width still tracks the current title
string,
and other parts of the tab (such as the colour stripe) repaint on demand - only
the text is missing.
STEPS TO REPRODUCE
1. Open Konsole, create a second tab (`Ctrl+Shift+T`).
2. Rename the second tab via `Ctrl+Alt+S` (e.g. to `asd`).
3. In that tab run a program that sets the terminal title, e.g. `htop`.
4. Switch to the first tab so the renamed one becomes inactive.
OBSERVED RESULT
The renamed tab's label goes completely blank - only the close button remains.
Activating the tab restores the text; leaving it again re-blanks it on the
program's next title update.
EXPECTED RESULT
The tab keeps showing the user-assigned name.
SOFTWARE/OS VERSIONS
Operating System: Fedora Linux 44
KDE Plasma Version: 6.7.4
KDE Frameworks Version: 6.29.0
Qt Version: 6.11.1
Konsole Version: 26.08.0
Kernel Version: 7.1.12-200.fc44.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 16 × Intel® Core™ i7-10875H CPU @ 2.30GHz
Memory: 32 ГиБ of RAM (30.7 ГиБ usable)
Graphics Processor 1: Intel® UHD Graphics
Graphics Processor 2: NVIDIA GeForce RTX 2080 Super with Max-Q Design
ADDITIONAL INFORMATION
- A neighbouring tab that was not renamed, running the same `htop`, renders
correctly. Renaming is required to trigger it.
- Over D-Bus, `Session.tabTitleFormat(0)` and `Session.title(1)` both return
the correct string while the label is blank - the model is intact, only
painting fails.
- Setting a longer title over D-Bus makes the tab GROW WIDER while still
painting
no text, so the string does reach the layout/size-hint path.
- `Session.setTabColor()` repaints the tab's colour stripe immediately, so the
widget itself is repainting.
- Not a one-off latch: forcing a full tab-bar relayout
(`Window.moveSessionRight` + `moveSessionLeft`) restores the text, but the
program's next title update blanks it again.
- Renaming over D-Bus (`setTabTitleFormat`, either or both contexts) does not
reproduce it - only the `Ctrl+Alt+S` dialog does.
- Reproduces identically with `QT_QPA_PLATFORM=xcb`, so it is not
Wayland-specific.
- Distinct from Bug 472548, which is about a 2-second delay rather than missing
text.
WHY THIS MATTERS IN PRACTICE
This is easy to hit with any long-running TUI (`htop`, `top`, `watch`), but it
is especially painful with AI coding assistants such as Claude Code, which
update the terminal title continuously while working. Users who keep several
named tabs - one per project or task - lose all their tab names as soon as the
assistant starts, which defeats the purpose of naming them. Note that
`CLAUDE_CODE_DISABLE_TERMINAL_TITLE=1` does not reliably prevent the title
updates, so users cannot work around it from that side.
--
You are receiving this mail because:
You are watching all bug changes.
