Snapped windows not restored when Using titlebar move

[RamonUnch]

I've set Title bar's Left mouse button action to Move window and it works like I was expecting now. Thanks!

However, there is another issue: If I simply drag a window by its title bar to the edge of the screen and aero snap it (the native Windows feature) to take up the left half of the screen for example, dragging the window back by its title bar doesn't return the window to its original dimensions. So a similar issue. If instead of dragging the window back by its title bar you use Alt + drag, the window shape is restored after a Windows aero snap. Can this happen for when dragging back via the title bar also?

Oddly, the above does actually work sometimes, but others times not. Interestingly, the behaviour is different even between two Firefox windows (one launched as a new window from the other). There is a bug here, but I'm not sure what. It seems to work on all other windows, but one Firefox window doesn't restore itself 100% of the time when dragging back via the title bar.

Originally posted by @redactedscribe in https://github.com/RamonUnch/AltSnap/issues/7#issuecomment-1235931499

[Ichisich]

Tried it with Firefox and couldn't replicate it.

[RamonUnch]

First when you set the Title bar's Left mouse button action to Move window , there should be no more native window snapping of any kind because AltSnap should bein charge to move/snap the window when you click the titlebar.

Then, my educated guess is that some programs have a fake titlebar that cannot be detected by AltSnap in some places so it can happen that when you click on the titlebar of a snapped window, depending on where you click precisely AltSnap cannot see it is a titlebar and the window is moved natively instead and not properly restored.

The solution would be to introduce a titlebar action that just restores the window and then lets the click grab the titlebar normally.

[Ichisich]

First when you set the Title bar's Left mouse button action to Move window , there should be no more native window snapping of any kind because AltSnap should bein charge to move/snap the window when you click the titlebar.

I initiated the native snap with both the modkey and with win+arrow. In both cases, the window gets restored with a AltSnap title bar grab.

Then, my educated guess is that some programs have a fake titlebar that cannot be detected by AltSnap in some places so it can happen that when you click on the titlebar of a snapped window, depending on where you click precisely AltSnap cannot see it is a titlebar and the window is moved natively instead and not properly restored.

True, but @redactedscribe already specified Firefox which gets recognized properly.

The solution would be to introduce a titlebar action that just restores the window and then lets the click grab the titlebar normally.

Is there even a case in which AltSnap already recognizes the title bar as a title bar, but doesn't restore the window correctly?

[RamonUnch]

Is there even a case in which AltSnap already recognizes the title bar as a title bar, but doesn't restore the window correctly?

I cannot see such a case, maybe there is, but I would need to be able to reproduce it. Of course if you do not use Smart Aero snapping or you enabled the never restore altsnapped windows, then it can happen but it is part of the design.

[Ichisich]

My uneducated guess, in regard to @redactedscribe issue, is that the window was already snapped (windows edge / screen edge / zone / etc.) beforehand, so resizes after that get discarded, or he has a Firefox add-on installed which can interfere somehow.

But it would be helpful to know how he even natively snapped:

If I simply drag a window by its title bar to the edge of the screen and aero snap it (the native Windows feature) to take up the left half of the screen for example, dragging the window back by its title bar doesn't return the window to its original dimensions.

By the sound of it, AltSnap isn't even involved.

[redactedscribe]

First when you set the Title bar's Left mouse button action to Move window , there should be no more native window snapping of any kind because AltSnap should bein charge to move/snap the window when you click the titlebar.

I've only recently started using Mouse > Title bar > LMB > Move window so I didn't notice that AltDrag now meant to handle the "aero" snapping. Only some windows like Windows Terminal still uses the native snapping, but that is expected because of its special title bar I think. The title bar Move window function seems seems to work fine on most windows, but for my Firefox window, the parent window will snap to a half/corner for example, but dragging it via its title bar back won't restore its shape. A child new window of Firefox however will behave as expected.

Strangely, I just tested the parent window again, and now it does restore its dimensions after dragging it back via its title bar. I think it has something to do with mixing Alt + dragging to "aero" snap, and dragging the title bar to "aero" snap. AltDrag seems to get confused because sometimes the bug is present and sometimes not. ...and now the bug is back again... Here's a video, even Window's native aero snapping starts to work at random...

https://user-images.githubusercontent.com/25013746/188316238-7ffd0e8c-9a2f-4aca-b3fa-1e226f5bf941.mp4

