Select applications are not moving to their last known zone when creating new windows.

[francoiswnel]

Environment

Windows build number: Microsoft Windows [Version 10.0.19041.330]
PowerToys version: 0.19.0
PowerToy module for which you are reporting the bug (if applicable): FancyZones

Steps to reproduce

Open a new Explorer window with Win+E, or launch a new instance of Firefox, or open a new Firefox window from within Firefox with Ctrl+N.

Expected behavior

The newly created window should move and snap to its last known zone.

Actual behavior

The newly created window does not move or snap to any zones.

Additional Info

Not all applications are affected. The PowerToys settings window still snaps to the last known zone, for example. So does Steam, Device Manager, etc. I can only confirm it with Explorer and Firefox so far. This behaviour started after I upgraded to both Windows 10 2004 and PowerToys 0.19.0 in the same evening, so it could be attributed to either. I can confirm that the expected behaviour is still valid on Windows 10 1909 with PowerToys 0.18.0.

[enricogior]

@francoiswnel
this is happening for the second instance of the same process. It's currently by design, since we can't detect if the second window of the same process is an actual window or a dialog/tool window.

[francoiswnel]

@enricogior Ah okay. And this design change was implemented between 0.18.0 and 0.19.0? Because my expected behaviour is definitely still the case on 0.18.0 since I'm running that in another environment.

I'm fairly certain that the very first Firefox window does not move to its zone though, but perhaps there is already a background process running upon startup.

To add my two cents, I think the previous behaviour is still the better compromise and more consistent with expectations. Yes, it's not ideal for a dialog to snap to the top right of the zone, but at least it's still confined to the same zone, i.e. the same expected workspace, and not just left to decide where it wants to appear on its own. Maybe windows that cannot be resized (like dialogs) should be centred within their parent zone. Thoughts?

[enricogior]

@francoiswnel

I'm fairly certain that the very first Firefox window does not move to its zone though

I cannot reproduce the problem, for me the first FF window is zoned as expected.

I think the previous behaviour is still the better compromise and more consistent with expectations

Unfortunately the previous behavior was causing bugs like these:
#1931
#4601
#1192

[francoiswnel]

@enricogior Thanks for the info. Okay, happy to close this issue then.

[enricogior]

Closing this has won't fix for now, but we have other issues tracking how to handle child windows, so it might be revisited in the future.
Adding a reference to #1445