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

[ion-elgreco]

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

1. Install brave/chrome (chromium-based) browser
2. Open up two tabs in separate windows.
3. Turn on fancyzones
4. 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

[enricogior]

Hi @ion-elgreco
I was able to reproduce it with 0.18.0, but I can't reproduce it with 0.18.1.
I tested Edge Chromium, Chrome and Brave and they all work as expected.
Is there anything that you changed in the FZ settings compared to the https://github.com/microsoft/PowerToys/issues/3504#issuecomment-632582485 ?

[ion-elgreco]

Hi @ion-elgreco
I was able to reproduce it with 0.18.0, but I can't reproduce it with 0.18.1.
I tested Edge Chromium, Chrome and Brave and they all work as expected.
Is there anything that you changed in the FZ settings compared to the #3504 (comment) ?

No, still the same settings. I also used Chrome and chromium version of edge. They all have the same issue.

On the old version of edge (before chromium, I don't have this issue).

[enricogior]

Can you verify in the PowerToys General Settings that you are running 0.18.1?

[ion-elgreco]

Can you verify in the PowerToys General Settings that you are running 0.18.1?

[enricogior]

Does it happen all the times?

[ion-elgreco]

Does it happen all the times?

Maybe 9 out of 10. If I move my tab real fast, imagine this: You quickly throw your tab onto your browser, then it works better.

[enricogior]

If you turn off the transparency for the dragged window does it make any difference?

[ion-elgreco]

If you turn off the transparency for the dragged window does it make any difference?

Not really, sometimes works, but also sometimes doesn't work. However it seems to occur less with transparency off.

Edit:
Turning transparency on again, and then a drag instantly freezes window when you tab it.

[enricogior]

OK thanks,

[ion-elgreco]

OK thanks,

Turning transparency off helps, but it still causes to occasionally crash a window (closing) when tabbing or freezes the window when tabbing.

[pokemav]

this problem is still present as of v.19.2. I move tabs alot and have been struggling with this problem since version .18 I think.
Hope this is a bug worth working on.

[ion-elgreco]

How is this still not fixed?

[enricogior]

@pokemav @ion-elgreco
can you still reproduce it with 0.21.1? https://github.com/microsoft/PowerToys/releases/tag/v0.21.1

[ion-elgreco]

@pokemav @ion-elgreco
can you still reproduce it with 0.21.1? https://github.com/microsoft/PowerToys/releases/tag/v0.21.1

Yeah, still the same issue.

[enricogior]

@ion-elgreco
can you post your current FZ settings? Thanks.

[ion-elgreco]

@ion-elgreco
can you post your current FZ settings? Thanks.

[enricogior]

@ion-elgreco
beside the Brave browser, you can repro it on Chrome/Edge Chromium as well, right?
Have you noticed if it's relevant the timing of the tab snapping?
Does the problem happen as soon as you start dragging the tab or when the tab is merging with the target window?

[ion-elgreco]

@ion-elgreco
beside the Brave browser, you can repro it on Chrome/Edge Chromium as well, right?
Have you noticed if it's relevant the timing of the tab snapping?
Does the problem happen as soon as you start dragging the tab or when the tab is merging with the target window?

I have recently switched to Edge chromium, so this behavior is on edge. I checked on chrome and brave but it's also the same since these are also chromium browsers.

The problem occurs the moment they are merging with the target.

My assumption is that merging with browser and fancy zone happens sometimes at exact same time causing this issue.

I don't know if this helps. but why not make fancyzones recognize a title bar and make this area not snappable so that a conflict can not occur between the two.

_Extra info, maybe which could help:_
Since a week or so I am using a different app called groupy. This allows me to snap multiple different programs within each other so it acts like tabs. Somehow groupy and fancyzones can work perfectly fine together without causing weird behaviour.

[enricogior]

@ion-elgreco
the target is currently in a zone, correct? So it should be a conflict between the browser relocating the tab and FZ trying to zone it at the same time.
The title bar is kind of unreliable since it's not a fixed property, it can change value. We need to figure out a consistent approach that will work on any browser (or other apps that have movable tabs).

[ion-elgreco]

@ion-elgreco
the target is currently in a zone, correct? So it should be a conflict between the browser relocating the tab and FZ trying to zone it at the same time.
The title bar is kind of unreliable since it's not a fixed property, it can change value. We need to figure out a consistent approach that will work on any browser (or other apps that have movable tabs).

Exactly, the target is in a zone. It's really related to how chromium browsers attach tabs, because with edge non-chromium it was fine.

[enricogior]

It also works just fine with Firefox, because dragging the tab doesn't activate FZ.

[enricogior]

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]

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

[ion-elgreco]

@enricogior wasn't it supposed to be fixed with 0.23? The issue still persists with 0.23.

[enricogior]

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

[enricogior]

Confirmed: this commit broke the fix https://github.com/microsoft/PowerToys/commit/3d36779e19d3f2470585c3789b3cd9d728f4e8ec#diff-ff7794bdc47c8ebd8c1cecabe2f532fc
Sorry about that.

[ion-elgreco]

Confirmed: this commit broke the fix 3d36779#diff-ff7794bdc47c8ebd8c1cecabe2f532fc
Sorry about that.

No problem, when can we expect to have the fix back as an update? It's very difficult to use powertoys at the moment when I cant snap a window back in its place :(.

[enricogior]

@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.

[ion-elgreco]

@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 :)

[stefansjfw]

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

[ion-elgreco]

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

Haha made me laugh 💯 Thanks for the work guys, much appreciated!

[enricogior]

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]

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

[ion-elgreco]

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

Amazing :) Thank you!

[ion-elgreco]

Thanks for the fix guys! 👍 🥇

[crutkas]

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