I've tried with a blank Nightly install but I can't get the bug to happen with that, so perhaps Firefox stable (104.0.1) is the issue, or an installed extension, but I'm leaning towards it being an AltDrag issue, or a conflicting program.

Not sure what else to say. Here's my config:

[General]
AutoFocus=1
Aero=1
SmartAero=1
StickyResize=1
MMMaximize=0
AeroHoffset=50
AeroVoffset=50
InactiveScroll=0
AutoSnap=0
MDI=1
ResizeCenter=3
CenterFraction=32
MoveTrans=245
Language=en-US

[Input]
UniKeyHoldMenu=0
LMB=Move
MMB=Lower
RMB=Resize
MB4=Borderless
MB5=AlwaysOnTop
Scroll=Transparency
HScroll=Nothing
LMBB=Nothing
MMBB=StackList
RMBB=Nothing
MB4B=Nothing
MB5B=Nothing
ScrollB=Nothing
HScrollB=Nothing
LMBT=Move
MMBT=Nothing
RMBT=Nothing
MB4T=Nothing
MB5T=Nothing
ScrollT=Roll
HScrollT=Nothing
LMBTB=Nothing
MMBTB=Nothing
RMBTB=Nothing
MB4TB=Nothing
MB5TB=Nothing
ScrollTB=Nothing
HScrollTB=Nothing
GrabWithAlt=Nothing
GrabWithAltB=Nothing
MoveUp=Nothing
MoveUpT=Nothing
ResizeUp=Nothing
ResizeUpT=Nothing
MoveUpB=Nothing
ResizeUpB=Nothing
TTBActions=1
ScrollLockState=0
HScrollKey=10
Hotkeys=5B
ModKey=
Killkeys=09 2E
Shiftkeys=A0
Hotclicks=
XXButtons=
KeyCombo=0
LongClickMove=0
FrameColor=80 00 80
PinColor=FF FF 00 54
AggressivePause=0
AggressiveKill=0
NPStacked=0

[Blacklist]
Processes=Virtual PC.exe,StartMenuExperienceHost.exe,SearchApp.exe,osk.exe
Windows=Program Manager|Progman,*|MultitaskingViewFrame,Volume Control|Tray Volume,Volume Control|Windows.UI.Core.CoreWindow,*|TaskSwitcherWnd,*|TaskSwitcherOverlayWnd,|WorkerW,|Shell_TrayWnd,|BaseBar,|#32768,*|XamlExplorerHostIslandWindow,*|TSSHELLWND,|MozillaDropShadowWindowClass,*|RAIL_WINDOW,Start|Windows.UI.Core.CoreWindow
Scroll=
MDIs=*|PPTFrameClass,*|MMCMainFrame,*|classFoxitReader
Pause=taskmgr.exe,explorer.exe,dwm.exe,Virtual PC.exe,AltSnap.exe
Snaplist=*|BaseWindow_RootWnd,*|SkinWnd,*|ChatSkinWnd,*|SpotifyMainWindow,*|USurface_*,*|Winamp*,*|M4W_MainWindow,*|SunAwtDialog
MMBLower=*|CASCADIA_HOSTING_WINDOW_CLASS,*|MozillaDialogClass
AResize=*|SunAwtDialog
SSizeMove=*|iTunes
NCHittest=*|ApplicationFrameWindow
Bottommost=*|RainmeterMeterWindow

[Advanced]
TopmostIndicator=0
NumberMenuItems=0
AutoRemaximize=1
SnapThreshold=10
AeroThreshold=32
SnapGap=0
AeroMaxSpeed=100
AeroSpeedTau=64
MultipleInstances=0
AlwaysElevate=0
ResizeAll=1
FullScreen=0
BLMaximized=0
AeroTopMaximizes=0
UseCursor=1
MinAlpha=32
AlphaDelta=64
AlphaDeltaShift=1
ZoomFrac=16
ZoomFracShift=64
ShiftSnaps=1
PiercingClick=0
DragSendsAltCtrl=0
BLCapButtons=3
BLUpperBorder=3
ACMenuItems=-1

[Performance]
FullWin=2
TransWinOpacity=0
PinRate=32
RezTimer=1
RefreshRate=1
MoveRate=2
ResizeRate=6
[Zones]
UseZones=0
GridNx=3
GridNy=2
InterZone=32
FancyZone=0
Zone0=
Zone1=
Zone2=
Zone3=
Zone4=
Zone5=

