Bug 314625 - window border "stays on top" after using present windows
Summary: window border "stays on top" after using present windows
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 4.10.0
Platform: Other Linux
: NOR normal
Target Milestone: 4.10.1
Assignee: KWin default assignee
URL: http://git.reviewboard.kde.org/r/108867/
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-07 20:34 UTC by Franz Trischberger
Modified: 2013-02-18 06:58 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In: 4.10.1
thomas.luebking: ReviewRequest+


Attachments
s/panelproxy heuristic/screenedge restack (4.88 KB, patch)
2013-02-08 19:14 UTC, Thomas Lübking
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Franz Trischberger 2013-02-07 20:34:46 UTC
1) open a kate window
2) open another kate window
3) arrange the windows so that they overlap
4) toggle present windows, select the kate window that is placed most right
5) Move the mouse to the region where the border of the other window (now stacked behind) should be
-> cursor changes to "resize" and when you click the other window raises.

That does not happen with every app!
e.g. konqueror and "bespin demo" seem to be immune when on top.

Reproducible: Always
Comment 1 Thomas Lübking 2013-02-07 20:40:58 UTC
Not saying it's related, but stay tuned on bug #313145
Comment 2 Franz Trischberger 2013-02-07 20:49:32 UTC
Thanks. I will go through the other bug report tomorrow.

It seemed as if just bespin deco was affected, but after setting  oxygen border to "none" this happens with oxygen, too.
Comment 3 Thomas Lübking 2013-02-07 20:58:16 UTC
Yes, it does seem we uncovered another bug from the "ancient ages of doom"

Bespin and oxygen w/o borders support the input window (ie. resizing the window w/o visual borders) what apparently exposes this bug on 64bit architectures.
Do you compile -O3?
Comment 4 Franz Trischberger 2013-02-07 21:25:40 UTC
I compile with -O2.
Comment 5 Thomas Lübking 2013-02-07 21:27:21 UTC
So does Alex, but it actually doesn't matter (could as well be something in QVector or whatnot)
The other bug has a patch attached. Feel free to try.
Comment 6 Franz Trischberger 2013-02-08 14:21:02 UTC
As I'm running 4.10.0 I had to modify the patch.
It did not fix this issue.
Comment 7 Martin Flöser 2013-02-08 14:25:49 UTC
> As I'm running 4.10.0 I had to modify the patch.
> It did not fix this issue.
then I think it's a different issue
Comment 8 Thomas Lübking 2013-02-08 18:21:39 UTC
Is the window "near" the edge?
In screenedge.cpp shortcut void ScreenEdge::raisePanelProxies() (return immediately) - does the issue remain?
Comment 9 Thomas Lübking 2013-02-08 19:14:23 UTC
Created attachment 77024 [details]
s/panelproxy heuristic/screenedge restack

Reporter says: "yes, shortcut seems to do", thus i suspect a false positive panelproxy hit on the input window(s)

@Franz
Please test the attached patch to substitute raising proxies by lowering screenedges.
Comment 10 Franz Trischberger 2013-02-08 19:32:40 UTC
Yes, the attached patch fixes the issue.
Thx :)
Comment 11 Thomas Lübking 2013-02-12 21:29:37 UTC
Git commit af37273c79d2da157a6821788676aad1ab522789 by Thomas Lübking.
Committed on 08/02/2013 at 20:59.
Pushed by luebking into branch 'KDE/4.10'.

do not try to raise possible panel proxies

but drop screenedges below the supportWindow instead
that's why it exists, that's deterministic, that's faster
FIXED-IN: 4.10.1
REVIEW: 108867

M  +1    -1    kwin/effects.cpp
M  +23   -0    kwin/layers.cpp
M  +0    -49   kwin/screenedge.cpp
M  +0    -5    kwin/screenedge.h
M  +1    -0    kwin/workspace.h

http://commits.kde.org/kde-workspace/af37273c79d2da157a6821788676aad1ab522789
Comment 12 Thomas Lübking 2013-02-12 21:30:17 UTC
Git commit 42e547571e963f4c63b4ae77b00cbf2d6652b5ad by Thomas Lübking.
Committed on 08/02/2013 at 20:59.
Pushed by luebking into branch 'master'.

do not try to raise possible panel proxies

but drop screenedges below the supportWindow instead
that's why it exists, that's deterministic, that's faster

includes adaption to new screenedge and xcb invocation (compared to 4.10)
FIXED-IN: 4.10.1
REVIEW: 108867

M  +1    -1    kwin/effects.cpp
M  +14   -0    kwin/layers.cpp
M  +0    -64   kwin/screenedge.cpp
M  +0    -5    kwin/screenedge.h
M  +4    -0    kwin/workspace.h

http://commits.kde.org/kde-workspace/42e547571e963f4c63b4ae77b00cbf2d6652b5ad