Bug 365014

Can you run "xprop" and click on the desktop? Looks like it lost its desktop attribute and thus is treated like a regular window and is raised above the other windows when you click it.

Created attachment 99833 [details]
xprop result 2

xprop result for clicking on the desktop

I have the same issue on three different machines: two thinkpads with docking station and one desktop computer (without docking station). All systems are arch linux 64bit.

After update to KDE plasma 5.7 today the bug still exist. On my machine.

Greetings

The issue is that the desktop window loses _NET_WM_STATE_BELOW state.

https://phabricator.kde.org/D2121

> The issue is that the desktop window loses _NET_WM_STATE_BELOW state.

that state is irrelevant for a desktop window. The root problem must be somewhere else like the window never being properly set as a desktop window.

What's the xprop output of the plasmashell window with your change?

After an update to plasma 5.3.2-2 it is still there.
And I noticed you can make all hidden windows visible again, if you lower the desktop with a right-click (right-click -> context-menu, right-click besides the menu -> windows appear).

> After an update to plasma 5.3.2-2 it is still there.

Typo or really 5.3?

Yes, sorry. That was a mistake, the number is totally wrong.
I updated yesterday from 5.7.0-2 to 5.7.1-1 (plasma-desktop)

I, too, have this issue in 5.7.1-1 and it has been here since 5.6. For me it's a problem because it makes my Conky disappear.

I'm also running Arch Linux.

hey i'm having the same problem on a fresh install of arch linux 64-bit, kde plasma 5.7.1
didn't have the problem on manjaro, plasma 5.6.5

Today I updated to 5.7.2, but the issue is still there.

Have the same issue, and in fact the desktop behaves like if was a window, the other windows go "behind it" when loosing focus.

Here is what xprog gives me:

XdndAware(ATOM) = BITMAP
WM_NAME(STRING) = "Desktop"
_NET_WM_NAME(UTF8_STRING) = "Desktop — Plasma"
_KDE_NET_WM_USER_CREATION_TIME(CARDINAL) = 20752
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x1, 0x0, 0x0, 0x0
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DESKTOP
_XEMBED_INFO(_XEMBED_INFO) = 0x0, 0x1
WM_CLIENT_LEADER(WINDOW): window id # 0x200000c
WM_HINTS(WM_HINTS):
                Client accepts input or input focus: True
                Initial state is Normal State.
_NET_WM_PID(CARDINAL) = 687
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 33554448
WM_CLASS(STRING) = "plasmashell", "plasmashell"
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_NORMAL_HINTS(WM_SIZE_HINTS):
                user specified location: 0, 0
                user specified size: 1920 by 1080
                program specified minimum size: 1920 by 1080
                program specified maximum size: 1920 by 1080
                window gravity: Static

Just as a guess,

the problem might be from another source. Cause my fluxbox system with VirtualBox has a similar problem. When switching to fullscreen with a VirtualBox-System, it is not really a fullscreen as the fluxbox titlebar and all other windows stay above the fullscreen VirtualBox window.

Maybe it is realted to another component and we find some similarities to our system. Many people here seem to use ArchLinux. Another information might be interesting: T540p with nvidia and intel graphics adapter.

Greetings