[KBShortcuts]
UsePtWindow=0
Kill=0

The only thing added to Blacklist.Windows is ,Start|Windows.UI.Core.CoreWindow. This was due to a past bug I reported long ago, but maybe now it isn't needed any more?

[redactedscribe]

Here is a second video showing that my Firefox unsnaps and restores correctly the first time, but on second attempt immediately after that, it doesn't. The purple Firefox is Nightly and it has no issue regardless if it is "aero" snapped via Winkey-dragging or via its title bar:

https://user-images.githubusercontent.com/25013746/188317822-59622387-ec04-4790-b95d-cec5d2109fde.mp4

Just to state it clearly, and possibly again, it appears it's certain that my stable Firefox never has issues restoring its dimensions if Winkey-dragging it back away from the snapped location, only dragging via the title bar is the problem.

[Ichisich]

Is this an addon?

And is the marked region still dedicated as title bar? You can test it with the windows identifier in the blacklist tab. WM_NCHITTEST=2 would be the proper value.

[RamonUnch]

From the video, I kind of understand. This is what I expected. There was a problem with many windows about title-bar detection in older releases: If you clicked in the third-left side of the minimize button then the window would pretend it is the titlebar when it is actually not. So AltSnap would behave badly and grab the window instead of minimizing the program. In the end I ended up using another algorithm based on a DWM function combined with the old one:

For a click to be considered by AltSnap to be inside the titlebar you need: 1) WM_NCHITTEST=2 the windows says 2) the cursor needs to be outside of the reported caption button boundary ie: DWMWA_CAPTION_BUTTON_BOUNDS

So what happens in your case is that you are always clicking very close to the caption button and often the reported caption button boudary are more generous than the reality, so if you get a bit too close from the minimize button, the window will not restore properly.

This is unfortunate but it seems that since Windows 8 it is impossible to get pixel perfect position for the caption buttons, because the function that reports dimensions are legacy code that are not releated to the actual display.

Of course plugins inside firefox can alter the behaviour even more.

Have a try with notepad's window and try the identify window option while clicking very close to the minimize button, you will see In DWM button=Yes at some point when you did not click the minimize button. You will also see WM_NCHITTEST=2/2 when you click on the very left side of the minimize button. It should be 8/8 inside a minimize button.

[redactedscribe]

Is this an addon?

It is, but it doesn't take up any additional space because when it is removed, Firefox's other icons on the left just move closer to the Minimise button. That gap is the default space given to drag the title bar when the tab bar is full.

So what happens in your case is that you are always clicking very close to the caption button and often the reported caption button boudary are more generous than the reality, so if you get a bit too close from the minimize button, the window will not restore properly.

You are right. If I grab the title bar just a few pixels to the left of the Minimise button and attempt to "aero" snap, it will always be a native Windows aero snap and not handled by Alt Drag.

A workaround seems to be to use title bar space provided on the very left of the title bar: using this never results in a native snap or a failed restoring of the window dimensions. Ideally something could be done so that the right side of the title bar always works, but I guess I'll just have to retrain my muscle memory to reach for the far left from now on, or alternatively, permanently sacrifice some horizontal space and enable Firefox's normal (full width) title bar.

Have a try with notepad's window and try the identify window option while clicking very close to the minimize button, you will see In DWM button=Yes at some point when you did not click the minimize button.

Notepad:

For Firefox when it's snapped to one side and with a full tab bar, there doesn't seem to be any available space on the right side of the title bar that returns "No" (or if there is, it's very small). However the left side always gives you as much space as is actually visible.

So nothing can be done and this issue should be closed?

[redactedscribe]

So nothing can be done and this issue should be closed?

One idea is that if we could blacklist some windows from using AltDrag's implementation of "aero" snapping and instead let them rely upon Windows' native method, then the issue would go away. For whatever reason, natively snapping Firefox to the left of the screen for example and then dragging it away using the right side of its title bar is no problem for Windows: Firefox's dimensions are restored (which Alt Drag apparently can't do because that area of the title bar is considered as DWM Buttons "Yes"). This of course would sacrifice using AltDrag's snapping zones etc.

[RamonUnch]

You can always put firefox inside the titlebar blacklist and AltSnap will not move it. however you will have the same problem than before if you snapped via Altsnap and try to restore with normal drag.

