Stale tab titles

Bug #1520377 reported by Egmont Koblinger
34
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Terminator
Fix Released
Medium
Stephen Boddy

Bug Description

Bringing bug 1160508 and bug 1225819 here.

The tab titles do not update properly when closing one window of a split.

Steps to reproduce:
1. Open Terminator.
2. Create another tab (Ctrl-Shift-T).
3. Split the tab vertically (Ctrl-Shift-E).
4. In the active window, change the directory to something else (for example, cd /).
5. Exit the shell of the active window (Ctrl-D).

Expected results:
The second tab title is the same as the title of the remaining window of the split, showing the home directory (user@host: ~).

Actual results:
The second tab title is left over from the closed tab, showing the directory changed to (user@host: /).

Note: In order for the bug to occur, it might be required that all the terminals set their title at least once via escape sequences, and practically to different values.

Related branches

Revision history for this message
Egmont Koblinger (egmont-gmail) wrote :

Results so far:

My bash prompt sets the window title to the tty number, a unique number for each terminal at a time. I'm testing by starting up Terminator, then pressing Ctrl+Shift+T, Ctrl+Shift+E, Ctrl+D.

paned.py -> wrapcloseterm(), "At this point we only have one child, which is the surviving term". Notebook's vpaned or hpaned child is removed and we're about to add the terminal directly as the new child. Hence "parent.add(sibling, metadata)" is called.

metadata, for some reason, contains the title of the tab that's being removed.

notebook.py -> add(), calls newtab() in turn. Due to metadata['label'] being defined, calls label.set_custom_label() in turn. Things obviously go wrong from this point.

Revision history for this message
Egmont Koblinger (egmont-gmail) wrote :

With a bit of luck, the fix for this really hard to track down bug is as simple as this patch, without side effects.

Revision history for this message
Egmont Koblinger (egmont-gmail) wrote :

@Jon Ives
@Alexey Kotlyarov

Could you please try this patch and let us know if it works reliably and fixes the issue for you?

Revision history for this message
Alexey Kotlyarov (koterpillar) wrote :

The patch works perfectly for me.

Revision history for this message
Stephen Boddy (stephen-j-boddy) wrote :

There is a problem with this patch (at least for me).

With the steps in the description, instead of splitting your new tab, move to a unique folder, then switch back to the first tab and split that one. Then continue.

The problem is that the first tab "jumps" to the end, after the second tab.

Revision history for this message
Egmont Koblinger (egmont-gmail) wrote :

So, what are the exact steps, one by one?

1. Start terminator
2. Ctrl+Shift+T
3. (in the 2nd tab where you are right now) cd /etc
4. Switch to the 1st tab
5. Ctrl+Shift+E (split)
6. Ctrl+D (exit)

Do the two tabs switch for you, that is you have /etc in the left one? With gtk3? Well, this doesn't happen for me.

Revision history for this message
Stephen Boddy (stephen-j-boddy) wrote :

Yup. Exactly those steps for me result in the /etc tab being to the left, and the tab of the remaining split term being on the right.

@Alexey: Does the patch still work if you do as comment #6?

If you can paste the following details too (assumes you are on Ubuntu):

- dpkg -l | grep libgtk-3-bin

For ref, I'm on Ubuntu 14.04, with GTK3 "3.10.8-0ubuntu1.6"

I have some tab related code that I was working on for the maximise/zoom of a single term under a tab that was having to deal with this crap, where the child (single term) is removed, and the tab got auto cleaned. Then on restore, the tab was recreated at the end. It might be generic enough to fix this. I'll take a look when I get chance. It may be that GTK has changed the default in newer versions to require explicit tab deletion rather than auto clean by default.

Changed in terminator:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Alexey Kotlyarov (koterpillar) wrote :

The tabs are fine for me if I do the sequence in #6, i.e. the /etc tab is on the right.

I am on Arch, so:

$ LC_ALL=C pacman -Qi gtk3 | grep Version
Version : 3.18.5-1

Revision history for this message
Stephen Boddy (stephen-j-boddy) wrote :

