Bug 218822

Created attachment 39074 [details]
desktop with 2 windows not shown in taskbar (they also can't be minimized until I switch to 4rth desktop)

Are you able to interact with these Konqueror windows when you are on a different desktop? You are not using effects, right? Does the problem persists, when you switch to another dekoration such as for example Plastik?

I have changed the decoration to plastic, loggout/logged in and received the same behaviour.

I can interact with both windows fine, I can also maximize and move them - I just can't minimize them and they are shown on all desktops. Also the 1st window is always shown above the 2nd - as if I have enabled "keep above others" option, but it is kept only obove the 2nd defective window - all "normal" windows can be shown above it.

I have also noted another thing - when I have just switched to 4th desktop (to which both windows belong to), this did not qured them from this issue - to return them to normal state I have pressed twice on their icons in the taskbar (which were available only on the 4rth desktop) - that minimized the window, then returned it back and it was already normal. So, taskbar might be responsible in some way for this behaviour.

Same thing here, also using 4.3.80 from openSUSE's KDE4:Factory repository.

Do those window restart with the session despite they were closed when you ended the session?

what's the output of (you'll have to click one of them)
xprop | grep -iE '(desktop|minimize)'
and (when clicking the background/desktop)
xprop | grep -i desktop

> Do those window restart with the session despite they were closed when you
ended the session?

Those windows were saved with session. I use manual session saving, added kmail instance on desktop4 to session and it also started in a bad way. Also after last restart another konqueror instance from the desktop1 also started in this bad way (my session always start on desktop2), so I suppose this might happen to windows which are started on all desktops except the one session starts with.

With plastic decoration I have also noted another thing which were not visible with oxygen decoration. All those defective windows have inactive (grey with my color cheme) window title decoration enen when I click on it and drag window, when I click on the taskbar item, decoration becomes active (yellow with my color cheme) and the problem disappears for it. This gives me a feeling that this window is already minimized according to its some interal state, but the system by some reason paints is restored.


clicked on the defective kmail window when it is on the wrong desktop:

> xprop | grep -iE '(desktop|minimize)'
_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE
_NET_WM_DESKTOP(CARDINAL) = 3

clicked on the defective kmail window when it is on the right desktop, but still with problem:

> xprop | grep -iE '(desktop|minimize)'
_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE
_NET_WM_DESKTOP(CARDINAL) = 3


clicked on the desktop:
> xprop | grep -i desktop
_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_CHANGE_DESKTOP
_NET_WM_DESKTOP(CARDINAL) = 4294967295
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DESKTOP
WM_NAME(STRING) = "plasma-desktop"
WM_COMMAND(STRING) = { "/usr/bin/plasma-desktop" }


clicked on kmail window after it was cured by clicking on its task bar item:
> xprop | grep -iE '(desktop|minimize)'
_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE
_NET_WM_DESKTOP(CARDINAL) = 3

(In reply to comment #6)
> color cheme) and the problem disappears for it. This gives me a feeling that
> this window is already minimized according to its some interal state, but the
> system by some reason paints is restored.

can you please test "xprop | grep -i state" on such defective window?
(the desktop for the kmail window is always "3", what should cause kwin to unmap ("minimize") it for all other desktops... unless it's already (assumed to be) unmapped...

(sidenote: the window can be moved although the action is not allowed...)

On defective konqueror window from 4th desktop:

> xprop | grep -i state
WM_STATE(WM_STATE):
                window state: Normal
_NET_WM_STATE(ATOM) = _NET_WM_STATE_HIDDEN
                Initial state is Normal State.


the same window after being normalized:
> xprop | grep -i state
WM_STATE(WM_STATE):
                window state: Normal
_NET_WM_STATE(ATOM) =
                Initial state is Normal State.

does this problem still exist?

I am on another comp with kde 4.6beta, don't remember receiving this issue for now.

closing by comment #10