From 79f4168fd6902218904cb973a8f4f234ddfb2fd9 Mon Sep 17 00:00:00 2001
From: Vlad Zahorodnii <vladzzag@gmail.com>
Date: Mon, 30 Sep 2019 11:30:04 +0300
Subject: [PATCH] Compute correct visible rect for client-side decorated
 clients

Summary:
Frame and buffer geometry don't have strict order. Either one of them can
be inside the other one, so we must take that into account when computing
visible bounds of the client including drop-shadows. We also have to take
sub-surfaces into account when determining the visible rect, however it's
out of scope for this patch.

Reviewers: #kwin, davidedmundson

Reviewed By: #kwin, davidedmundson

Subscribers: kwin

Tags: #kwin

Maniphest Tasks: T10867

Differential Revision: https://phabricator.kde.org/D24458
---
 toplevel.cpp | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/toplevel.cpp b/toplevel.cpp
index 78f510edcc..735aeba3e9 100644
--- a/toplevel.cpp
+++ b/toplevel.cpp
@@ -145,11 +145,14 @@ void Toplevel::disownDataPassedToDeleted()
 
 QRect Toplevel::visibleRect() const
 {
-    QRect r = decorationRect();
+    // There's no strict order between frame geometry and buffer geometry.
+    QRect rect = frameGeometry() | bufferGeometry();
+
     if (shadow() && !shadow()->shadowRegion().isEmpty()) {
-        r |= shadow()->shadowRegion().boundingRect();
+        rect |= shadow()->shadowRegion().boundingRect().translated(pos());
     }
-    return r.translated(frameGeometry().topLeft());
+
+    return rect;
 }
 
 Xcb::Property Toplevel::fetchWmClientLeader() const