Bug 456039 - 5.25.1 "shading" a gtk window continues to display the window's contents
Summary: 5.25.1 "shading" a gtk window continues to display the window's contents
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 5.25.1
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-06-27 14:50 UTC by Rob
Modified: 2022-07-25 17:34 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
video capturing the defect (654.76 KB, video/mp4)
2022-06-27 14:50 UTC, Rob
Details
brave window, pre-shaded (258.22 KB, image/png)
2022-06-27 14:52 UTC, Rob
Details
brave window, shaded (262.55 KB, image/png)
2022-06-27 14:52 UTC, Rob
Details
brave window, shaded and moved (291.88 KB, image/png)
2022-06-27 14:52 UTC, Rob
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rob 2022-06-27 14:50:29 UTC
Created attachment 150190 [details]
video capturing the defect

SUMMARY
Shade a gtk window (evolution, brave, firefox)  by double clicking title bar (or however you shade your window). The window decorations collapse as they should, however the original window contents continue to display. If you drag the collapsed title bar around, the zombie window contents paint away revealing the desktop behind the original window area.  Unshading the window back to normal behaves as expected and the full window is properly displayed.



STEPS TO REPRODUCE
1. Start a gtk app like evolution or brave, etc.
2. Double click the title bar, or otherwise shade the window.
3. Note the window decorations, border etc display the collapse/shade effect, however the original window contents continue to display right where they were.

OBSERVED RESULT
See #3 above

EXPECTED RESULT
The window should shade to just the title bar, and the area behind the original window should be visible.

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: Plasma 5.25.1
(available in About System)
KDE Plasma Version: 5.25.1
KDE Frameworks Version: 5.95.0
Qt Version: 5.15.5

ADDITIONAL INFORMATION

nvidia-drivers 515.48.07, kernel 5.15.11, both of which are unchanged with previous versions of plasma that do not demonstrate this behavior.

I suspect there may be a regression introduced with the fix applied for https://bugs.kde.org/show_bug.cgi?id=450582
Comment 1 Rob 2022-06-27 14:52:16 UTC
Created attachment 150191 [details]
brave window, pre-shaded
Comment 2 Rob 2022-06-27 14:52:41 UTC
Created attachment 150192 [details]
brave window, shaded
Comment 3 Rob 2022-06-27 14:52:59 UTC
Created attachment 150193 [details]
brave window, shaded and moved
Comment 4 Hans-Peter Jansen 2022-06-27 17:05:33 UTC
Some more observations to this issue: with my revert patch applied (https://bugs.kde.org/show_bug.cgi?id=450582), the shading/shuttering does work at times and produce the described behavior at other times. I've learned to "work-around" it by switching to an open konsole window, and back to firefox. This often fixes this behavior. The window content, if it keeps being displayed often flickers at a high frequency.
Comment 5 Rob 2022-06-27 17:18:04 UTC
Interesting, I cannot get a proper shade effect to work under any circumstances.  Shading, then switching to a Konsole and then back just continues to display the old window contents.  In fact, anything I drag into the old window area stays there and becomes part of the zombie window display.
Comment 6 Hans-Peter Jansen 2022-06-27 19:17:42 UTC
(In reply to Rob from comment #5)
> Interesting, I cannot get a proper shade effect to work under any
> circumstances.  Shading, then switching to a Konsole and then back just
> continues to display the old window contents.  In fact, anything I drag into
> the old window area stays there and becomes part of the zombie window
> display.

Sorry, I was too sparse, Rob. Here's the successful procedure:

DC (double click) Window header to shade it, content is still displayed.
DC again to redisplay the correct content. Switch/Open konsole on the same workspace. 
Switch back to dysfunctional window. DC again. Works in 3 of 4 cases for me.
Comment 7 Rob 2022-06-27 20:01:09 UTC
Hmm, try as I might I cannot duplicate that.  It just continues to exhibit the broken behavior.
Comment 8 Rob 2022-06-27 20:21:51 UTC
I just forced a rollback to kwin-5.24.5, and ran 

$ kwin_x11 --replace

And right away all windows are shading properly.
Comment 9 Rob 2022-07-07 16:45:47 UTC
This appears resolved now in 5.25.2?  If you agree @hpj I will close as fixed.
Comment 10 Hans-Peter Jansen 2022-07-07 17:21:57 UTC
(In reply to Rob from comment #9)
> This appears resolved now in 5.25.2?  If you agree @hpj I will close as
> fixed.

Thanks for the note, Rob. I've disabled my revert in the relevant build, but it takes a while to get this tested on my system zoo (because I and couple of others, that I infected with the Tumbleweed virus rely heavily on operational systems to do our day to day work). 

I restored a system backup on my primary workstation two times already related to this issue.
Comment 11 Hans-Peter Jansen 2022-07-07 17:23:03 UTC
FTR, my build is available here: 
https://build.opensuse.org/package/show/home:frispete:Tumbleweed/kwin5
Comment 12 Rob 2022-07-25 17:34:47 UTC
I believe this is resolved in 5.25.2 and now also 5.25.3.  Closing