Notification window not shown on top after restarting the window manager

[blueyed]

I have noticed that dunst notifications are not visible above other clients, after the window manager (awesome) has been restarted.

It seems like dunst only puts its window on top when it creates the first notification, but not for additional ones.

I think a good enough fix might be to put dunst's window on top for every new notification.

[mgraham]

I'm seeing the not-on-top behaviour as well, but I'm having trouble reproducing it. It's not related to restarting my window manager. It seems to happen after long periods of inactivity.

(edit: I reproduced it and created issue #225)

[Seeryn]

Can anyone confirm if this is still an issue on HEAD?

[rafaqz]

This is still happening on arch/xmonad. Again its hard to reproduce, but also seems after long periods of inactivity.

[rafaqz]

I think I have to take that back... This is now only happening to when I have another window maximised. Still an issue but less random.

[bebehei]

Ok, I have researched the topic yesterday after we hit a similar bug in https://github.com/dunst-project/dunst/pull/496#issuecomment-381760930.

Dunst uses two common techniques to stay on top of all windows:

• XMapRaised call, when the window gets shown with a fresh notification and no notifications had been displayed in the moment before
• _NET_WM_STATE_ABOVE to tell the window manager to display this window above all others (except for those, which manually layer on top).

This has got very neat effects. In combination with _NET_WM_STATE_ABOVE, the window manager keeps track of the layering and doesn't layer dunst above more important windows: e.g. the lockscreen manager. And the XMapRaised call is done only once, when it's important. Because there is a VisibilityNotify XEvent which you can listen on. This event fires, if another window is shown above you. So, a proper lockscreen manager will listen on it to hide other windows even if they want to show up. It does something similar to XMapRaised and lifts itself on the stack. If we would listen to this event and respond with a raise in dunst, we'd create an endless loop of our lockscreen manager and dunst. This is an undesirable solution.

That's why the _NET_WM_STATE_ABOVE got introduced to stop such issues. I found the corresponding PR #146

for xmonad: It's ICCCM compatible, but it doesn't make any statements towards XDG's WM specification (_NET_WM_STATE_ABOVE is defined in XDG). Also I haven't found hints for this. While writing this, I've asked the guys in the IRC. extended window manager hints shall be supported. @rafaqz Do you use the EWMH package? If not, you should know now the source of the problem. :wink:

---

All in all, as there is no further information which versions are involved, there is no path to trace back, which versions got tested before the bugreport got opened.

@blueyed Does this actually still happen?

[blueyed]

@bebehei Thanks for clearing things up! Yes, it still happens for me, to reproduce:

1. go to a new/empty tag in awesomeWM
2. open a (tiled) terminal window
3. trigger a notification: notify-send foo
4. the notification shows up as expected above the terminal window
5. restart awesome, and go back to the previous tag if necessary

The notification is now hidden behind the terminal window.

For reference: awesome v4.2-291-gd9cc56538, dunst 1.3.1.

So it might be a bug in awesomeWM after all, since it appears to not handle the _NET_WM_STATE_ABOVE correctly on restart: it should stack the notification window above the terminal, shouldn't it? /cc @psychon

[bebehei]

I've created a small reproducer for the _NET_WM_STATE_ABOVE.

On awesomewm you can even erase the contents of the window after restart. i3 also ignores _NET_WM_STATE_ABOVE, but the window is still visible (but layered on the bottom).

I'm not getting enlightened by the WM spec section either and so I don't know if I actually have to fix it in dunst or say, it's awesome's/i3's issue.

[bebehei]

Well, it's not i3's issue. See https://github.com/i3/i3/issues/3265#issuecomment-384314904 I now understand i3's behavior, which was quite weird for me.

It finally think this is actually a bug in awesomewm.

[psychon]

The only call to XCreateWindow "in here" that I found sets OverrideRedirect to true. Such windows are not managed by the WM and so setting _NET_WM_STATE_ABOVE has no effect.

This issue is also not specific to restarting awesome: From the X11 protocol reference, new windows are on top of the stacking order (docs for CreateWindow):

The window is placed on top in the stacking order with respect to siblings.

https://www.x.org/releases/X11R7.5/doc/x11proto/proto.html (sorry, you have to scroll quite a bit to find the paragraph)

Thus, any window that is created after dunst created its window will end up being above it.

If you want to waste CPU time, I would suggest setting a timer and raising your window e.g. every five seconds. If you want to spend a bit more coder timer, select SubstructureNotify on the root window and raise your window(s) whenever you get a CreateNotify event.

[bebehei]

@psychon Thanks for enlighting us. Do I read your post right, that _NET_WM_STATE_ABOVE is actually useless and void in our code and we actually should remove it?

If you want to spend a bit more coder timer, select SubstructureNotify on the root window and raise your window(s) whenever you get a CreateNotify event.

@tsipinakis I think that could be even the easiest and cleanest solution to solve this bug here and even https://github.com/dunst-project/dunst/pull/496#issuecomment-381760930 which was my initial researcher bug. Then you can call x_win_show all the time you like, still have the visible field removed and as I assume it's just a few lines in code.

@tsipinakis Would you mind implementing the solution in #496 ?

[psychon]

Do I read your post right, that _NET_WM_STATE_ABOVE is actually useless and void in our code and we actually should remove it?

Well... I do not know. If you want me to guess: Yes. However, I wouldn't bet that there is nothing out there that actually looks at that property (but I do not really know what piece of software this would be; However since this is X11, something surely does).

I think that could be even the easiest and cleanest solution to solve this bug here and even #496 (comment) which was my initial researcher bug.

Well, no, my suggestion would actually make dunst show consistently above the lock screen. Once the lock screen is opened, dunst would raise its own window above it. If I remember correctly, xscreensaver raises its own window to the top every $X seconds, but I'd be surprised if e.g. i3lock were to do the same.

Oh, wait. No, my suggestion would not make dunst show consistently above the lock screen. Instead, there is the possibility for a race. i3lock creates its window and then raises it to the top. If dunst manages to raise its own window between i3lock creating and raising its window, i3lock ends up on top. Otherwise, dunst ends up on top. https://github.com/i3/i3lock/blob/ae72b675ca4f104fc210e5ad476a8b91acf6beb3/xcb.c#L129-L160

(However, since xcb caches requests and does not actually send out things immediately, this race is highly unlikely and I would expect dunst to end up consistently above the lock screen)

[tsipinakis]

I've implemented the solution in #496 can you build from the refactor-drawing branch and verify that it works correctly?

Well, no, my suggestion would actually make dunst show consistently above the lock screen

Looking at the docs for XCreateWindowEvent there's an override_redirect field. Given that screen lockers and the like tend to have that bit set, I set it so that it only raises the window if the window generating the event doesn't have override_redirect.

This can still cause an issue if a window is created after the screen locker is started but I don't see many cases of that happening.

[bebehei]

verify that it works correctly?

Yes, I can verify it now for awesomewm. @tsipinakis awesome! Testing it with i3lock still stands out, but this will be part of review in #496.