Tabs moving out of order randomly

I'm unclear exactly how to reproduce this. My setup is a single window with several tabs. Sometimes, a tab will move out of order in the list. When I Command-Shift-] or Command-Shift-[ to where the tab should be, it goes to the tab, but its position in the tab bar is in the wrong spot. The tabs also seem to keep their original Command-number shortcuts. I can drag the tab back to where it is supposed to be.

I am using Build 3.0.20160729-nightly

There's an OS bug where dragging tabs in a fullscreen window can cause them to end up out of order (the OS never informs us when the drag ends). This only occurs when the tab bar is where the menu bar would usually be. Is it possible that you're hitting this issue?

I doubt it. I don't use full screen (I just keep my window maximized), and I don't really reorder tabs very often.

Strange. Do keep an eye out and see if you can find reproduction steps. Also check for exceptions in /var/log/system.log as soon as you notice the issue, as that could cause the internal state of the tab bar to get broken.

Just saw it again and this was at the tail of /var/log/system.log:

Aug 15 18:55:08 Aarons-Retina-MacBook-Pro iTerm2[940]: Active space did change
Aug 15 18:55:24 --- last message repeated 1 time ---
Aug 15 18:55:24 Aarons-Retina-MacBook-Pro iTerm2[940]: Time to encode state for window <PseudoTerminal: 0x7f95a542d850 tabs=13 window=<iTermWindow: 0x7f95a70ab750 frame=NSRect: {{0, 4}, {1440, 873}} title=1. bash alpha=1.000000 isMain=0 isKey=0 isVisible=1 delegate=0x7f95a542d850>>: 0.05252701044082642
Aug 15 18:56:15 Aarons-Retina-MacBook-Pro iTerm2[940]: Active space did change
Aug 15 18:58:08 Aarons-Retina-MacBook-Pro iTerm2[940]: Active space did change
Aug 15 18:58:18 --- last message repeated 1 time ---
Aug 15 18:58:18 Aarons-Retina-MacBook-Pro iTerm2[940]: Time to encode state for window <PseudoTerminal: 0x7f95a542d850 tabs=13 window=<iTermWindow: 0x7f95a70ab750 frame=NSRect: {{0, 4}, {1440, 873}} title=1. python3.5 alpha=1.000000 isMain=0 isKey=0 isVisible=1 delegate=0x7f95a542d850>>: 0.04771000146865845
Aug 15 18:58:19 Aarons-Retina-MacBook-Pro iTerm2[940]: Active space did change
Aug 15 18:58:24 --- last message repeated 1 time ---
Aug 15 18:58:24 Aarons-Retina-MacBook-Pro iTerm2[940]: Time to encode state for window <PseudoTerminal: 0x7f95a542d850 tabs=13 window=<iTermWindow: 0x7f95a70ab750 frame=NSRect: {{0, 4}, {1440, 873}} title=1. python3.5 alpha=1.000000 isMain=0 isKey=0 isVisible=1 delegate=0x7f95a542d850>>: 0.0473400354385376
Aug 15 18:59:55 Aarons-Retina-MacBook-Pro iTerm2[940]: Active space did change
Aug 15 18:59:55 Aarons-Retina-MacBook-Pro syslogd[57]: ASL Sender Statistics
Aug 15 19:00:25 Aarons-Retina-MacBook-Pro iTerm2[940]: Time to encode state for window <PseudoTerminal: 0x7f95a542d850 tabs=13 window=<iTermWindow: 0x7f95a70ab750 frame=NSRect: {{0, 4}, {1440, 873}} title=1. emacsclient alpha=1.000000 isMain=1 isKey=1 isVisible=1 delegate=0x7f95a542d850>>: 0.04830002784729004
Aug 15 19:00:56 Aarons-Retina-MacBook-Pro iTerm2[940]: Time to encode state for window <PseudoTerminal: 0x7f95a542d850 tabs=13 window=<iTermWindow: 0x7f95a70ab750 frame=NSRect: {{0, 4}, {1440, 873}} title=1. emacsclient alpha=1.000000 isMain=1 isKey=1 isVisible=1 delegate=0x7f95a542d850>>: 0.0535159707069397
Aug 15 19:01:34 Aarons-Retina-MacBook-Pro iTerm2[940]: Time to encode state for window <PseudoTerminal: 0x7f95a542d850 tabs=13 window=<iTermWindow: 0x7f95a70ab750 frame=NSRect: {{0, 4}, {1440, 873}} title=1. emacsclient alpha=1.000000 isMain=1 isKey=1 isVisible=1 delegate=0x7f95a542d850>>: 0.05550003051757812
Aug 15 19:01:38 Aarons-Retina-MacBook-Pro com.apple.xpc.launchd[1] (com.apple.imfoundation.IMRemoteURLConnectionAgent): Unknown key for integer: _DirtyJetsamMemoryLimit
Aug 15 19:02:07 Aarons-Retina-MacBook-Pro iTerm2[940]: Time to encode state for window <PseudoTerminal: 0x7f95a542d850 tabs=13 window=<iTermWindow: 0x7f95a70ab750 frame=NSRect: {{0, 4}, {1440, 873}} title=1. emacsclient alpha=1.000000 isMain=1 isKey=1 isVisible=1 delegate=0x7f95a542d850>>: 0.04780697822570801
Aug 15 19:02:25 Aarons-Retina-MacBook-Pro com.apple.xpc.launchd[1] (com.adobe.fpsaud[60393]): Service exited with abnormal code: 209
Aug 15 19:02:39 Aarons-Retina-MacBook-Pro iTerm2[940]: Time to encode state for window <PseudoTerminal: 0x7f95a542d850 tabs=13 window=<iTermWindow: 0x7f95a70ab750 frame=NSRect: {{0, 4}, {1440, 873}} title=1. emacsclient alpha=1.000000 isMain=1 isKey=1 isVisible=1 delegate=0x7f95a542d850>>: 0.04751098155975342
Aug 15 19:03:10 Aarons-Retina-MacBook-Pro iTerm2[940]: Time to encode state for window <PseudoTerminal: 0x7f95a542d850 tabs=13 window=<iTermWindow: 0x7f95a70ab750 frame=NSRect: {{0, 4}, {1440, 873}} title=1. emacsclient alpha=1.000000 isMain=1 isKey=1 isVisible=1 delegate=0x7f95a542d850>>: 0.04671394824981689
Aug 15 19:03:31 Aarons-Retina-MacBook-Pro iTerm2[940]: Active space did change
Aug 15 19:03:31 Aarons-Retina-MacBook-Pro iTerm2[940]: Time to encode state for window <PseudoTerminal: 0x7f95a542d850 tabs=13 window=<iTermWindow: 0x7f95a70ab750 frame=NSRect: {{0, 4}, {1440, 873}} title=1. emacsclient alpha=1.000000 isMain=0 isKey=0 isVisible=1 delegate=0x7f95a542d850>>: 0.05098700523376465
Aug 15 19:03:38 Aarons-Retina-MacBook-Pro iTerm2[940]: Active space did change
Aug 15 19:04:07 Aarons-Retina-MacBook-Pro iTerm2[940]: Time to encode state for window <PseudoTerminal: 0x7f95a542d850 tabs=13 window=<iTermWindow: 0x7f95a70ab750 frame=NSRect: {{0, 4}, {1440, 873}} title=1. emacsclient alpha=1.000000 isMain=1 isKey=1 isVisible=1 delegate=0x7f95a542d850>>: 0.04665297269821167
Aug 15 19:04:38 Aarons-Retina-MacBook-Pro iTerm2[940]: Time to encode state for window <PseudoTerminal: 0x7f95a542d850 tabs=13 window=<iTermWindow: 0x7f95a70ab750 frame=NSRect: {{0, 4}, {1440, 873}} title=1. emacsclient alpha=1.000000 isMain=1 isKey=1 isVisible=1 delegate=0x7f95a542d850>>: 0.0488860011100769
Aug 15 19:04:48 Aarons-Retina-MacBook-Pro iTerm2[940]: Time to encode state for window <PseudoTerminal: 0x7f95a542d850 tabs=13 window=<iTermWindow: 0x7f95a70ab750 frame=NSRect: {{0, 4}, {1440, 873}} title=1. make alpha=1.000000 isMain=0 isKey=0 isVisible=1 delegate=0x7f95a542d850>>: 0.0638890266418457
Aug 15 19:05:19 Aarons-Retina-MacBook-Pro iTerm2[940]: Time to encode state for window <PseudoTerminal: 0x7f95a542d850 tabs=13 window=<iTermWindow: 0x7f95a70ab750 frame=NSRect: {{0, 4}, {1440, 873}} title=1. make alpha=1.000000 isMain=1 isKey=1 isVisible=1 delegate=0x7f95a542d850>>: 0.04865998029708862
Aug 15 19:05:50 Aarons-Retina-MacBook-Pro iTerm2[940]: Time to encode state for window <PseudoTerminal: 0x7f95a542d850 tabs=13 window=<iTermWindow: 0x7f95a70ab750 frame=NSRect: {{0, 4}, {1440, 873}} title=1. emacsclient alpha=1.000000 isMain=1 isKey=1 isVisible=1 delegate=0x7f95a542d850>>: 0.04382699728012085
Aug 15 19:06:16 Aarons-Retina-MacBook-Pro iTerm2[940]: Active space did change
Aug 15 19:06:17 Aarons-Retina-MacBook-Pro iTerm2[940]: Time to encode state for window <PseudoTerminal: 0x7f95a542d850 tabs=13 window=<iTermWindow: 0x7f95a70ab750 frame=NSRect: {{0, 4}, {1440, 873}} title=1. emacsclient alpha=1.000000 isMain=0 isKey=0 isVisible=1 delegate=0x7f95a542d850>>: 0.04863500595092773
Aug 15 19:06:44 Aarons-Retina-MacBook-Pro iTerm2[940]: Active space did change
Aug 15 19:07:14 Aarons-Retina-MacBook-Pro iTerm2[940]: Time to encode state for window <PseudoTerminal: 0x7f95a542d850 tabs=13 window=<iTermWindow: 0x7f95a70ab750 frame=NSRect: {{0, 4}, {1440, 873}} title=1. less alpha=1.000000 isMain=1 isKey=1 isVisible=1 delegate=0x7f95a542d850>>: 0.050711989402771

