Bug 317025 - Java Swing Apps do not receive Deiconify event if window is shaded
Summary: Java Swing Apps do not receive Deiconify event if window is shaded
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: compatibility (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: NOR normal
Target Milestone: 4.11
Assignee: KWin default assignee
URL: https://git.reviewboard.kde.org/r/109...
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-19 12:01 UTC by Mike Chou
Modified: 2013-03-21 17:54 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In: 4.11
Sentry Crash Report:
thomas.luebking: ReviewRequest+


Attachments
The sample Iconify java Swing application (3.12 KB, application/octet-stream)
2013-03-19 12:04 UTC, Mike Chou
Details
Compiled Iconify sample application (796 bytes, application/octet-stream)
2013-03-19 17:08 UTC, Mike Chou
Details
Compiled Iconify sample application (1.47 KB, application/octet-stream)
2013-03-19 17:09 UTC, Mike Chou
Details
Compiled Iconify sample application (423 bytes, application/octet-stream)
2013-03-19 17:09 UTC, Mike Chou
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Chou 2013-03-19 12:01:47 UTC
When a Java Swing application is shaded first and then minimized, Java does not receive a De-iconify event upon un-minimization of the Swing application. The Swing application then fails to render properly when subsequently un-shaded because it does not think it has been de-iconified yet.

To demonstrate this, we ran the attached sample code (Iconify.java) which simply outputs the events received by Swing. 





Reproducible: Always

Steps to Reproduce:
1. Compile the attached java Swing application (Iconify.java)
2. Run the application
3. Shade the application
4. Minimize the application
5. Un-minimize the application
6. Un-shade the application
Actual Results:  
The Iconify application outputs the following to standard out:

Window Opened Event
Window Activated Event
Window Deactivated Event
Window Iconified Event
Window Activated Event


Expected Results:  
The Iconify application should output the following to standard out:

Window Opened Event
Window Activated Event
Window Deactivated Event
Window Iconified Event
Window Deiconified Event <--- This is the missing event !
Window Activated Event


Same thing can be observed when switching desktops. When a Java Swing application is shaded first and a desktop switch is performed, the Swing application receives an Iconification event. But when we switch back to the original desktop, no deiconification event is received.
Comment 1 Mike Chou 2013-03-19 12:04:05 UTC
Created attachment 78203 [details]
The sample Iconify java Swing application
Comment 2 Martin Flöser 2013-03-19 12:07:55 UTC
with which KWin version have you tested? With which Java version? How does it behave on other window managers, e.g. Compiz or Mutter?
Comment 3 Thomas Lübking 2013-03-19 13:54:18 UTC
void Client::map(allowed_t)
{
 ....
    if (!isShade()) {
....
        exportMappingState(NormalState);
    } else
        exportMappingState(IconicState);
}

altering the shade state does not export the mapping state so everything relying on the clientmessage rather than the WM_STATE will not get the change.

@Mike
Can you compile a patch? ("because otherwise i'd have to install java...")
Comment 4 Mike Chou 2013-03-19 17:08:27 UTC
Created attachment 78209 [details]
Compiled Iconify sample application
Comment 5 Mike Chou 2013-03-19 17:09:26 UTC
Created attachment 78210 [details]
Compiled Iconify sample application
Comment 6 Mike Chou 2013-03-19 17:09:46 UTC
Created attachment 78212 [details]
Compiled Iconify sample application
Comment 7 Mike Chou 2013-03-19 17:12:59 UTC
Hi there,

Thanks for the reply. Forgive my ignorance but I'm not too sure what you meant by patch, but I have attached the compiled java application for you (compiled using JDK 1.6.0_18). Just download the 3 files and run "java Iconify". Please let me know if you meant something else and I will upload it.

We have tested this issue with:

* KWIN 4.8.5 
* KWIN 4.9.5

On KWIN 4.8.5 we tested with and was able to reproduce the issue with:
- Java Hotspot VM 1.6.0_20
- Java Hotspot VM 1.7.0_17
- OpenJDK VM 1.7.0_15

On KWIN 4.9.5 we were also able to reproduce the issue. I will need to verify which java version was used.

We have tried other window managers with similar shade functionality (ie: openbox) and they did not seem to have the problem. I will get the output of the Iconify Sample program for you on those other window managers.
Comment 8 Mike Chou 2013-03-19 18:59:22 UTC
As a test we ran the Iconify sample application on KWIN 3.0 with Java HotSpot JVM 1.6.0_34 and it does NOT seem to have the issue. The sample application receives the appropriate De-iconify event based on its output.

Seems in KWIN 3.0 the Iconified/Deiconified events are received when I shade/unshade the Swing application, as opposed to KWIN 4.8.5 where the Activated/Deactivated events are received when I shade/unshade the Swing application.
Comment 9 Thomas Lübking 2013-03-19 19:34:36 UTC
I mean like "compile a patched version of kwin" and take your reply as "no".
(compiling a java class is just about within my skills ;-)

Gonna install OpenJDK and check whether the patch works.
Comment 10 Mike Chou 2013-03-19 20:04:51 UTC
That's good to hear, because patching kwin is well out of my skill level ;-)
Comment 11 Mike Chou 2013-03-20 14:18:05 UTC
Quick addendum to our note above regarding what KWIN versions/Java versions we tested:

- We were able to reproduce the issue on KWIN 4.9.5 with Java HotSpot JVM 1.7.0_17
- We also tested the metacity window manager and could not reproduce the issue.
Comment 12 Thomas Lübking 2013-03-20 15:02:24 UTC
There's a fixing patch in the linked RR - also the current kwin behavior is inconsistent, so there's some bug for sure.
Comment 13 Thomas Lübking 2013-03-20 21:24:37 UTC
Git commit 607031cb4daec85082d35699214d2f9ae2ab386d by Thomas Lübking.
Committed on 19/03/2013 at 22:00.
Pushed by luebking into branch 'master'.

set / withdraw iconic state for shaded clients

Should shaded windows be iconic?
I don't know. Apparently nobody does. (google found me discussions but no conclusion)

OpenBox, Metacity and Compiz set shaded Windows iconic, Sawfish and IceWM don't.

Either way kwin presently sets shaded windows iconic when you map them (client.cpp, void Client::map(allowed_t)) so to remain consistent with ourselves and half of the other WMs i set it.
Otherwise it should not be set when unshading a window
(no justification but noteworthy: the bug reporter seems to intend to pause expensive painting when the window is iconic and in that regard it's oc better to have it for shaded windows)
FIXED-IN: 4.11
REVIEW: 109593

M  +2    -0    kwin/client.cpp

http://commits.kde.org/kde-workspace/607031cb4daec85082d35699214d2f9ae2ab386d
Comment 14 Mike Chou 2013-03-21 14:05:45 UTC
Thanks Thomas for all your help.
Comment 15 Thomas Lübking 2013-03-21 17:54:31 UTC
Well, thanks for pointing this issue out.

Aside that: bugs only exist to die, so there's no need to be extra thankful for that ;-)