Windows don't stay in position

[noChamp]

Environment

Windows build number: 10.0.18362.476
PowerToys version: latest
PowerToy module for which you are reporting the bug (if applicable): Zones

Steps to reproduce

1. have a dual monitor pc
2. have 3 virtual desktops
3. on the second virtual desktop have 4 windows for each monitor
4. on the second virtual desktop, set a 'grid' layout for each monitor
5. switch to any other virtual desktop
6. return back to the second one

Expected behavior

the windows on the second monitor stay in position

Actual behavior

the windows on the second monitor are placed one over the other

[fredrikahs]

I have the same issue with a single (21:9) monitor using only two virtual desktops. The desktops have different FancyZone layouts. Switching between the virtual desktops changes the positions of some (?) windows. The windows on both virtual desktops change positions.

I recently updated from v0.11 where I believe this issue was not present.

[fredrikahs]

I just tried version 0.13 and 0.12 and neither works. Reinstalled 0.11 and the issue is gone.

[fredrikahs]

I did a git bisect to find the issue and it seems it arose in bzoz/PowerToys@50dae8a
Commenting out dllmain.cpp#269
case EVENT_OBJECT_UNCLOAKED:
fixes the issue, but I don't know what else that might be affected since I'm not involved in the project.

[enricogior]

Hi @noChamp @fredrikahs
thank you for reporting the issue and thank you for finding the commit that caused the problem.
We'll pick it up from here.
Thanks!

[crutkas]

adding to 20.02 unless it is a quick fix.

[bzoz]

EVENT_OBJECT_UNCLOAKED was added to detect terminal window creation. @fredrikahs could you provide a screenshot of all your FancyZones settings?

[fredrikahs]

It seems this is caused by using FancyZones in conjunction with https://github.com/Eun/MoveToDesktop. When I turn that off everything seems to run fine.
I totally forgot I had this running in the background. I guess I forgot since it feels like it should be native to Windows.

Anyway, not sure if the settings will help, but here they are.

[tkon99]

Same here, also when using MoveToDesktop.
Perhaps integrating MoveToDesktop into PowerToys is a good idea, seems like something that belongs in here.

Edit: related issue #16

[crutkas]

@tkon99, can’t, it is GPL and that conflicts with MIT license

[tkon99]

Sorry, I meant integrating the functionality, not the program itself. I imagine writing new code is faster in this case anyway.

…

On Thu, Jan 30, 2020, 20:54 Clint Rutkas ***@***.***> wrote: @tkon99 <https://github.com/tkon99>, can’t, it is GPL and that conflicts with MIT license — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1033?email_source=notifications&email_token=AATNG4C4XH64WNNOX27MS6TRAMV5TA5CNFSM4KB2JLTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKMJRLY#issuecomment-580425903>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AATNG4FFD434HMGT7DK23RLRAMV5TANCNFSM4KB2JLTA> .

[crutkas]

we have the idea (and a prototype) for 'move to new desktop' but i do like the idea of 'moving to an existing desktop' as well. that is basically #16

[noChamp]

hi @fredrikahs I don't have this extension installed and still the bug occurs

[fredrikahs]

@noChamp it might be unrelated, or maybe something else is interfering in a similar way? Does downgrading to v0.11 fix it for you?

[enricogior]

This may be the same as #1018

[enricogior]

As @fredrikahs pointed out, this commit 50dae8a breaks the desktop switch logic and generates random window snapping if appLastZone_moveWindows or virtualDesktopChange_moveWindows are on.

EVENT_OBJECT_UNCLOAKED and EVENT_OBJECT_SHOW events are generated when switching desktops, but they are also used in FZ to detect when a Store app is launched.
The two things are conflicting and breaking some basic FZ functionality.

[crutkas]

We know that all VD issues are caused by the same root bug. Tracking in #1236