Bug 317502 - Sometimes triggering a fullscreen declarative script the dialog is not appearing
Summary: Sometimes triggering a fullscreen declarative script the dialog is not appearing
Status: RESOLVED WORKSFORME
Alias: None
Product: kwin
Classification: Plasma
Component: scripting (other bugs)
Version First Reported In: git master
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-28 17:41 UTC by Michail Vourlakos
Modified: 2021-12-07 04:36 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michail Vourlakos 2013-03-28 17:41:23 UTC
I have observed that sometimes triggering a fullscreen declarative script the dialog is not appearing at all. The focus is lost from the Desktop and it is in the Dialog but the Dialog is not appearing. No special error messages are appearing from kwin --replace.

I can understand that the dialog is called but not shown because in the Dialog I have set ESC to hide it. So in order for the Desktop to regain focus and responsiveness I have to press ESC. 

It happes also sometimes in 4.10.x...

Reproducible: Sometimes

Steps to Reproduce:
Unfortunately, I havent found a way to reproduce it
Actual Results:  
The PlasmaCore.Dialog in the KWin script is not shown even though it is triggered.

Expected Results:  
The PlasmaCore.Dialog in the KWin script should be shown
Comment 1 Thomas Lübking 2013-03-28 18:57:13 UTC
The dialog is override_redirect (bypass windowmanager hint) so kwin just ignores it.

Not invalid though, since it's an OR from the kwin process.
Are you sure it's not shown? (Determine the WId eg. with xwininfo)

When it fails, move to VT1 and use "xwininfo -id <WId> | grep -i map"
If it doesn't print "Map State: IsViewable", the window is really not shown (and not just unstacked) what means that Qt didn't map it - for what reason ever*.

Otherwise this may be a stacking or compositing issue.

*Just to be sure: you're no more calling KWindowSystem::self() in any way, do you? ;-)
Comment 2 Michail Vourlakos 2013-03-28 19:59:11 UTC
(In reply to comment #1)
> The dialog is override_redirect (bypass windowmanager hint) so kwin just
> ignores it.
> 
> Not invalid though, since it's an OR from the kwin process.
> Are you sure it's not shown? (Determine the WId eg. with xwininfo)
> 
> When it fails, move to VT1 and use "xwininfo -id <WId> | grep -i map"
> If it doesn't print "Map State: IsViewable", the window is really not shown
> (and not just unstacked) what means that Qt didn't map it - for what reason
> ever*.
unfortunately for xwininfo I get...
xwininfo: error: Can't grab the mouse. // but I can find the Wid from inside the script

one more info when it fails, I can not use any application and I have to press ESC which is going to restore probably the window state by telling it to really hide...

> 
> Otherwise this may be a stacking or compositing issue.
> 
> *Just to be sure: you're no more calling KWindowSystem::self() in any way,
> do you? ;-)
Hmmm, for signals definitely I have disabled them but there is a chance to have let some calls inside the plugins... I will disable all this plugins and create scripting only alternatives for the kwin script....

Thomas please give some days because some work caught me up...
Comment 3 Thomas Lübking 2013-03-28 20:26:00 UTC
(In reply to comment #2)

> one more info when it fails, I can not use any application
sounds like the mouse is grabbed, meaning the window is mapped (or you X11 fundamentally broken)
-> ever happened w/o active compositor?

> > Otherwise this may be a stacking or compositing issue.
This.

> Thomas please give some days because some work caught me up...
Take your time, it's your project after all ;-)
Comment 4 Andrew Crouthamel 2018-11-10 03:16:47 UTC
Dear Bug Submitter,

This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond.

Thank you for helping us make KDE software even better for everyone!
Comment 5 Andrew Crouthamel 2018-11-20 04:04:26 UTC
Dear Bug Submitter,

This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand.

Thank you for helping us make KDE software even better for everyone!
Comment 6 kde.org 2021-11-07 00:42:04 UTC
This issue report is quite old. Can you please confirm, that it still persists with Plasma 5.23?
Comment 7 Bug Janitor Service 2021-11-22 04:38:37 UTC
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!
Comment 8 Bug Janitor Service 2021-12-07 04:36:17 UTC
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!