There is no possible way to access to the native snapping functions, it is undocumented and unavailable and reserved for the Window manager. This is why AltSnap Has to re-invent the wheel, otherwise I would never have spend so much time writing all of this code.

. For whatever reason, natively snapping Firefox to the left of the screen for example and then dragging it away using the right side of its title bar is no problem for Windows: Firefox's dimensions are restored (which Alt Drag apparently can't do because that area of the title bar is considered as DWM Buttons "Yes"). This of course would sacrifice using AltDrag's snapping zones etc.

The reason is that if it was snapped natively, then AltSnap can restore it, and also the native movement can restore it. So as soon as the window was snapped natively, restoring will be flawless whatever happens.

With the latest test build that you have I am working on a spetial Restore action that will restore the window if it was snapped by AltSnap and then let the click go through for native movement.

So if you set LMBT=Restore in the .ini file you should have something similar to the old behaviour. However if you AltSnap a window and then restore via the titlebar clicking on the "bad" area you will still have trouble.

There are still even more things to do: 1) I could add a list of window for which the HITTEST should be trusted and no double check with DWM buttons will be performed I would prefer to do this only if necessary though. 2) You could try using the BLCapButtons=0 option. In this case, even clicking on the caption button will let you move the window. However there will be no more way to close a window with the close button.

[redactedscribe]

You can always put firefox inside the titlebar blacklist and AltSnap will not move it. however you will have the same problem than before if you snapped via Altsnap and try to restore with normal drag.

True, but that would sacrifice all other AltDrag functions on the window.

I could add a list of window for which the HITTEST should be trusted and no double check with DWM buttons will be performed I would prefer to do this only if necessary though.

I guess my idea of a blacklist just for the title bar would be too much of a niche edge case to be worth implementing.

You could try using the BLCapButtons=0 option.

I will have to try it.

[RamonUnch]

True, but that would sacrifice all other AltDrag functions on the window.

No there is already a titlebar blacklist that only involves titlebar actions, you have:

MMBLower=*|CASCADIA_HOSTING_WINDOW_CLASS,*|MozillaDialogClass
; List of windows for which the Titlebar action should not be performed.
; default is MS-WindowTerminal and some popup windows of Firefox.

You can still Alt+Drag those window but you just cannot perform titlebar actions. But it is still not perfect of course.

[RamonUnch]

Note that there is also the Restore action in the latest build. To use it set LMBT=Restore in the .ini file and it will just restore the window in case it was AltSnapped when you left click the titlebar. It should be similar to the old pre-1.50 behavior.

I am not sure it is really relevant as the LMBT=Move option is more logical, but in case it is the good solution for you I can keep it for the next release. Otherwise I will not include it because it is a bit messy. Or maybe I can keep it as a ini-only option.

[redactedscribe]

• With LMBT=Restore, AltSnapping a window (not using the title bar) to an edge and then dragging the window back away from it using the title back does not restore the window to its original dimensions (problem).
• When LMBT=Restore is in use, dragging a window via its title bar to an edge uses the Windows Aero Snap feature instead so dragging it back via its title bar does restore its dimensions (expected).
• With LMBT=Move, dragging a window away from the screen's edge always succeeds via the title bar (expected).

Note that there is also the Restore action in the latest build.

I'm using 1.56.

it will just restore the window in case it was AltSnapped when you left click the titlebar

I was hoping that LMBT=Restore would allow any windows snapped via alt-snapping to be dragged back by the title bar and have the dimensions restored, but it does not (see the first bullet point above). I can't tell what LMBT=Restore is doing, apparently the same as LMBT=Nothing?

[RamonUnch]

I was hoping that LMBT=Restore would allow any windows snapped via alt-snapping to be dragged back by the title bar and have the dimensions restored, but it does not (see the first bullet point above). I can't tell what LMBT=Restore is doing, apparently the same as LMBT=Nothing?

LMB restore is only available in the latest test build, sorry for the mistake.

AltSnap1.57test18_x64.zip

This is still far from perfect however if a window was AltSnapped and you try to restore with a normal click on the bad small area close to the caption, then the window will not be restored properly.

[redactedscribe]

Even though the title bar won't use AltSnap's "aero"-snapping with "Restore" set, I'm fine with it using Windows' native aero-snapping, and if I want AltSnap's snapping, then I'll use AltSnap hotkey.

"Restore" works nicely with your linked build, even if there's that small bad clickable area.

Thanks.