[FancyZones]: workspace/virtual desktop <-> layout mapping

[manuelserradev]

Microsoft PowerToys version

0.37

Running as admin

• Yes

Area(s) with issue?

FancyZones

Steps to reproduce

1. Setup two or more workspaces
2. Open Fancy zone editor and use a different layout for each workspace

✔️ Expected Behavior

Fancy zones for each workspace are persisted and correctly mapped.

❌ Actual Behavior

Every Fancy zone layout change is applied to every workspace.

Other Software

System info
Edition	Windows 10 Pro
Version	Dev
Installed on	01-‎May-‎21
OS build	21370.1
Experience	Windows 10 Feature Experience Pack 321.9601.0.3

[manuelserradev]

PowerToysReport_2021-05-06-08-26-40.zip

[manuelserradev]

Maybe Windows vNext related, since rolling back to 0.33.1 or 0.35.0 do not solved the issue.

Also, removing temp data under %appdata%/Local/Microsoft/PowerToys/FancyZones do not solved the issue.

Update: not reproducible on Windows stable. Maybe some special label is required?

[crutkas]

when you say workspaces, you mean virtual desktops?

[manuelserradev]

Yes.

[tychedelia]

This is also an issue for me. Other closed issues in this repo suggest that the layout per virtual desktop should persist, but changing layout on one desktop currently is breaking all my others.

[manuelserradev]

From my understanding and investigation (with me being completely uncomfortable and ignorant with cpp) the issue is with the registry key not being open when CurrentVirtualDesktop is requested.

// VirtualDesktopUtils.cpp

if (RegQueryValueExW(key.get(), NonLocalizable::RegCurrentVirtualDesktop, 0, nullptr, reinterpret_cast<BYTE*>(&value), &size) == ERROR_SUCCESS)
{
    // this code never get executed
    *desktopId = value;
    return true;
}

Also experimenting with RegOpenKeyEx before requesting the value, fix the problem.

Problem is that is not very clear to me how to handle this kind of change, for example I can see the usage of wil::unique_hkey here and there.

The fix seems trivial: open before query. But looks like there is some magic to have the key always open (and thus this code is failing)?

[manuelserradev]

The missing regkey is Software\Microsoft\Windows\CurrentVersion\Explorer\SessionInfo\1\VirtualDesktops from sessionKeyPath.

Maybe a fallback to the canonical Software\Microsoft\Windows\CurrentVersion\Explorer\VirtualDesktops can be done? Maybe I can contribute that way.

[crutkas]

This is a valid scenario we need to address. @zadjii-msft anything else we need? @SeraphimaZ as fyi

[manuelserradev]

In the meantime I updated my local branch to use a different approach with reg key open/read (I think more RAII compliant???) by using wil::unique_hkey - the same approach used by the same code in the same scope.

Let me know if you want me to refine this branch and open or document a bit more.

Maybe this is a regression from Explorer.exe itself, but I'm now on build 21390.1 and can repro the issue.

System info	Value
Edition	Windows 10 Pro
}Version	Dev
Installed on	‎27-‎May-‎21
OS build	21390.1
Experience	Windows 10 Feature Experience Pack 321.13302.10.3

[dedavis6797]

Resolved.