Bug 343573

Does the window "reappear" when suspending the compositor? (SHIFT+Alt+F12)

Please attach the output of
   qdbus org.kde.KWin /KWin supportInformation

Yes, pressing Shift+Alt+F12 made the window visible again.

Below is the output of  qdbus org.kde.KWin /KWin supportInformation.

Any idea for solution/workaround?
___________________________________________________________________
$  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: 4.11.11
KDE SC version (runtime): 4.13.3
KDE SC version (compile): 4.13.2
Qt Version: 4.8.6

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
showDesktopIsMinimizeAll: false
rollOverDesktops: false
focusStealingPreventionLevel: 1
legacyFullscreenSupport: false
operationTitlebarDblClick: 
commandActiveTitlebar1: 0
commandActiveTitlebar2: 30
commandActiveTitlebar3: 2
commandInactiveTitlebar1: 4
commandInactiveTitlebar2: 30
commandInactiveTitlebar3: 2
commandWindow1: 7
commandWindow2: 8
commandWindow3: 8
commandWindowWheel: 31
commandAll1: 10
commandAll2: 3
commandAll3: 14
keyCmdAllModKey: 16777251
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: 2
colorCorrected: false
xrenderSmoothScale: false
maxFpsInterval: 16666666
refreshRate: 0
vBlankTime: 6000000
glDirect: true
glStrictBinding: false
glStrictBindingFollowsDriver: true
glLegacy: false
glCoreProfile: false
glPreferBufferSwap: 101

Screen Edges
============
desktopSwitching: false
desktopSwitchingMovingClients: false
cursorPushBackDistance: 
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:  no
Number of Screens: 1
Screen 0 Geometry: 0,0,1440x900

Decoration
==========
Current Plugin: kwin3_oxygen
Shadows: yes
Alpha: yes
Announces Alpha: yes
Tabbing: yes
Frame Overlap: no
Blur Behind: no

Compositing
===========
Qt Graphics System: native
Compositing is active
Compositing Type: OpenGL
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) 965GM 
OpenGL version string: 2.1 Mesa 10.1.3
OpenGL shading language version string: 1.20
Driver: Intel
GPU class: i965
OpenGL version: 2.1
GLSL version: 1.20
Mesa version: 10.1.3
X server version: 1.15.1
Linux kernel version: 3.13
Direct rendering: yes
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:
---------------
kwin4_effect_login
kwin4_effect_minimizeanimation
kwin4_effect_screenshot
kwin4_effect_desktopgrid
kwin4_effect_flipswitch
kwin4_effect_maximize
kwin4_effect_highlightwindow
kwin4_effect_taskbarthumbnail
kwin4_effect_dialogparent
kwin4_effect_presentwindows
kwin4_effect_logout
kwin4_effect_screenedge
kwin4_effect_startupfeedback
kwin4_effect_kscreen

Currently Active Effects:
-------------------------

Effect Settings:
----------------
kwin4_effect_login:

kwin4_effect_minimizeanimation:

kwin4_effect_screenshot:

kwin4_effect_desktopgrid:
zoomDuration: 300
border: 10
desktopNameAlignment: 0
layoutMode: 0
customLayoutRows: 2
usePresentWindows: true

kwin4_effect_flipswitch:
tabBox: false
tabBoxAlternative: false
duration: 200
angle: 30
xPosition: 0.330000013113022
yPosition: 1
windowTitle: true

kwin4_effect_maximize:

kwin4_effect_highlightwindow:

kwin4_effect_taskbarthumbnail:

kwin4_effect_dialogparent:

kwin4_effect_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
dragToClose: false

kwin4_effect_logout:
useBlur: true

kwin4_effect_screenedge:

kwin4_effect_startupfeedback:

kwin4_effect_kscreen:

Please note, my desktop effects are not switched on by default, i.e. on start up. So by pressing Alt+Shift+F12, I actually switched them on. Somehow, it also helped making the Chrome window visible.

Interesting.
Can you specify "invisible"?
Do you make use of the system titlebar (can be enabled in chromium settings)?
If so, are they "invisible" as well?

When the window becomes visible w/ enabling compositing, is it then responsive?