Yeah, you are on a very recent GTK too, like Egmont. I suspect behaviour changed (yet again!!!) in GTK.

Anyone else out there following this who is on older GTK3?

I'll see if I can fix this for old and new GTK3.

Changed in terminator:
status: Confirmed → In Progress
assignee: nobody → Stephen Boddy (stephen-j-boddy)
Revision history for this message
Egmont Koblinger (egmont-gmail) wrote :

Worst-worst-worst-case: Manually test various gtk versions which one works which way, and add a run-time branch on that. Ugly as hell.

Revision history for this message
Sparhawk (sparhawkthesecond) wrote :

I'm using Arch Linux too. I also see this bug, so I tested the patch. This fixes the split-window issue for a single tab, but I now see the switched-tab problem from #6, i.e. the /etc tab is on the left.

terminator-gtk3-bzr r1641-1

Revision history for this message
Stephen Boddy (stephen-j-boddy) wrote :

I found the proper fix for this. The problem was that when closing the second-last terminal we grab some metadata to rebuild the tab properly. We were grabbing the tab title as metadata and then setting it so that it was acting as a custom tab title. You can see this by double clicking the "frozen" tab title to edit it, then deleting the contents. This reverts to paying attention to shell escape codes and changing as expected. All I needed to do was slightly alter the notebook get_child_metadata to account for the fact that a tab title may not be customised.

Fixed in gtk branch rev 1649

Changed in terminator:
status: In Progress → Fix Committed
Revision history for this message
Sparhawk (sparhawkthesecond) wrote :

Thank you for the fix! Is there any chance of this fix making it into the gtk2 terminator? I find the gtk3 version a little too buggy for general use at the moment.

Revision history for this message
Stephen Boddy (stephen-j-boddy) wrote :

Sigh. Better would be to identify what exactly is buggy so it can be fixed, and you can get moved to the modern toolkit and VTE. Are there specific launchpad bugs you consider blockers for you to use gtk3?

Revision history for this message
Stephen Boddy (stephen-j-boddy) wrote :

I should add that the place to talk about gtk3 release blockers is in the porting bug: https://bugs.launchpad.net/terminator/+bug/1030562

Revision history for this message
Sparhawk (sparhawkthesecond) wrote :

Fair enough. That sigh is probably warranted.

TBH I haven't investigated the specific bugs because I just haven't invested the time in it. I *do* want to move to vte3, and terminator is by far my preferred emulator, so I'll get onto it. The specific bugs that are preventing me from moving are having the cursor disappear in zsh and some focus issues (I can't use a keyboard shortcut that prints strings with xvkbd).

I'm happy to write up full bug reports though. Cheers.

Revision history for this message
Egmont Koblinger (egmont-gmail) wrote :

As for cursor disappearing in zsh: That's purely vte's business, it would be great to see steps to reproduce. We're not aware of any cursor-related bugs in the most recent vte versions.

As for xvkbd: I'm not aware of that tool but it sounds somewhat similar to xdotool. See the discussion at https://bugzilla.xfce.org/show_bug.cgi?id=12926 (also following the stackoverflow link from there).

Changed in terminator:
status: Fix Committed → Fix Released
Revision history for this message
Sparhawk (sparhawkthesecond) wrote :

Ahhhh… after writing up a very lovely bug report, I've realised the missing cursor problem was from an issue with zsh-syntax-highlighting [1]. Oddly enough I only saw it in terminator, and not other vte3 emulators like gnome-terminal and roxterm. And only with "blink" off, which (related?) is not available in the other two terminal emulators. Removing "cursor" from the zsh-syntax-highlighting module fixes it.

As for the xvkbd issue, it actually seems to fail in a few other applications as well; I had just never tested them. Thanks for the hint with xdotool. It is indeed similar, but unfortunately xdotool fails universally for me! I'll chase it up myself, but I'm fairly sure now that it's not a terminator bug.

Thanks again for your help.

[1] https://github.com/zsh-users/zsh-syntax-highlighting/issues/171

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Patches

Remote bug watches

Bug watches keep track of this bug in other bug trackers.