Bug 381610 - windows sometimes shifted upwards when starting new program
Summary: windows sometimes shifted upwards when starting new program
Status: RESOLVED DUPLICATE of bug 361236
Alias: None
Product: kwin
Classification: Unclassified
Component: aurorae (show other bugs)
Version: 5.8.7
Platform: Mint (Ubuntu based) Linux
: NOR crash (vote)
Target Milestone: ---
Assignee: KWin default assignee
Depends on:
Reported: 2017-06-24 16:03 UTC by Paul Loock
Modified: 2017-06-27 12:29 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:

Detailed description of crashes; my system parameters (9.33 KB, text/plain)
2017-06-24 16:03 UTC, Paul Loock

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Loock 2017-06-24 16:03:14 UTC
Created attachment 106274 [details]
Detailed description of crashes;  my system parameters

Desktop-windows are sometimes shifted upwards by the size of the upper decoration. If the window was already at y-position zero the upper decoration is lost and the window is not movable nor can it be closed if no menu or close-button exists.
"kde4-config --version" shows KDE: 4.14.22
Comment 1 Christoph Feck 2017-06-25 09:48:49 UTC
As a workaround use the breeze window decoration.

*** This bug has been marked as a duplicate of bug 361236 ***
Comment 2 Paul Loock 2017-06-26 09:00:15 UTC
(In reply to Christoph Feck from comment #1)
> As a workaround use the breeze window decoration.
> *** This bug has been marked as a duplicate of bug 361236 ***

Bug #381610 
Thank You for quick reply. I changed all my KDE-settings to breeze but it doesn't help.
After several restarts of the system to get a clean memory cache I could nearly reproduce the prior described window shifting after starting and closing 5 to 20 different programms, some of them starting at position 0,0. The triggering programm for the window shift is not always the same.
Maybe window positioning is a more common problem as I learned from QtCreator5.6-help:
On X11, a window does not have a frame until the window manager decorates it. This happens asynchronously at some point in time after calling QWidget::show() and the first paint event the window receives, or it does not happen at all. Bear in mind that X11 is policy-free (others call it flexible). Thus you cannot make any safe assumption about the decoration frame your window will get. Basic rule: There's always one user who uses a window manager that breaks your assumption, and who will complain to you.
Furthermore, a toolkit cannot simply place windows on the screen. All Qt can do is to send certain hints to the window manager. The window manager, a separate process, may either obey, ignore or misunderstand them. Due to the partially unclear Inter-Client Communication Conventions Manual (ICCCM), window placement is handled quite differently in existing window managers.
X11 provides no standard or easy way to get the frame geometry once the window is decorated. Qt solves this problem with nifty heuristics and clever code that works on a wide range of window managers that exist today. Don't be surprised if you find one where QWidget::frameGeometry() returns wrong results though.
Nor does X11 provide a way to maximize a window. QWidget::showMaximized() has to emulate the feature. Its result depends on the result of QWidget::frameGeometry() and the capability of the window manager to do proper window placement, neither of which can be guaranteed. 

Maybe there is a problem with my linuxMint installation because I left my home-partition from my last openSuse 13.2 untouched during installation. OpenSuse 13.2/KDE without nouveau driver and another kernel worked for a long time without problems on the same hardware. I don't like unresolved problems. So I will backup my system an then reinstall a linuxMint 18.1/KDE on formatted partitions. If that would not help I will install openSuse Leap 42.2/KDE both with the nouveau driver. Perhaps it will take some time until I can post a result.

Comment 3 Christoph Feck 2017-06-26 11:20:45 UTC
Your initial bug report mixed a crash report and a shifting issue. Note that whenever KWin crashes, the decorations are temporarily removed, and only re-added to the windows when it is running again, so I assumed the shifting was caused by the crash.

If this happens again, please add the output of this Konsole command:

qdbus-qt5 org.kde.KWin /KWin supportInformation

Changing status until you can provide more information.
Comment 4 Paul Loock 2017-06-27 11:27:24 UTC
Thank you for your work.
bug#381610 june 27, 2017

My system just got frozen after nearly one day running perfect. I think you are right that window-shifting was a secondary process after KWin crashed. I have never seen it again so we are now perhaps in the wrong bug lane.
By the way: Yesterday I installed a brand new linuxMint 18.1 at the now active partitions and tested it with some of my own Qt-programms and a lot of standard software inside the new linuxMint installation. After some hours without any crash I restored my actual working distribution and there were no problems with video-cut and -demux and fullscreen-video playing etc..
Everything worked fine until now:
At clicking for more information inside a newspaper Firefox (54.0(64 Bit) for linuxMint) gave a small message about the site to be downloaded and than froze. My system-information tool at the right side of the screen had just enough time to show the running processes bevor it froze too. The mouse was still movable but without any action possibility(keyboard dead too) so I had to take a screen picture with my camera.

The last catch of running processes ordered by CPU activity:

kwin_killer   13 %
firefox      6.2 %
paulsys      1.6 % (my information tool)
Xorg         0.4 %
kwin_x11     0.2 %
plasmashell  0.1 %
pulseaudio   0.1 %
systemd      0.0 %
kthreadd     0.0 %
ksoftirq/0   0.0 %
kworker/0:0  0.0 %
kworker/u8:..0.0 %

output of <qdbus org.kde.KWin /KWin supportInformation>:
(qdbus-qt5 doesn't exist on my System);

KWin version: 5.8.7
Qt Version: 5.6.1
Qt compile version: 5.6.1
XCB compile version: 1.11.1

Operation Mode: X11 only

Build Options
HAVE_X11_XCB: yes

Vendor: The X.Org Foundation
Vendor Release: 11804000
Protocol Version/Revision: 11/0
SHAPE: yes; Version: 0x11
RANDR: yes; Version: 0x14
DAMAGE: yes; Version: 0x11
Composite: yes; Version: 0x4
RENDER: yes; Version: 0xb
XFIXES: yes; Version: 0x50
SYNC: yes; Version: 0x31
GLX: yes; Version: 0x0

Plugin: org.kde.breeze
Blur: 0
onAllDesktopsAvailable: false
alphaChannelSupported: true
closeOnDoubleClickOnMenu: false
decorationButtonsLeft: 0, 2
decorationButtonsRight: 6, 3, 4, 5
borderSize: 2
gridUnit: 10
font: Noto Sans,10,-1,0,50,0,0,0,0,0
smallSpacing: 2
largeSpacing: 10

focusPolicy: 0
nextFocusPrefersMouse: false
clickRaise: true
autoRaise: false
autoRaiseInterval: 0
delayFocusInterval: 0
shadeHover: false
shadeHoverInterval: 200
separateScreenFocus: false
placement: 4
focusPolicyIsReasonable: true
borderSnapZone: 10
windowSnapZone: 10
centerSnapZone: 0
snapOnlyWhenOverlapping: false
rollOverDesktops: false
focusStealingPreventionLevel: 1
legacyFullscreenSupport: false
operationTitlebarDblClick: 5019
operationMaxButtonLeftClick: 5000
operationMaxButtonMiddleClick: 5015
operationMaxButtonRightClick: 5014
commandActiveTitlebar1: 0
commandActiveTitlebar2: 31
commandActiveTitlebar3: 2
commandInactiveTitlebar1: 4
commandInactiveTitlebar2: 31
commandInactiveTitlebar3: 2
commandWindow1: 7
commandWindow2: 8
commandWindow3: 8
commandWindowWheel: 31
commandAll1: 10
commandAll2: 31
commandAll3: 14
keyCmdAllModKey: 16777251
showGeometryTip: false
condensedTitle: false
electricBorderMaximize: false
electricBorderTiling: false
electricBorderCornerRatio: 0.25
borderlessMaximizedWindows: false
killPingTimeout: 5000
hideUtilityWindowsForInactive: false
inactiveTabsSkipTaskbar: false
autogroupSimilarWindows: false
autogroupInForeground: false
compositingMode: 1
useCompositing: true
compositingInitialized: true
hiddenPreviews: 0
glSmoothScale: 1
colorCorrected: false
xrenderSmoothScale: false
maxFpsInterval: 16666666
refreshRate: 0
vBlankTime: 6000000
glStrictBinding: true
glStrictBindingFollowsDriver: true
glCoreProfile: false
glPreferBufferSwap: 101
glPlatformInterface: 1
windowsBlockCompositing: true

Screen Edges
desktopSwitching: false
desktopSwitchingMovingClients: true
cursorPushBackDistance: 1x1
timeThreshold: 150
reActivateThreshold: 350
actionTopLeft: 0
actionTop: 0
actionTopRight: 0
actionRight: 0
actionBottomRight: 0
actionBottom: 0
actionBottomLeft: 0
actionLeft: 0

Multi-Head: no
Active screen follows mouse:  no
Number of Screens: 1

Screen 0:
Name: DVI-D-1
Geometry: 0,0,1280x1024
Refresh Rate: 60.0197

Compositing is active
Compositing Type: OpenGL
OpenGL vendor string: nouveau
OpenGL renderer string: Gallium 0.4 on NV106
OpenGL version string: 3.0 Mesa 11.2.0
OpenGL platform interface: GLX
OpenGL shading language version string: 1.30
Driver: Nouveau
GPU class: Unknown
OpenGL version: 3.0
GLSL version: 1.30
Mesa version: 11.2
X server version: 1.18.4
Linux kernel version: 4.4
Direct rendering: Requires strict binding: yes
GLSL shaders:  yes
Texture NPOT support:  yes
Virtual Machine:  no
OpenGL 2 Shaders are used
Painting blocks for vertical retrace:  no

Loaded Effects:

Currently Active Effects:

Effect Settings:
zoomFactor: 1.2
mousePointer: 0
mouseTracking: 0
enableFocusTracking: false
followFocus: true
focusDelay: 350
moveFactor: 20
targetZoom: 1






duration: 350
effect: 0
angle: -90



type: 1


Comment 5 Christoph Feck 2017-06-27 12:29:18 UTC
If Firefox freezes, you should report this to Firefox developers. Unless you provide more evidence that there is a bug in KWin different from the crash reported, please open a new ticket.

*** This bug has been marked as a duplicate of bug 361236 ***