Closed gileli121 closed 11 months ago
According to logs, when WindowTop first starts, it first lists all windows including the invisible windows. During this operation, it will trigger the logic that will cause the bug. After that, WindowTop detects that all of these invisible windows should be removed and untracked, and remove them. But at this point, it is too late and it already causes the invisible windows to be visible.
The fix is to avoid loading any invisible windows in the first place.
Released version v5.21.2 beta with this bugfix: https://github.com/WindowTop/WindowTop-App/releases/tag/v5.21.2
Fixed regression that in some case the app did not recover a window with PIP enabled after the app restarted.
Version v5.21.2-beta2 Released in https://github.com/WindowTop/WindowTop-App/releases/tag/v5.21.2
Released
A customer reported the following issue:![image](https://github.com/WindowTop/WindowTop-App/assets/17680514/faa35601-9c59-4445-bb97-f24a5cce1be5)
The issue was reproduced using explorer.exe. In the customer's case, he used the TIM.exe program. However, I was unable to find the program on the Internet.
But I was able to reproduce it using Windows Explorer (explorer.exe).
Steps to reproduce:
The issue will happen - WindowTop will pick some invisible windows that belong to explorer.exe and will apply the saved configuration that includes the always-on-top (it will set the window on top). The bug is that the logic is triggered on all explorer.exe windows - including the invisible windows. When the logic to apply the configuration is triggered on the invisible window of explorer.exe, it will then apply the always-on-top mode which then causes the invisible window to be visible.