windows get shown on top when compton is active

[bebehei]

Current Behavior

Windows appearing after i3lock's start and in combination with compton will get shown on top. When compton is not active, the behavior is not seen.

Here's a screenshot of a clean Ubuntu VM with the reproduction instructions executed:

Expected Behavior

Windows shall get drawn below i3lock.

Reproduction Instructions

# On a clean Ubuntu 18.04 installation
$> sudo apt install i3-wm i3lock i3status dunst compton

# And after i3 login:
$> compton -c &
$> dunst &
$> (sleep 7 && notify-send a b) &
$> i3lock

Environment

Output of i3lock --version:

$> i3lock --version
i3lock: version 2.10 (2017-11-25) © 2010 Michael Stapelberg

Related

#130

Originally reported on dunst-project/dunst#553

[Airblader]

@stapelberg Why did we want to open a new issue here? We fixed it, it broke stuff, we reverted it. I'm not sure what else there is to do?

[stapelberg]

Can’t we find a new fix which doesn’t break? Or at least document the defect.

[bebehei]

Oh, shit, I forgot the most important part: I cannot reproduce it on ArchLinux.

I've also cloned now i3lock's repo and tested the following tags/branches: 2.9.1, 2.10, 2.11.1, master. All show the same bad behavior in the Ubuntu VM.

I believe it's a problem in the coupling of some library, which is used by Ubuntu 18.04.

[bebehei]

Sorry, my browser lagged. About "the library": I can definitely exclude compton: ArchLinux uses a fork of compton. I've compiled the fork on Ubuntu 18.04, but it doesn't help either.

[Airblader]

@stapelberg The author of xsecurelock commented on #96 and said that they also have the problem with different compositors and different configs thereof. His idea (for xsecurelock) was to maybe make it a flag whether to use the overlay window or not. That's about the only thing I can think of.

[4goettma]

I can partially confirm the descriped behaviour on Arch Linux. (I'm using compton with compton -b --dbe, not sure whether it works too with compton -c. I had also cases where I can't confirm the behaviour, I will do soon further tests.)

$> i3lock --version
i3lock: version 2.11.1 © 2010 Michael Stapelberg

$> compton --version
v4-rc1-14-gf834cf2

$> uname -a
Linux <hostname> 4.18.16-arch1-1-ARCH #1 SMP PREEMPT Sat Oct 20 22:06:45 UTC 2018 x86_64 GNU/Linux

[bebehei]

I can finally reproduce it on my own setup now, too. 🙈

Same compton and i3lock version, but Linux kernel 4.19.2-arch1-1-ARCH.

[Airblader]

@stapelberg How do you feel about hiding it behind a flag? We have a PR for that now.

[stapelberg]

I’m not a fan of flags for bugfixes.

Ideally, the fix would work in all environments.
The next best thing is if the code can auto-detect where the fix works.

Have we really exhausted all approaches yet?

[Airblader]

I didn't try to research this more, but with my current knowledge I can't think of anything else to try. @divVerent has the most knowledge about this with xsecurelock as far as I can see, and so his comment on #96 is the best information available to me.

Apart from a flag he suggested detecting the compositor, but that won't work in my opinion: 1) Only enabling it if no compositor is present kills the entire usecase since we usually only see this issue when a compositor is running and 2) if used a whitelist and didn't whitelist compton we might as well not bother at all, because compton is by far the most common compositor used with i3lock.

Looking at xsecurelock right now, some things seem to have happened:

1. It uses composite by default now but has an option to disable it.
2. There's an obscurer window feature, which sounds like what i3lock is doing too (didn't look in detail though). Noteworthy here is that the obscurer window is 1px smaller to prevent the compositor from unredirecting (I have no idea what that means)