PowerToys: [FancyZones] Browser tab freezes when trying to snap it back with other tabs already zoned (chromium-browsers)

Environment

Windows build number: Microsoft Windows [Version 10.0.18363.836]
PowerToys version: v0.18.1
PowerToy module for which you are reporting the bug (if applicable): Fancyzones

Steps to reproduce

Install brave/chrome (chromium-based) browser
Open up two tabs in separate windows.
Turn on fancyzones
Drag one tab into the other, so that your browser window has two tabs. Try to do this a couple of times and you will see the tab sometime freezes and becomes unresponsive, or turns black and becomes unresponsive.

Expected behavior

Tab has to snap into the browser

Actual behavior

Tab is crashing and closes instantly when you snap it in. This doesn’t happen when fancyzones is off.

Screenshots

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 45 (21 by maintainers)

Most upvoted comments

The fix will be available in 0.23 (end of September).

enricogior on Sep 11, 2020

@ion-elgreco it was fixed, but I suspect we broke the fix in a subsequent commit.

enricogior on Sep 30, 2020

@ion-elgreco it will be released in a hotfix release (probably early next week).

enricogior on Oct 1, 2020

Fan fact: the first fix worked because two bugs were cancelling each other, then we made a commit that unintentionally fixed one of the two bugs exposing the second one… true story 😃

enricogior on Oct 1, 2020

I fixed it. I broke it ( sorry 😦 ). I fixed it again 😃 I hope it will get to @ion-elgreco this time 😃

stefansjfw on Oct 1, 2020

Fixed in https://github.com/microsoft/PowerToys/releases/tag/v0.23.2

crutkas on Oct 9, 2020

@ion-elgreco if we release an hotfix for 0.23.0, this will be included. Otherwise if we don’t release an hotfix, and if it’s acceptable for you to installed an unsigned build, I can provide a private build with the fix.

In case there isn’t a hotfix, I am completely fine with an unsigned build 😃

ion-elgreco on Sep 30, 2020

@ion-elgreco if we release an hotfix for 0.23.0, this will be included. Otherwise if we don’t release an hotfix, and if it’s acceptable for you to installed an unsigned build, I can provide a private build with the fix.

enricogior on Sep 30, 2020

Note for dev. Repro steps:

unselect
zone a Chrome/Edge Chromium window to a zone
open another Chrome window away from the zone, create a new tab and drag the tab to the Chrome window that is zoned

Result: the target Chrome window is inside an active zone, therefore, when the tab gets merged by Chrome, FZ receives EVENT_SYSTEM_MOVESIZEEND and invokes WindowMoveHandlerPrivate::MoveSizeEnd that tries to zone the tab, this generates a conflict with Chrome and most of the time causes the tab to freeze.

Possible fix: when moving a tab, initially it has windowInfo.noVisibleOwner and windowInfo.standardWindow both set to true (see IsCandidateForZoning). Then, when the tab is merged with an exiting Chrome window, WindowMoveHandlerPrivate::MoveSizeEnd is invoked and at this point both windowInfo.noVisibleOwner and windowInfo.standardWindow are false. To fix this issue, we should consider comparing the windowInfo.noVisibleOwner and windowInfo.standardWindow values at the end with the value at the start of the dragging and if they changed, we should abort WindowMoveHandlerPrivate::MoveSizeEnd. It is important to check against the initial values, because it’s legit to zones windows that had windowInfo.noVisibleOwner and windowInfo.standardWindow set to false when the dragging starts.

enricogior on Sep 10, 2020