Taskbar appears unexpectedly with some applications in fullscreen mode

[Vrihub]

(I initially noticed this bug using the mpv video player in fullscreen mode, but it seems to be a more general problem with applications in fullscreen mode, see the "Notes" section below)

Steps to reproduce:

• 1 Watch a video in fullscreen mode with mpv
• 2.a Switch from fullscreen mode to normal window mode (using "f" in mpv, or icewm's Alt-F11), then back again to fullscreen mode: the icewm taskbar will stay visible and it will steal the keyboard/mouse focus OR
• 2.b Have a new window appearing over the fullscreen video (e.g. a popup alert window from some other application): the new window AND the taskbar will appear; if you close the new window, the taskbar will stay visible (but in this case the keyboard/mouse focus will stay on the video)

To make the taskbar disappear I have to either click on the video, or switch the focus back to it by Alt-Tab, or move the mouse pointer over the taskbar, and then up away from it.

Expected result: the taskbar should never appear over a fullscreen window.

Notes:

• In step 2, switching to another application (Alt-tab), or to another desktop, and then switching back to the video does NOT trigger the bug.
• Setting the video window as "always on top" (using icewm's menu command, or using mpv's "--ontop" option) doesn't help; i.e. the bug still happens
• Other video players besides mpv, are affected in exactly the same way: I tested mplayer and vlc
• Other applications (e.g. xterm, audacious) are affected by case 2.a and not by 2.b, or vice versa. (tested using icewm's Alt-F11 fullscreen command)
• Some applications are not affected at all: e.g Firefox works as expected
• I'm running icewm 1.3.8+mod+20 on Debian 9.3 (xorg 7.7+19)
• I have TaskBarFullscreenAutoShow=0 in my icewm preferences

Please let me know if you need other info, I'll be glad to help in debugging.

[Code7R]

Can you make a screenshot? Is this only because of fullscreen mode? If it's hard to catch, you could use a timed command, like: sleep 5; xwd -root | convert xwd:- /tmp/screeni.png

This partly reminds of my own issue reported upstream, see https://github.com/bbidulock/icewm/issues/220 for details.

[Vrihub]

Can you make a screenshot?

Well, just imagine a video (or some other app) in full screen, and the icewm taskbar over it. That's it.

Is this only because of fullscreen mode?

Yes; AFAIK fullscreen is the only mode when the taskbar is supposed NOT to appear, so it's the only mode when the bug (i.e. the taskbar appears and stays) can happen.

This partly reminds of my own issue reported upstream, see bbidulock#220 for details.

Uhm, I don't think that bug is related: besides I can't reproduce it, there's nothing wrong in my taskbar (no spooky windows or anything strange), it just appears and stays on, when it's not supposed to.

(BTW: should I better file this issue into the bbidulock's icewm repo? I can't remember exactly why I came here, I guess it was the only repo mentioned in the Debian package documentation)

[Vrihub]

Interesting news: I've installed icewm 1.4.3.0~pre-2017122 from Debian Experimental (to test your enhancement in #9) and this bug doesn't occur anymore in case 2.a above (e.g. switching back and forth fullscreen mode), with any application (video players, and other apps in fullscreen via Alt-F11)!

Please note that I didn't upgrade anything else in my system, so the upgrade from 1.3.8 to 1.4.3 must have made the magic.

Only case 2.b (a new window appearing also triggers the taskbar) still happens, but this is way less important, because it happens very rarely and because the taskbar doesn't also steal the focus (and somehow it might also be considered as intended behaviour), so as far I am concerned you can now give this issue a very low priority, or even close it.

[Code7R]

And, still occurring with the latest builds?

[Vrihub]

No, as I said in my last message, version 1.4.3.0 fixed the worst case scenario (and the other scenario is not that problematic, at least for me).

I haven't installed newer versions, so I can't tell if the bug re-appeared (if this is what you were wondering).