Bug 181

Summary: Modal dialogs vanish when using JOGL 1.1.1, Java 1.5, and OS X 10.4.3
Product: [JogAmp] Jogl Reporter: Sven Gothel <sgothel>
Component: coreAssignee: Sven Gothel <sgothel>
Status: VERIFIED FIXED    
Severity: normal    
Priority: P3    
Version: 1   
Hardware: All   
OS: macosx   
Type: DEFECT SCM Refs:
Workaround: ---
Attachments: Test case program
updated test case

Description Sven Gothel 2010-03-24 07:48:08 CET


---- Reported by ianwdavis 2005-11-10 06:23:31 ----

Summary:
The combination of (1) OS X 10.4.3, (2) the latest 1.5 developer release (build 1.5.0_05-72), and (3) 
JOGL 1.1.1 creates a problem where modal dialogs (such as Swing file choosers) pop up in front of 
other windows for a brief time, and then disappears behind all other windows. The time in front  ranges 
from ~1 sec to the briefest flicker, and the time shortens as program runs longer. This is extremely 
irritating and makes programs almost unusable.

This behavior occurs whenever a GLCanvas has been created (and shown?), at any point in the program 
execution. That is, if the GLCanvas is later removed from the interface and is no longer present on 
screen, modal dialogs will continue to pop behind all other windows.

Steps to reproduce:
1. Open any JOGL application using Java 1.5 and OS X 10.4.3.
2. Open e.g. a file chooser dialog.
3. Wait (up to 5 seconds).

Expected results:
The file chooser should stay on top of other windows.

Actual results:
The file chooser disappears to the back of the stack of windows. It can be recovered by right-clicking 
the Dock icon and re-selecting the dialog (which already has a check mark next to it).

Regression:
Yes, but which product is unclear. I upgraded JOGL, Java, and OS X all at about the same. I can verify 
that it works normally with 10.4.3, JOGL 1.1.1, and Java 1.4.2, so I'm filing this first as a Java bug, and 
second as a JOGL bug.

Notes:
This bug has also been filed with Apple. They never fix anything, though, so I'm hoping the JOGL team 
can solve it relatively quickly and easily.



---- Additional Comments From kbr 2005-11-10 08:57:49 ----

Could you please post a test program which reproduces this behavior?

The JOGL library does very few operations on windows overall, which makes it
difficult to understand which operation in particular could be causing this
change. Is it just the case that modal dialogs appear behind the GLCanvas, or do
they appear behind all windows? Have you tried specifying popups, etc. to be
heavyweight (see the section "Heavyweight and Lightweight Issues" in the JOGL
User's Guide)?

Does your application have any control once these dialogs are visible? Can you
try starting a background thread executing an
EventQueue.invokeLater(dialog.toFront()) or something similar?

I think you would be better served first trying to figure out a workaround in
your application, as that might inform whether a workaround in JOGL or somewhere
else is feasible.




---- Additional Comments From ianwdavis 2005-11-11 06:29:51 ----

Created an attachment
Test case program




---- Additional Comments From ianwdavis 2005-11-11 06:35:27 ----

I've now posted a test case, which is very simple but still demonstrates this behavior. I've also got two 
new observations:

- Since this code creates a new chooser every time, the delay before pop-behind is long. In fact, it stays 
visible until I move the mouse -- no mouse movement, the dialog stays in place.

- It doesn't actually pop *behind*, it just *disappears*.  I had too much clutter before to notice that.

kbr, my understanding was that *all* dialogs and windows are heavyweight (except InternalFrame and 
friends).  I did encounter a problem with lightweight popup menus before, and that was solved by 
making them heavy. This is something else, especially since we now know the dialog actually vanishes 
completely, even though it doesn't totally overlap the JOGL canvas.



---- Additional Comments From kbr 2005-12-06 18:41:26 ----

I can reproduce this problem with Java 1.5, the current JOGL source tree, and Mac OS X 10.4.3. It is clearly 
a bug in Apple's JDK because running the same test program with the same JOGL and 1.4.2 works 
properly. Off the top of my head I can't think of any code in JOGL which would have provoked this 
behavior. We interact with the AWT only minimally and don't do anything fancy like intercept events or 
anything similar.

I'll ask a colleague at Apple to look into this issue.




---- Additional Comments From kbr 2005-12-06 18:43:37 ----

BTW, a workaround appears to be to Alt-Tab to another application and then Alt-Tab back to the JOGL 
application.




---- Additional Comments From gziemski 2006-01-17 18:11:12 ----

This should be fixed in "J2SE 5.0 Release 4 Developer Preview 4" that was released today - see http://
connect.apple.com



---- Additional Comments From gziemski 2006-01-17 18:26:47 ----

Created an attachment
updated test case




---- Additional Comments From gziemski 2006-01-17 18:28:48 ----

Verified that the bug is fixed in "J2SE 5.0 Release 4 Developer Preview 4"

Refer to <http://connect.apple.com> for the update.



--- Bug imported by sgothel@jausoft.com 2010-03-24 07:48 EDT  ---

This bug was previously known as _bug_ 181 at https://jogl.dev.java.net/bugs/show_bug.cgi?id=181
Imported an attachment (id=65)
Imported an attachment (id=66)

The original submitter of attachment 65 [details] is unknown.
   Reassigning to the person who moved it here: sgothel@jausoft.com.
The original submitter of attachment 66 [details] is unknown.
   Reassigning to the person who moved it here: sgothel@jausoft.com.