border_z_order bugs

[Louis047]

Some of the bugs that I found out when testing this feature while configuring my windows rice

AboveWindow

AboveWindow.mp4

BelowWindow

BelowWindow.mp4

The above odd behavior is noted on both in the following cases:

• Nested floating window
• Two (or more) overlapping floating windows

Not really sure what's causing this border behavior but worth looking into it. This issue is similar to #37 but documented for both AboveWindow and BelowWindow showcasing different behavior in each. Note that this behavior is not limited to a single app, it happens in all applications with the above cases.

Tested in Windows 11 24H2 Build 26100.7462

[Louis047]

Update: For BelowWindow, the said behavior doesn't happen with rendering_backend set to Legacy but the user loses shadow and other configuration except for the border_width and border colors. Stays the same for AboveWindow

[Louis047]

Another update: Found an another issue where the border width changes in zen but other apps follow it normally

[lukeyou05]

I can reproduce the buggy z-order with ShareX when using BelowWindow, but I can't reproduce the lingering border when using AboveWindow on either of my machines, one of which runs Windows 11 23H2 and the other 25H2. Maybe it's something in the config; can you send your config.yaml over? I have an inkling your issue with Zen might also be from there.

[Louis047]

@lukeyou05 Sure, I have a repository to maintain my dotfiles. Here's the link to it

https://github.com/Louis047/Windows-Dots/blob/main/Tacky-Borders/config.yaml

And about the zen border issue, it doesnt' seem to be the case anymore after a system restart as the border draws normally now. not sure what went wrong before.

[lukeyou05]

Oh I think the lingering border issue only happens when using GlazeWM. Can you try without it just to verify? Regardless, I'll look into it and see if I can find a fix.

Note that this behavior is not limited to a single app, it happens in all applications with the above cases.

Do you mean both the lingering border and buggy z-order happen with all apps? Or just the buggy z-order? I can only reproduce the lingering border with ShareX so far.

[Louis047]

Oh I think the lingering border issue only happens when using GlazeWM. Can you try without it just to verify? Regardless, I'll look into it and see if I can find a fix.

Yes you were right about it. I just tested it without glazewm and it works normally without lingering. I'm currently testing it in komorebi if its the same case in that too, it is by default packaged with your border app so I don't think it would cause an issue but better to verify it

Do you mean both the lingering border and buggy z-order happen with all apps? Or just the buggy z-order? I can only reproduce the lingering border with ShareX so far.

As for this, it happens with every apps that has nested window open. Doesn't happen when there's only a single window (given that it happens in glazewm only as per the above answer)

Update: For the second, just found that the lingering happens with BelowWindow and not AboveWindow as I have observed that the nested window bug doesn't persist for it.

So safe to say that without GlazeWM open and border_z_order set to AboveWindow, it works normally

[lukeyou05]

It looks like GlazeWM sends another "create window" event after the ShareX window is closed, causing a new border to be created that stays there and never gets destroyed. This might be worth bringing up in the GlazeWM repo, but I've just gone ahead and added a thread that that periodically polls window validity (there are other things I wanted to poll anyways).

Does this artifact fix the lingering border for you? I'll work on the buggy z-order with BelowWindow later.
https://github.com/lukeyou05/tacky-borders/actions/runs/21124238098

[Louis047]

Hey, I have tested your artifact with my current config (border_z_order: AboveWindow) and the below video shows the border behavior of the build:

AboveWindow.-.New.Build.mp4

I shall confirm that this fixed the lingering border bug the occurs with AboveWindow but still the same border_z_bug bug case for BelowWindow. Hope you address it too.

Update: I just noticed in the video after recording and posting that there is a brief black color window appearance and the below video showcases new cases with it.

AboveWindow.-.Black.Window.Case.mp4

As seen from the clip, the black window trace only appears if there's a background window to the nested window, but it doesn't appear when the nested window doesn't have a background window (aka in the desktop screen)

[Louis047]

Another update: The lingering issue didnt go off completely, I was testing out with other applications, most of them didnt have the issue except for some installers, specifically the installer that ASUS standalone update packages use. Screenshot shows the lingering after installation.

[Louis047]

Another Update: I went ahead and forked the repository to work on the fixes by myself, with the help of Antigravity IDE. It helped me fix both the lingering window and the BelowWindow issue where the nested window border hide behind the background window. Submitted a PR #66

Not gonna lie, this tool is really powerful imo. Tested it manually and shall confirm everything was addressed.

[lukeyou05]

I left a few comments on the PR

[Louis047]

I have left my testing notes and crucial details below the PR after working a whole day on this, trying to figure out the root cause for BelowWindow border hide issue. Hope this help you to find the issue and come up with a fix @lukeyou05 (I'm brain dead officially for today lol)

[Louis047]

I'll close this issue now as the PR got merged (I can finally take rest in peace 😌)