The window is completely invisible. Instead, one sees the windows that are in the place of / underneath that window, but cannot interact with them.

 I have system titlebar / window frame disabled in Chrome. I'd need to try and reproduce the behaviour with system titlebar enabled.

Yes, the window is responsive with switched on compositing.

There is also a bug report about this issue in the freedesktop bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88877

Actually it seems quite the opposite condition:

> Please note, my desktop effects are not switched on by default, i.e. on
> start up. So by pressing Alt+Shift+F12, I actually switched them on.
> Somehow, it also helped making the Chrome window visible.

Atm I suspect either a masking issue or chrome falsely unmaps (and the "keep hidden" feature in the cmpositor unmaps it)

We'll figure in detail once we know about the behavior w/ system titlebar :-)

I could easily reproduce this with "Use system title bar and borders" on (and compositing off).
The problem does not seem to affect the browser window as long as the compositing as on.

That's bad (for you ;-)

When you recause the missing chrome (chromium window), please call (in konsole)

    xwininfo -tree -root | grep -i chrom

What should print sth. like

     0x160004e "chromium": ("chromium" "Chromium")  200x200+0+0  +0+0
     0x1600015 "chromium": ("chromium" "Chromium")  200x200+0+0  +0+0
     0x1600003 "chromium": ("chromium" "Chromium")  200x200+0+0  +0+0
     0x1600001 "chromium": ("chromium" "Chromium")  10x10+10+10  +10+10
           0x3200001 "Speed Dial - Chromium": ("Chromium" "Chromium")  879x617+0+0  +91+122

The first entries are unrelated, obviously the "Speed Dial" entry is the actual window.
Next (the chrome window shall still be hidden), please call

   xwininfo -id 0x3200001 | tee chrome.info
   xwininfo -wm -id 0x3200001 | tee chrome.wminfo
   xprop -id 0x3200001 | tee chrome.props

And attach the three created files to the bug, so we can see the state of the window.

Created attachment 90852 [details]
output of xwininfo -id

Created attachment 90853 [details]
output of  xwininfo -wm -id

Created attachment 90854 [details]
output of xprop -id

Thanks.

>  Map State: IsUnMapped
> _NET_WM_STATE(ATOM) = 
> _KDE_NET_WM_ACTIVITIES(STRING) = "40b0fac1-61e1-43bc-a0f5-58fe71f06177"

The combination smells like that window is not on the current activity (though it should then rather not magically appear with starting the compositor either)

-> What's the output of

   qdbus org.kde.ActivityManager /ActivityManager/Activities CurrentActivity

In that situation?
Is it the same as the _KDE_NET_WM_ACTIVITIES value?

Does
   qdbus org.kde.ActivityManager /ActivityManager/Activities ListActivities

the output of this contain the _KDE_NET_WM_ACTIVITIES value?

(You should check all current values, _KDE_NET_WM_ACTIVITIES is in the xprop output, next time this happens)

Also: do you use the plasma-desktop feature to have individual wallpapers & widgets for every virtual desktop?

qdbus org.kde.ActivityManager /ActivityManager/Activities CurrentActivity gives the same value  as the _KDE_NET_WM_ACTIVITIES ?

Yes. I do use (four) individual desktop wallpapers (gradients).

I can still reproduce the bug with "Different widgets for each desktop" switched off.

Since it's also on the current activity, it's highly unlikely that this is related.

I suspect rather some chrome smartness to unmap windows to save VRAM - whenever it believes it's not required (eg. when the screen is covered by a fullscreen window like by the screenlocker)

See eg. http://code.google.com/p/chromium/issues/detail?id=185906 for such plan of insanity ;-)

I'd suggest to check whether this also happens w/ another WM, eg. install openbox (low dependecies) and run "openbox --replace &"

Then suspend/resume/unlock and see whether the chromium window is visible.
(Notably since openbox knows nothing about activities, it will just ignore that property)

Daniel I'm not able to reproduce this issue.

Can you please test and confirm if this issue is still occurring or if this bug report can be marked as resolved. I'm setting status to "needsinfo" pending your response, please change back to "resolved" or "reported" when you respond, thanks.

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!