I believe the tab mentioned in the logs is the one that got moved (it is the only one currently running emacsclient).

I guess that's just because it was the active tab. Here's a screenshot of the broken tab bar (notice the numbering).

Nothing interesting there :(. Do you ever reorder tabs using the keyboard? Move tabs between windows?

No I don't. My tab life is pretty boring. I have one window with several tabs. I create new tabs until I have "enough", then I rarely create a new tab again. I then just switch between them with command-shift-[ and command-shift-] (actually three finger swipes via BetterTouchTool). My tab color is based on my current directory and I keep them somewhat organized from left to right by that, but I rarely re-order them (and I haven't done so recently).

Quick sanity check: toggle broadcasting of input on and off again from a session's right-click context menu. Does that cause them to reorder properly?

I'll try it next time this happens.

It just happened again and that didn't fix the problem.

I made a special build to help diagnose this issue. Please do this:

1. Install http://iterm2.com/adhocbuilds/iTerm2-3_0_20160907_212045-adhoc.zip
2. Use it normally until you notice the tab bar is out of order
3. Toggle debug logging on and immediately back off (no need to do anything while logging is on), and attach the log here.

Thanks!

Will do.

Here you go. Tab 8 moved between tabs 3 and 4. debuglog.txt

The last thing I see is a drag-drop of a tab. I can't see tabs out of order so I'm not quite sure what caused it, but one hint is that the protocol PSMTabBarControl implements (-draggedImage:beganAt:, and friends) is deprecated. I should change it to to use NSDraggingSource and see if that helps.

