Tabs being inadvertently dragged

This is not a new issue, but I'm hoping the problem can be fixed at its root cause, instead of treating the symptoms by e.g., disabling features (see Issue #4848). (I still want to be able to move tabs, but on my terms, not theirs ;-) ) I'm on a beta build, but it's happened for as long as I can remember, and seems to be getting worse (as sammgc noted maybe OSX has made it worse over time). Also, I've tried the Advanced setting that sets a threshold for moving tabs; that doesn't really help (at minimum, it glitches and acts as if it'd like to move the tab). So, here are more details that I hope are helpful:

The first symptom is that the cursor is in the "cartoon fist" shape, which indicates it's in "drag" mode. The second symptom is that at that point, the tab can be dragged away from its current place and make a new window (or merge into the tab bar of another window). (It behaves as if the mouse up event was not getting to the tab for a while, until after the mouse had moved a ways away.)

To get it to happen, I can create a couple of windows with, say, three to five tabs. Then, start clicking on the various tabs, selecting them. Sometimes the drag cursor will appear, and if I move the mouse some more, it might tear the tab off. This is most likely to happen when I click on a not recently used one.

The third symptom is that sometimes the tab+window will be dragged after the fact, when dealing with multiple windows. For example, just now I hit Cmd+n to create a new window, and dragged that from one monitor to the other... and one of the tabs and windows materialized beneath it!

Right now I have two windows going, with about five tabs in each. And I'm clicking back and forth from a random tab on the first window to a random tab on the second one (in each case, just selecting the target tab, making its pane active/have focus). And pretty soon I have tabs moving from one window to the other, and showing up as "lower panes" of a split pane, etc. This is with a newly restarted iTerm2. I catted a couple of 800k files in a few of them, just to give it some data in its buffers.

(Did it a couple more times, including with debug log etc., below.)

Thanks for your consideration.

Thanks for filing an issue! Please answer the questions below so I can help you.

• iTerm2 version: Build 3.1.beta.9
• OS version: 10.12.6
• Attach [com.googlecode.iterm2.plist]com.googlecode.iterm2.plist here (drag-drop from finder into this window) (/uploads/c5440aff01a8b70339c8b0cc8e336e4b/com.googlecode.iterm2.plist)
• Attach a debug log, if possible. Instructions at https://iterm2.com/debuglog debuglog.txt
• Are you reporting a performance issue or a hang? Please attach a sample. Instructions at https://gitlab.com/gnachman/iterm2/wikis/HowToSample
• Are you reporting a crash? Please attach the crash log. Instructions at https://gitlab.com/gnachman/iterm2/wikis/crash-logs

Detailed steps to reproduce the problem:

1. start iTerm2
2. in the window, resize it to be short and wide (the better to display tabs)
3. make a bunch of tabs (like 5)
4. make another window, like the first one
5. start clicking back and forth randomly at tabs, selecting them
6. look for tabs/panes magically moving back and forth and/or to new windows
7. You don't even have to rush! You can move the mouse real leisurely-like and still make it happen.

What happened: Tabs/panes moved around -- see screen shot (they were all like one, two, three, four at the beginning)

What should have happened: Tabs stay where they are

mentioned in issue #4848

changed the description

Thank you for the well written report. I've been trying to track this down for a long time. Some interesting things from the log:

1504807385.427249 [CrashLogMessage]: 1504807385.427225 PSMTabBarControl.m:1323 (-[PSMTabBarControl mouseDragged:]): Start dragging with mouse down event NSEvent: type=LMouseDown loc=(283.629,426.375) time=1482480.8 flags=0 win=0x7fbdc053f6c0 winNum=43718 ctxt=0x0 evNum=5494 click=1 buttonNumber=0 pressure=1 deviceID:0x0 subtype=0 in window 0x7fbdc053f6c0 with frame {{-1121, 22}, {865, 466}}
1504807385.431978 [CrashLogMessage]: 1504807385.431954 PSMTabDragAssistant.m:590 (-[PSMTabDragAssistant draggingBeganAt:]): Drag of 0x7fbdc05491f0 began with current event NSEvent: type=LMouseDragged loc=(228.074,525.93) time=1482481.0 flags=0 win=0x7fbdc053f6c0 winNum=43718 ctxt=0x0 evNum=5494 click=1 buttonNumber=0 pressure=1 deltaX=-9.000000 deltaY=-17.000000 deviceID:0x0 subtype=0 in window with frame {{-1121, 22}, {865, 466}} from
```

This makes it look like the mouse moved from (283,426) to (228, 525) in 0.2 seconds, which is more than enough distance to signal a drag. As this was the last drag in the log (about a minute before you started logging) I think it's safe to say that was not your intent.

Perhaps it's not right to assume that drags begin with a mouse down followed by a mouse drag. Somehow the mouse down location is wrong.

Please try this build and see if you can reproduce the issue with it:

http://iterm2.com/adhocbuilds/iTerm2-3_1_20170912_222342-adhoc.zip

I believe #5055 (closed) is also related to this.

Hi George. So, I've fired up your test build and it seems better. Yay!

Question, should I continue using this or use the beta (10?) that dropped yesterday?

Thanks!

-Tom

and, yes, agree that 5055 seems like the same problem.

3.1 is going to become a stable release but I'll include this patch in the first bugfix release that follows it so it has some time in beta.

changed milestone to %Next Beta

Note to self: cherry-pick 6cd36859 to master for 3.1.1

mentioned in issue #5055 (closed)

closed