When moving the mouse over ui elements (if a browser then only when the mouse cursor is near the top not in in fullscreen windows, the windows will lose focus and the window title will change color as if it was now a background window. This seems to happen in any fullscreen window that has a titlebar (not steam, but in dolphin, browsers, etc) and it only happens when kwin 3d mode is enabled. opensuse 13.2 Reproducible: Always
Errrr.... what?? =) a) fullscreen windows do not have a titlebar (by definition) - do you refer to maximized windows? b) kwin doesn't know whether a "UI element" is approached. Is it maybe related to tooltips? c) can you capture the situation in a screenshot (so we know what we're talking about)? d) please attach the output of qdbus org.kde.KWin /KWin supportInformation in any case
a) maximized $ qdbus org.kde.KWin /KWin supportInformation KWin Support Information: The following information should be used when requesting support on e.g. http://forum.kde.org. It provides information about the currently running instance, which options are used, what OpenGL driver and which effects are running. Please post the information provided underneath this introductory text to a paste bin service like http://paste.kde.org instead of pasting into support threads. ========================== Version ======= KWin version: 5.3.0 Qt Version: 5.4.1 Qt compile version: 5.4.1 XCB compile version: 1.11 Operation Mode: X11 only Build Options ============= KWIN_BUILD_DECORATIONS: yes KWIN_BUILD_TABBOX: yes KWIN_BUILD_ACTIVITIES: yes HAVE_WAYLAND: yes HAVE_WAYLAND_EGL: yes HAVE_WAYLAND_CURSOR: yes HAVE_XKB: yes HAVE_INPUT: no HAVE_XCB_CURSOR: yes HAVE_XCB_SYNC: yes HAVE_X11_XCB: yes X11 === Vendor: The X.Org Foundation Vendor Release: 11601000 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 Decoration ========== Plugin: org.kde.breeze Theme: Blur: 0 onAllDesktopsAvailable: true alphaChannelSupported: true closeOnDoubleClickOnMenu: false decorationButtonsLeft: 0 decorationButtonsRight: 3, 4, 5 borderSize: 3 gridUnit: 12 font: Droid Sans,10,-1,5,50,0,0,0,0,0 smallSpacing: 3 largeSpacing: 12 Options ======= focusPolicy: 0 nextFocusPrefersMouse: false clickRaise: true autoRaise: false autoRaiseInterval: 0 delayFocusInterval: 0 shadeHover: false shadeHoverInterval: 250 separateScreenFocus: false placement: 4 focusPolicyIsReasonable: true borderSnapZone: 10 windowSnapZone: 10 centerSnapZone: 0 snapOnlyWhenOverlapping: false rollOverDesktops: true focusStealingPreventionLevel: 1 legacyFullscreenSupport: false operationTitlebarDblClick: 5000 operationMaxButtonLeftClick: 5000 operationMaxButtonMiddleClick: 5015 operationMaxButtonRightClick: 5014 commandActiveTitlebar1: 0 commandActiveTitlebar2: 1 commandActiveTitlebar3: 2 commandInactiveTitlebar1: 4 commandInactiveTitlebar2: 30 commandInactiveTitlebar3: 2 commandWindow1: 7 commandWindow2: 8 commandWindow3: 8 commandWindowWheel: 31 commandAll1: 10 commandAll2: 3 commandAll3: 14 keyCmdAllModKey: 16777250 showGeometryTip: false condensedTitle: false electricBorderMaximize: true electricBorderTiling: true electricBorderCornerRatio: 0.25 borderlessMaximizedWindows: false killPingTimeout: 5000 hideUtilityWindowsForInactive: true inactiveTabsSkipTaskbar: false autogroupSimilarWindows: false autogroupInForeground: true compositingMode: 1 useCompositing: true compositingInitialized: true hiddenPreviews: 1 unredirectFullscreen: false glSmoothScale: 1 colorCorrected: false xrenderSmoothScale: false maxFpsInterval: 16666666 refreshRate: 0 vBlankTime: 6000000 glStrictBinding: false glStrictBindingFollowsDriver: true glCoreProfile: true glPreferBufferSwap: 0 glPlatformInterface: 1 Screen Edges ============ desktopSwitching: false desktopSwitchingMovingClients: false cursorPushBackDistance: 1x1 timeThreshold: 150 reActivateThreshold: 350 actionTopLeft: 0 actionTop: 0 actionTopRight: 0 actionRight: 0 actionBottomRight: 0 actionBottom: 0 actionBottomLeft: 0 actionLeft: 0 Screens ======= Multi-Head: no Active screen follows mouse: yes Number of Screens: 1 Screen 0 Geometry: 0,0,1920x1080 Compositing =========== Compositing is active Compositing Type: OpenGL OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GTX 750 Ti/PCIe/SSE2 OpenGL version string: 3.1.0 NVIDIA 346.59 OpenGL platform interface: GLX OpenGL shading language version string: 1.40 NVIDIA via Cg compiler Driver: NVIDIA Driver version: 346.59 GPU class: Unknown OpenGL version: 3.1 GLSL version: 1.40 X server version: 1.16.1 Linux kernel version: 3.16.7 Direct rendering: Requires strict binding: no GLSL shaders: yes Texture NPOT support: yes Virtual Machine: no OpenGL 2 Shaders are used Painting blocks for vertical retrace: no Loaded Effects: --------------- zoom dimscreen slidingpopups kwin4_effect_login wobblywindows screenshot minimizeanimation kwin4_effect_scalein glide kwin4_effect_translucency desktopgrid kwin4_effect_windowaperture cubeslide cube sheet kwin4_effect_fade kwin4_effect_maximize presentwindows highlightwindow kwin4_effect_dialogparent blur contrast logout dashboard startupfeedback screenedge kscreen Currently Active Effects: ------------------------- blur contrast Effect Settings: ---------------- zoom: zoomFactor: 1.2 mousePointer: 0 mouseTracking: 0 enableFocusTracking: false followFocus: true focusDelay: 350 moveFactor: 20 targetZoom: 1 dimscreen: slidingpopups: fadeInTime: 150 fadeOutTime: 250 kwin4_effect_login: wobblywindows: stiffness: 0.03 drag: 0.92 moveFactor: 0.2 xTesselation: 20 yTesselation: 20 minVelocity: 0 maxVelocity: 1000 stopVelocity: 0.5 minAcceleration: 0 maxAcceleration: 1000 stopAcceleration: 0.5 moveEffectEnabled: true openEffectEnabled: false closeEffectEnabled: false moveWobble: true resizeWobble: true screenshot: minimizeanimation: kwin4_effect_scalein: glide: duration: 350 effect: 0 angle: -90 kwin4_effect_translucency: desktopgrid: zoomDuration: 300 border: 10 desktopNameAlignment: 0 layoutMode: 0 customLayoutRows: 2 usePresentWindows: true kwin4_effect_windowaperture: cubeslide: rotationDuration: 200 dontSlidePanels: false dontSlideStickyWindows: false usePagerLayout: true useWindowMoving: false cube: cubeOpacity: 0.699999988079071 opacityDesktopOnly: false displayDesktopName: true reflection: true rotationDuration: 200 backgroundColor: #000000 capColor: #eff0f1 paintCaps: true closeOnMouseRelease: true zPosition: 2271 useForTabBox: true invertKeys: false invertMouse: false capDeformationFactor: 0.0399999991059303 useZOrdering: false texturedCaps: true sheet: duration: 500 kwin4_effect_fade: kwin4_effect_maximize: presentwindows: layoutMode: 0 showCaptions: true showIcons: true doNotCloseWindows: false ignoreMinimized: false accuracy: 20 fillGaps: true fadeDuration: 150 showPanel: false leftButtonWindow: 1 rightButtonWindow: 2 middleButtonWindow: 0 leftButtonDesktop: 2 middleButtonDesktop: 0 rightButtonDesktop: 0 highlightwindow: kwin4_effect_dialogparent: blur: blurRadius: 13 cacheTexture: true contrast: logout: useBlur: true dashboard: brightness: 0.5 saturation: 0.5 blur: false startupfeedback: type: 1 screenedge: kscreen:
Created attachment 92633 [details] p just after the titlebar loses focus
What I mostly wanted to see was whether there would be any other windows on screen. The focus should not magically disappear when you hover some application item, at least not from KWins side. => I would assume the the application in question maps a managed window as tooltip for the element, maybe from the taskbar?
I can mouseover parts of the fullscreen window that popup extra information without the window losing focus. So mouse hover over the reload button in a browser and then the reload current page popup comes up and the window doesn't lose focus. It seems to reliably happen when mousing over horizontally across the part of the window that has file, edit, view, or right below that. It happens mostly in that general area.
Does this happen with non Qt/KDE windows, eg. gimp or inkscape as well? Does it happen with eg. the windows style? dolphin --style windows (yes it's ugly ;-)
It happens in ugly dolphin and inkscape. Gimp maximized has the titlebar and file, edit column offscreen because it maximizes to big/incorrectly, so I don't know about gimp.
It also happens when the windows are not maximized. I just figured this out. I have to be moving the mouse around the top center of the screen, not even close to the open windows, and the titlebar turns white as if the window just lost focus.
That sounds as if there's some window which takes focus on hover (what does not match your focus policy settings, though, so it's unlikely done by KWin) => run xprop > freaky.props; xwininfo -all > freaky.info and when the cursor turns into a '+' (twice) click the region where the focus loss would be triggered (also watch out whether the focus loss occurs while the cursor has a '+' shape, since no crossing events should be received during that time, ie. whatever takes the focus would poll the mouse position) The attach the freaky.* files to the bug.
ping?
$ xprop > freaky.props; xwininfo -all > freaky.info xwininfo: command not found It happens when I am running steam in wine. Even if it is on a different desktop.
You'll have to a) attach "freaky.props" to the bug (it doesn't help on your HDD ;-) b) install xwininfo (in order to obtain that information)
Created attachment 93248 [details] p
Created attachment 93249 [details] prop
That's a konsole window, left edge, 62px way from the top edge, 957px wide and 476px high. If that matches the window you saw, there's nothing in the window stack (at that position) that would take/move focus on crossing events. Another thing: > Gimp maximized has the titlebar and file, edit column offscreen because it maximizes to big/incorrectly That's a bit weird as well - for a wild guess, please also attach the output of "xrandr -q"
The window that takes my focus was on another desktop. The window that lost focus was konsole. You said to click the region where the focus loss happens, so I tried to click right as the konsole lost focus. $ xrandr -q Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 16384 x 16384 DVI-I-0 disconnected primary (normal left inverted right x axis y axis) DVI-I-1 disconnected (normal left inverted right x axis y axis) HDMI-0 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 597mm x 336mm 1920x1080 60.00*+ 59.94 50.00 60.05 60.00 50.04 1680x1050 59.95 1600x1200 60.00 1440x900 59.89 1400x1050 59.98 1280x1024 75.02 60.02 1280x960 60.00 1280x720 60.00 59.94 50.00 1152x864 75.00 1024x768 75.03 70.07 60.00 800x600 75.00 72.19 60.32 56.25 720x576 50.00 50.08 720x480 59.94 60.05 640x480 75.00 72.81 59.94 59.93 DVI-D-0 disconnected (normal left inverted right x axis y axis)
(In reply to illumilore from comment #16) > You said to click the region where the focus loss happens, so I tried to click right as the > konsole lost focus. Afaiu, the focus shift occurs when you move the cursor to a certain screen region (even if the focus holding window isn't there) I want to know what is at that region, not which window lost the focus. > The window that takes my focus was on another desktop. Woahoooo, wait: the focus goes to a window on another virtual desktop? Does the virtual desktop change as well? Is that window something random or is it always the same? (xrandr is dead end)
The loss of focus happens when wine is open with steam, and on another virtual desktop. Wine has emulate a virtual desktop, and that virtual desktop is fullscreen (takes up everything and hides the taskbar so while on that desktop, all I see is blue with steams window, even though I don't have any kwin window rules for it, kwin just seems to do that with 1080 size windows). Within wines virtual desktop is steam. "Does the virtual desktop change as well?" No, I stay on the same desktop. "Is that window something random or is it always the same?" I have only seen it occur with wined steam.
(In reply to illumilore from comment #18) > kwin just seems to do that with 1080 size windows There's a hidden key to turn "full screen size" windows fullscreen (because there was no NETWM hint for it ~2 decades ago ;-) but it's disabled by default. However, clients can set themselve fullscreen or force any geometry (minimum size) as they want. > No, I stay on the same desktop. KWin does not pass focus to windows on other VDs (w/o switching the latter) and would not (easily) allow such switch either, however: how do you determine the window has the focus? (*before* switching the VD, because afterwards, the "first" client on that desktop will be activated) Asking, because this post https://forum.kde.org/viewtopic.php?f=111&t=126940 suggests that actually steam just grabs the pointer (what would fit your "if i move the pointer somewhere, something happens and steam apparently has the focus" description) Please the the xdotool instructions in the linked post to check whether that's correct (at the time when the focus is lost) You may also want to try to set the focus stealing prevention level (kcmshell5 kwinoptions) rep. only for steam (kcmshell5 kwinrules) to "none" to see whether steam then als successfully activates the window.
What is KWin 3D mode? Anyway, is this still an issue?
.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!