OK, I just saw a very strange behavior here. I was in tab 7, and I typed a command. Then I switched to tab 8 and typed a command. I think ran (in tab 8), an open command which opened a window from another application (Skim) on top of iTerm2. Then, on top of the Skim window, appeared the tab rectangle for tab 7! It was in its correct position. I then switched back to iTerm2 and tab 7 had moved (I think to around tab 3 or 4). I switched back to Skim and the tab was gone. I wish I had grabbed a screenshot of it.

Unfortunately, these steps don't reproduce the problem, so there must be more going on.

This was on Build 3.0.20160918-nightly.

Mentioned in issue #5348 (closed)

I've removed the use of deprecated delegate calls and added some logging. Please try tomorrow's nightly build or the next 3.1 beta when it comes out. I've also improved debug logging to include some retroactive information about tab dragging. If the issue occurs to you again (while using one of the aforementioned versions) please do this:

1. Toggle debug logging on and then off again
2. Attach /tmp/debuglog.txt to this issue.

Thanks!

I haven't seen this issue in a while. I don't know if it's because my workflow has changed in some significant way since (I was previously working on a LaTeX paper, which involved a lot of tab switching, but now I'm not). I will let you know if I see it again after the latest nightly.

Just saw this again on 3.1.20170825-nightly

debuglog.txt

The tab bar was in the order 1 3 5 2 4 6 7 8 9 10 11

I got a few useful tidbits from this:

1. Some of the new logging code wasn't running. I've fixed that.
2. It thought you drag-dropped tabs 3 and 5 into new windows. Somehow they didn't move to new windows.

I've added some more logging code that will appear in crash reports. I'll need to search the crash logs in a few days for sanityCheck to see if anything comes up.

changed milestone to %Next Beta

I also just noticed a difficult to consistently reproduce behavior that may be related. If I have one tab selected and click on another tab in a certain way, it thinks I am dragging the active tab and moves it to that location. I can't really tell what that "certain way" is. Sometimes it happens, usually it doesn't.

I don't think that is exactly what is happening here. The tabs seem to shift once I move to another application, and in the above situation I didn't click on the tab far (from what I remember). But maybe it's another symptom of the same underlying issue.

debuglog.txt (tab 7 moved to between tab 3 and 4). Build 3.1.20170829-nightly

It might not have been a soon enough nightly. I just noticed the most recent commit in the update text was about this. Interestingly, when I restarted from the update, tab 7 went back to its original correct location.

The Aug 30 nightly is the first one that has the changes, unfortunately. Keep trying!

mentioned in issue #6023 (closed)

The fix from #6023 (closed) has been cherry-picked to master. I think it ought to do the job but let me know if this happens in the nightly builds. It'll be in 3.1.1.

closed