Another possible way to deal with this issue is to only run hideTabBar:animate: when there's an actual change in the tab bar visibility or tab count.

@dmoagx

1. Does this resolve issue?
2. Do you guys need more help reviewing PRs?

@clayreimann
a) No idea, only thing I can say that it ignores the debugging work I already did and the pointers I have given in #3091 (comment)
b) I personally don't review or merge PRs that I did not agree to review, before they have been submitted

@dmoagx
a) totally fair, I asked because I typically see a large number of PRs that appear to be stalled waiting for reviewb
b) would you be willing to review a PR for #3091 that works from your insights there? (A PR other than this one)

@clayreimann
b) Yes

Woops, my bad, yes, it works correctly for me when moving a window to a monitor with a lower vertical resolution :)

Wow, sorry that this has been lingering here for so long. This was just a way to give proof of a fix and maybe give a more informed person, such as yourself, a vantage point to create a "proper" fix.

b) I personally don't review or merge PRs that I did not agree to review, before they have been submitted

This is a strange collaboration technique to me. It's been over a year this has been here without conflicts with master. This tiny PR fixes a very annoying bug and there's only been a discussion about how you don't want to review it because I didn't ask for permission to submit a PR? That's bureaucratically bonkers!

a) No idea, only thing I can say that it ignores the debugging work I already did and the pointers I have given in #3091 (comment)

I did not totally ignore your assessment in #3091. It was just the only part I found relevant was this:

• The run loop starts the next iteration
  • The animation timer is actually triggered and updates the main content area to the (now invalid) frame which it had when the animation was created

This PR addresses that by deferring hideTabBar:animate: when an update is triggered in frameDidChange:. This is needed because frameDidChange: isn't what determines tab visibility. Opening or closing a tab is what determines tab visibility.

With this fix, opening a second tab that triggers the animation, [self update:NO] is called for each frame of the animation (10 by my count), then frameDidChange: is triggered from unknown sources 3 times.

Without this fix, opening a second tab that triggers the animation, [self update:NO] is called for each frame of the animation (10 by my count), then frameDidChange: is triggered from unknown sources 41 times! I don't totally understand the cause here, but it seems like the animation timer is inadvertently restarting itself a couple of times.

I admit that this feels like a workaround by adding a guard to the tab animation. But, it's the fastest and least invasive way to get around a bug that can't be fixed without totally restarting the program. I am asking you to please review this for the sake of fixing a very annoying and old bug.

If this PR feels too hacky, here's a patch that accomplishes the same thing by debouncing the update: call from frameDidChange:

diff --git a/Frameworks/PSMTabBar/PSMTabBarControl.h b/Frameworks/PSMTabBar/PSMTabBarControl.h
index dee4ed8a..9e98feb9 100644
--- a/Frameworks/PSMTabBar/PSMTabBarControl.h
+++ b/Frameworks/PSMTabBar/PSMTabBarControl.h
@@ -116,2 +116,3 @@ enum {
        NSTimer                                 *_showHideAnimationTimer;
+       NSTimer                                 *_updateDebounceTimer;
 
diff --git a/Frameworks/PSMTabBar/PSMTabBarControl.m b/Frameworks/PSMTabBar/PSMTabBarControl.m
index 7fcf5840..9cfe4f4f 100644
--- a/Frameworks/PSMTabBar/PSMTabBarControl.m
+++ b/Frameworks/PSMTabBar/PSMTabBarControl.m
@@ -1693,3 +1693,15 @@
 
-       [self update:NO];
+       if ([[self window] inLiveResize]) {
+               [self update:NO];
+       } else {
+               // Debounce updates
+               if ([_updateDebounceTimer isValid]) {
+                       [_updateDebounceTimer invalidate];
+                       [_updateDebounceTimer release];
+               }
+
+               _updateDebounceTimer = [[NSTimer scheduledTimerWithTimeInterval:0.5 repeats:NO block:^(NSTimer * _Nonnull timer) {
+                       [self update:NO];
+               }] retain];
+       }

@dmoagx could you please seriously consider this pull request? The bug that the layout gets screwed up when a 3rd party app resizes the app is really annoying and clearly it's bothering more people. If this PR indeed fixes that bug then that would be such a relief to me and most likely a lot of other people who use this app.

From your earlier responses I interpret that you were somewhat annoyed or fed up with something? I'm not sure that I fully understand where it came from, but I'm guessing you wanted to protect your time and energy and you wanted other people to consider your time and energy too, is that right? I don't know if you still feel the same way, but if you do I wonder if there's a way both of us can get what we want. For example, is there anyone else you trust to be able to review this code and judge whether it's good enough to merge and release?

I don't know. A lot of what I'm saying is based on assumptions, because I don't know you of course and I can't see what your face is expressing while you're reading this. But I hope you're open to talk about this if you still feel some resistance towards reviewing and possibly merging this PR.

Is this really still not fixed in nightly builds? I'm still using the binary I built from this PR branch in July, waiting for the issue to close. This bug makes sequel pro completely unusable for me as I daily plug/unplug my mac to a couple of external monitors which makes some sequel pro windows permanently unusable.

@Evertt Even if I would merge this, there would be no change. Nightly builds are broken for months, so you'd have to compile it yourself to see the change - the same as it is right now.

Yup, my builder not getting triggered any more :( https://build.spdevlog.com is down...

Well, we've relied on (mostly) resigned project members for that infrastructure, so I don't want to blame anyone for this or have to constantly nag people who've decided they'd rather spend their valuable spare time on other efforts.
I think it's only natural that this happend and there is nothing to do about it at the moment.

For anyone interested, we're trying to get a fork of Sequel Pro going. This fix and others have been merged in, and there's a downloadable beta that's notarized for macOS for anyone who wants to try it!
We need all the help we can get, so if @tweekmonster or others are interested in helping out, will be happy to review any inbound PRs.

Sequel Pro is/was awesome. I think @dmoagx hit the nail on the head - we can't blame anyone for this or nag people who want to do other things. All we can do is move forward and try to make a great, free tool for everyone.

https://github.com/Sequel-Ace/Sequel-Ace