hey guys, updated to 5.7.2 (on arch), bug still there
bug doesn't occur on wayland, only on X
(and if it's helpful, i have an amd card, open source drivers)

Created attachment 100261 [details]
The xprop result of clicking my desktop.

I also have this issue. I'm running a Skylake (6700HQ) with an Intel HD 530. I do not have this issue on OpenSUSE Tumbleweed, but I do have it on Arch Linux.

I attached my xprop as well.

Versions
---
KDE Plasma - 5.7.2
KDE Frameworks - 5.24.0
QT Version - 5.7.0
Kernel - 4.6.4-1-ARCH

At here, with the 

Qt 5.7.0
KF 5.7.2
Plasma 5.7.2
Arch Linux

Disabling the lines from the plasma-workspace-5.7.2 shell/desktopview.cpp as told at: https://bugs.kde.org/show_bug.cgi?id=365014#c5 and https://phabricator.kde.org/D2121 helps. No ill effects detected.

Same issue for me on Arch:
Qt 5.7.0-1
KDE 5.7.2
Plasma 5.7.2

Sean

Plasma desktop 5.7.2-1, still experiencing the same glitch after updating

(In reply to Rog131 from comment #17)
> At here, with the 
> 
> Qt 5.7.0
> KF 5.7.2
> Plasma 5.7.2
> Arch Linux
> 
> Disabling the lines from the plasma-workspace-5.7.2 shell/desktopview.cpp as
> told at: https://bugs.kde.org/show_bug.cgi?id=365014#c5 and
> https://phabricator.kde.org/D2121 helps. No ill effects detected.

Sorry where is this file located on an arch file system?

*** Bug 365898 has been marked as a duplicate of this bug. ***

(In reply to gurpal2000 from comment #20)
> (In reply to Rog131 from comment #17)
> > At here, with the 
> > 
> > Qt 5.7.0
> > KF 5.7.2
> > Plasma 5.7.2
> > Arch Linux
> > 
> > Disabling the lines from the plasma-workspace-5.7.2 shell/desktopview.cpp as
> > told at: https://bugs.kde.org/show_bug.cgi?id=365014#c5 and
> > https://phabricator.kde.org/D2121 helps. No ill effects detected.
> 
> Sorry where is this file located on an arch file system?

it's not. it's part of the source code.

(In reply to gurpal2000 from comment #20)
> (In reply to Rog131 from comment #17)
> > At here, with the 
> > 
> > Qt 5.7.0
> > KF 5.7.2
> > Plasma 5.7.2
> > Arch Linux
> > 
> > Disabling the lines from the plasma-workspace-5.7.2 shell/desktopview.cpp as
> > told at: https://bugs.kde.org/show_bug.cgi?id=365014#c5 and
> > https://phabricator.kde.org/D2121 helps. No ill effects detected.
> 
> Sorry where is this file located on an arch file system?

At here - short version:

- Grabbing Arch sources from https://www.archlinux.org/packages/extra/x86_64/plasma-workspace/
- Editing the ../src/plasma-workspace-5.7.2/shell/desktopview.cpp
- Building, makepkg with the '-e' option.
- Installing, pacman with the '-U' option.

@Rog131 thx, will try fix as suggested.

(In reply to Rog131 from comment #23)
> (In reply to gurpal2000 from comment #20)
> > (In reply to Rog131 from comment #17)
> > > At here, with the 
> > > 
> > > Qt 5.7.0
> > > KF 5.7.2
> > > Plasma 5.7.2
> > > Arch Linux
> > > 
> > > Disabling the lines from the plasma-workspace-5.7.2 shell/desktopview.cpp as
> > > told at: https://bugs.kde.org/show_bug.cgi?id=365014#c5 and
> > > https://phabricator.kde.org/D2121 helps. No ill effects detected.
...

Indeed this seems to work for me too. using it for a couple of days without problems so far.

I just updated to plasma 5.7.3, but the issue is still there.
And I tried to play a bit with the mouse focus settings:  it appears the same way (CLICK hides all windows) in every case. That is strange in case of all "focus follows mouse" settings with checked "raise on mouse enter" option. You should expect, that on mouse-over, if the desktop behaves like an ordinary window, it is "raised", i.e. all other windows disappear. If the mouse leaves a window (which loses the focus) and moves to another window, that second window gets the focus and is raised without click. But if the mouse moves from one window to the desktop, only a click will raise the desktop. Why? Here the desktop behaves NOT like a window.

Not sure if this helps, but it appears the parent parent 0x4028bae window is raised. Running `xwininfo -tree -root` shows:

  Root window id: 0x4aa (the root window) (has no name)
  Parent window id: 0x0 (none)
     190 children:
     ...
     0x4028bae (has no name): ()  1920x1080+0+0  +0+0
        1 child:
        0x4028baf (has no name): ()  1920x1080+0+0  +0+0
           1 child:
           0x5200010 "Desktop — Plasma": ("plasmashell" "plasmashell")  1920x1080+0+0  +0+0



xev -root shows something when the desktop is "raised". There's an extra "ConfigureNotify event, " and "_NET_CLIENT_LIST_STACKING" when the desktop is clicked.

Test Case:
Konsole Window is always on top. Then run 3 commands in different tabs.
xev -root > test.log
watch -n 0.5 -c "echo \"\\n\" >> test.log"
tail -f test.log
Then open another window (which will disappear) and click back and forth (minimize and reveal the window if it's taking forever).



ClientMessage event, serial 22, synthetic YES, window 0x5200010,
    message_type 0x172 (_NET_ACTIVE_WINDOW), format 32

PropertyNotify event, serial 22, synthetic NO, window 0x4aa,
    atom 0x172 (_NET_ACTIVE_WINDOW), time 394727465, state PropertyNewValue

PropertyNotify event, serial 22, synthetic NO, window 0x4aa,
    atom 0x172 (_NET_ACTIVE_WINDOW), time 394727466, state PropertyNewValue

ClientMessage event, serial 22, synthetic YES, window 0x5200010,
    message_type 0x14f (_NET_WM_STATE), format 32

ClientMessage event, serial 22, synthetic YES, window 0x5200010,
    message_type 0x14f (_NET_WM_STATE), format 32

ConfigureNotify event, serial 22, synthetic NO, window 0x4aa,
    event 0x4aa, window 0x4028bae, (0,0), width 1920, height 1080,
    border_width 0, above 0x40ce2be, override NO

PropertyNotify event, serial 22, synthetic NO, window 0x4aa,
    atom 0x1a7 (_NET_CLIENT_LIST_STACKING), time 394727473, state PropertyNewValue

Git commit 30b7e3f2423b07b372daffbe09e420ba1ef59ced by David Rosca.
Committed on 13/08/2016 at 06:50.
Pushed by drosca into branch 'master'.

DesktopView: Don't call ensureWindowType on FocusIn event

Fixes desktop window losing the keep-below flag.

Differential Revision: https://phabricator.kde.org/D2121

M  +0    -3    shell/desktopview.cpp

http://commits.kde.org/plasma-workspace/30b7e3f2423b07b372daffbe09e420ba1ef59ced

*** Bug 367961 has been marked as a duplicate of this bug. ***

Problem still persist hier on ArchLinux with plasma 5.7.4.

Greetings

(In reply to Christian Krippendorf from comment #30)
> Problem still persist hier on ArchLinux with plasma 5.7.4.

The fix is only in master, which means will be released with Plasma 5.8

A bug which hides all windows several times while working with KDE and breaks the workflow every time won't come with a next bugfix release but anytime in october with 5.8?

What ist the reason for that? Does the fix break anything else?

Greetings

> What ist the reason for that? Does the fix break anything else?

Hopefully not, but yes that's the thinking. We want to have it tested properly before shipping it to the users.

Unfortunately, the commit https://quickgit.kde.org/?p=plasma-workspace.git&a=commit&h=30b7e3f2423b07b372daffbe09e420ba1ef59ced has no effect here. After compiling plasma-workspace-5.7.4 with it, I still can reproduce the issue easily (on Manjaro Testing).

Please change the status!

I can confirm it works with master. Tested from K:U:F repositories. No need to change the status.

> I can confirm it works with master

So, other commits are also essential to fixing this bug? Which ones? I ask because this bug, together with bug #360219, has made a painful experience out of Plasma for months.

> No need to change the status.

 Martin Gräßlin said in https://bugs.kde.org/show_bug.cgi?id=365014#c33, "We want to have it tested properly before shipping it to the users." I told the result of my test.

>  I told the result of my test.

Which is appreciated. But we need testing with Plasma 5.8. All you now tested is that backporting doesn't work. There seem to be additional changes, which means the whole stack for Plasma 5.8 needs testing.

> There seem to be additional changes

OK! That's what I wanted to know. Thank you!

*** Bug 369634 has been marked as a duplicate of this bug. ***

I confirm that this bug is fixed in Plasma-5.8.1. Thanks!