Notifications is shown over auth screen

[arcan1s]

Hi,

When an auth screen is activated notifications (at least skype and kde notifications) are shown over this screen. auth_pam_x11 and auth_pamtester modules are affected.

Is it possible to paint auth screen on the foreground?

[divVerent]

The window already forces itself to foreground - but so do these notifications.

Can you answer these questions:

• Can it be reproduces with Chrome/Gmail notifications?
• Do the notifications of your KDE setup happen to be transparent? That might explain getting no VisibilityNotify message.
• Are you using a compositor? Probably yes.
• Does xscreensaver or any other non KDE specific saver handle this better?

I could always add back the hack to periodically bring the lock screen to the front. But I want to find out if there ia a better way that is less heavy on X and CPU/battery usage.

[arcan1s]

• Seems that Chromium/Gmail and Firefox/Gmail don't show notification over auth screen. So may be there is a problem in Qt?
• Notifications are not transparent itself, they inherit default plasma theme which is transparent. I've attached the screenshot: Skype notification of course is not transparent.
• Yes I use composite WM (kwin) and have enabled graphical effects.
• xscreensaver KDE notifications are shown over xscreensaver too.

[divVerent]

OK, for the plasma notification this explains everything. When compositing, probably a transparent window above another window does not cause VisibilityNotify events which xsecurelock and xscreensaver rely on. I'll see whether there's a better way for this or whether I really need to periodically raise the window.

As for Skype, that's interesting. I wonder whether I can even reproduce that, given I don't use a compositing WM.

I think I'll try to find a solution for the Qt problem first, and possibly that will fix Skype too.

[arcan1s]

thanks!

[divVerent]

(Just reproduced the issue of not getting VisibilityNotify when overlapped by a transparent window using xev, xcompmgr and transset; I also get no ConfigureNotify for this, as opposed to its documentation)

[divVerent]

This should be fixed by default now, using the hack to periodically raise the window.

I also added code to possibly detect other windows being raised atop the screen saver - can you see if this works by compiling the code with the line #define AUTO_RAISE in main.c commented out?

[arcan1s]

Sure, I'll test it soon

[arcan1s]

well, I've tested it on KDE email notification from kmail and x11_auth module. Seems it still doesn't work =(

// sorry for delay

[corpix]

I have similar problems with dunst on Archlinux. I am using xsecurelock https://github.com/google/xsecurelock/commit/b6f1476c2317f2734f0f31218df0dcfd91863794 built from git.

[divVerent]

Thank you, this can prove quite helpful especially as dunst is well configurable.

Can you provide the following information:

• Your dunst configuration file (possibly shortened but still causing the issue)
• The window manager and compositor you are using

I think with this information I should be finally able to reproduce and fix it. I actually already have an idea how to do this, however it depends on knowing whether there is a compositor or not and thus may need a command-line flag.

[corpix]

My apologies for late answer.

There are my configs:

• dunst 1.1.0-1
• compton 0.1_beta2-5 compositor. Command-line to run it /usr/bin/compton -b --config /home/corpix/.compton.conf

Also I am using openbox window manager. I could show configuration file, but don't see the point to do this because I have changed some key bindings only, leaving other things default. I will attach it if more information will be required.

[divVerent]

Pushed an attempt at using the composite overlay window to a branch called "xcomposite". Can you try this?

Even with your configs, I can't reproduce the issue - however, I did notice that with your compton config, the screen "fades out" at startup of the screen saver, which does worry me as it shows there are chances the compositor can make the screen saver transparent. Using the composite overlay window fixes that part.

[corpix]

Thanks for you work, but I have moved to gnome-shell for a while, not sure I could try it soon, sorry.

[divVerent]

I pushed the changes to use the XComposite overlay window to master. Seems to work fine and, as said, I can observe that there is no fading out effects or anything similar that may make anything shine through while the screen saver is running. So I assume this covers notifications too.

Considering this solved now.

[amosbird]

I can still see notifications after doing xsecurelock. I'm using archlinux + bspwm + dunst + picom.

dunst configuration: http://oracle.wentropy.com/24ad52f2d821a72c picom has no custom configurations.

[divVerent]

Most likely this is an incompatibility between the compositor and the method xsecurelock uses to go around it.

First thing worth trying thus is XSECURELOCK_NO_COMPOSITE=1 - it will then behave just as good/bad as any other locker.

On Fri, Oct 15, 2021, 02:12 Amos Bird @.***> wrote:

I can still see notifications after doing xsecurelock. I'm using archlinux + bspwm + dunst + picom.

dunst configuration: http://oracle.wentropy.com/24ad52f2d821a72c picom has no custom configurations.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/google/xsecurelock/issues/6#issuecomment-944029556, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAB5NMA3DFOCNV422VX6H4DUG7A5LANCNFSM4AVG24AQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[coffebar]

I have this issue on i3 with xcompmgr compositor. Dunst