Describe the bug
I'm using an app with <key>LSUIPresentationMode</key><integer>3</integer> setting in info.plist which means on launch this app hides the system menu bar.
I'm able to manually increase the size of the app's window to cover the full screen, including the area where the menu bar once was.
However, your Maximize window action still behaves as though the system menu bar is still there.
By luck I've discovered that your other action Restore last saved window layout can restore the window's size to the full physical screen, including the top non-existing system menu bar, so from this I know it's possible for BTT to do it correctly
unfortunately that's a limitation in how macOS reports the visible frame. For such LSUIPresentationMode 3 apps, it will still report the menubar as available. (The restore action ignores all of this and just restores the last position, but this only works if we know that a window has had the old position, and it was valid. Otherwise it can lead to issues)
You can use the custom move/resize action and uncheck the "Take Dock & Menubar Into Account" option on the bottom. Or if you want to maximize by dragging, you can create a custom snap area for the specific app.
Thanks! That's exactly what I need as it doesn't introduce any delays unlike the restore functionality!
There still seems to be one OS-level bug (since it affects manual window resizing as well): manual resizing or your custom resizing action only works after I use ⌥↹, before that the invisible system menu bar still behaves as though it's there (so I guess it's just not "cleanly" removed on app's launch)
Do you know of any trick that would fix it?
Maybe (just guessing) there is some way to launch an app "hidden", then immediately make it "visible" (but it's too fast to notice) then the window will appear with a properly cleaned up system menu bar.
Or is there a way to add custom action that would do that before the actual resizing, but only on first launch?
I couldn't find any such actions (window's minimize button is disabled for this app due to LSUIPresentationMode 3), tried to simulate ⌥↹ via this action sequence, but this doesn't seem to have any effect (even with 1s timeout; also tried with execute action sequence after timeout; and anyway this would fire up on each key press, while I only need to fix the app launch bug)
Out of curiosity, which ones? As far as I see from testing various apps, even when they visibly "try" to push a window above the top menu bar, it simply resets position
For example, with the ⌥↹ bug the only thing I see is just the bottom part of the window "jumping up" revealing the background (though the jump height is like 20% of the screen, much higher than the size of the system menu bar), so it's not a big deal is the new position is "invalid"?
Unfortunately a lot of the logic in BTT and macOS depend on that the requested window size matches the resulting one. Especially on multi monitor systems or when the "display use separate spaces" option is active, it causes wrong behavior for various BTT actions if that's not the case.
Also while macOS will usually not allow to resize windows "out of bounds", this is not consistent in all situations.
I just checked whether I can somehow programmatically force the Menubar to really hide, but couldn't find a way yet. I'll have another look next week as this would be a nice feature anyways and probably workaround the bug you see.
By the way, would you also look into adding the same option into Window snapping? I forgot that I used BTT for that, and it would be awesome if I could also use that to fully maximize a window when there is no system menu bar (it's ok if it's hidden behind some flag and warnings that multi-monitor and spaces will fail, I just never found any usefulness for spaces and mostly use this without an extra monitor)
Thank you!
P.S.
Curious, are you able to at least detect that the Menubar is invisible?
