Bug ID: JDK-6737888 PopupMenu behavior has changed in 6u10

JDK-6737888 : PopupMenu behavior has changed in 6u10

Type: Bug
Component: client-libs
Sub-Component: javax.swing
Affected Version: 6

Priority: P2
Status: Closed
Resolution: Duplicate
OS: generic
CPU: generic

Submitted: 2008-08-15
Updated: 2011-01-19
Resolved: 2009-06-25

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 6
6-poolResolved

Related Reports

Duplicate :	JDK-6770445 - Unable to transfer focus with single click when the combobox popup is visible
Relates :	JDK-6646781 - Nimbus L&F : Menu stays open when continously clicked on internal frame icon on Windows & nimbus L&F

Description

While testing NetBeans 6.5 UML plugin with the following scenario, the diagram window was frozen with no response. Once the diagram is frozen, it has to be closed and reopened before it can be used again.

- create a diagram of any type
- drop an element on the diagram
- select the element so that the context palette appears
- right click on the selected element so the context menu is opened
- now, while the context menu is still opened, try to create something (eg, an edge) from the context palette
- now the diagram is frozen. clicking anywhere in the diagram does not help until selecting an element on the modeling palette. Esc will only dismiss the context palette but diagram is still frozen.
This problem only occurred when using JDK 1.6.0_10 RC.
Here is the stack trace from the submitter:

2008-08-19 23:30:11
Full thread dump Java HotSpot(TM) Client VM (11.0-b13 mixed mode, sharing):

"Inactive RequestProcessor thread [Was:Default RequestProcessor/org.openide.expl
orer.propertysheet.PropertySheet$3]" daemon prio=2 tid=0x2e619400 nid=0x1f98 in
Object.wait() [0x2d3ff000..0x2d3ffa80]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x093cd0e0> (a java.lang.Object)
        at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:950)
        - locked <0x093cd0e0> (a java.lang.Object)

"GSF Source Worker Thread" prio=6 tid=0x2e61e400 nid=0x10e4 waiting on condition
 [0x32f2f000..0x32f2fa00]
   java.lang.Thread.State: TIMED_WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
^       - parking to wait for  <0x08622ff0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
C       at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:198)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:1963)
        at java.util.concurrent.PriorityBlockingQueue.poll(PriorityBlockingQueue.java:245)
        at org.netbeans.napi.gsfret.source.Source$CompilationJob.run(Source.java:1290)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)

        at java.lang.Thread.run(Thread.java:619)

"org.netbeans.modules.gsfret.source.usages.RepositoryUpdater" C:\Users\peter\met
eora\NetBeans-dev-080819\netbeans\bin>prio=6 tid=0x2e61e000 nid=0x118c in Object.wait() [0x32d2f000..0x32d2fb00]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x08621190> (a java.util.TaskQueue)
        at java.lang.Object.wait(Object.java:485)
        at java.util.TimerThread.mainLoop(Timer.java:483)
        - locked <0x08621190> (a java.util.TaskQueue)
        at java.util.TimerThread.run(Timer.java:462)

"Java Source Worker Thread" prio=6 tid=0x2e61dc00 nid=0x1d78 waiting on condition [0x2dbcf000..0x2dbcfa80]
   java.lang.Thread.State: TIMED_WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x085c5e18> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
        at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:198)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:1963)
        at java.util.concurrent.PriorityBlockingQueue.poll(PriorityBlockingQueue.java:245)
        at org.netbeans.api.java.source.JavaSource$CompilationJob.run(JavaSource.java:1553)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)

"DestroyJavaVM" prio=6 tid=0x2e61ac00 nid=0x15b0 waiting on condition [0x00000000..0x0165fd38]
   java.lang.Thread.State: RUNNABLE

"AWT-EventQueue-1" prio=6 tid=0x2e61a000 nid=0x1050 in Object.wait() [0x3248f000..0x3248fa80]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x07da6250> (a org.netbeans.core.TimableEventQueue)
        at java.lang.Object.wait(Object.java:485)
        at java.awt.EventQueue.getNextEvent(EventQueue.java:479)
        - locked <0x07da6250> (a org.netbeans.core.TimableEventQueue)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:236)
        at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
"TimerQueue" daemon prio=6 tid=0x2e619c00 nid=0x1490 in Object.wait() [0x3041f000..0x3041fb00]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x07da6328> (a javax.swing.TimerQueue)
        at javax.swing.TimerQueue.run(TimerQueue.java:236)
        - locked <0x07da6328> (a javax.swing.TimerQueue)
        at java.lang.Thread.run(Thread.java:619)

"Inactive RequestProcessor thread [Was:Refresh-After-WindowActivated/org.netbeans.core.ui.warmup.MenuWarmUpTask$NbWindowsAdapter]" daemon prio=2 tid=0x2e619000
nid=0x1404 in Object.wait() [0x3117f000..0x3117fc80]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x07d72f58> (a java.lang.Object)
        at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:950)
        - locked <0x07d72f58> (a java.lang.Object)

"*** JFluid Separate Command Execution Thread" daemon prio=6 tid=0x2e618400 nid=0x1b0c in Object.wait() [0x30d7f000..0x30d7fd00]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x07d6d208> (a java.lang.Object)
        at java.lang.Object.wait(Object.java:485)
        at org.netbeans.lib.profiler.ProfilerClient$SeparateCmdExecutionThread.run(ProfilerClient.java:101)
        - locked <0x07d6d208> (a java.lang.Object)

"Thread-4" daemon prio=6 tid=0x2e617c00 nid=0x1e80 in Object.wait() [0x31a8f000..0x31a8fd80]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x07c9a4c8> (a java.util.LinkedList)
        at java.lang.Object.wait(Object.java:485)
        at java.util.prefs.AbstractPreferences$EventDispatchThread.run(AbstractPreferences.java:1461)
        - locked <0x07c9a4c8> (a java.util.LinkedList)

"AWT-Windows" daemon prio=6 tid=0x2e30b800 nid=0x220 runnable [0x2ee9f000..0x2ee9fb80]
   java.lang.Thread.State: RUNNABLE
        at sun.awt.windows.WToolkit.eventLoop(Native Method)
        at sun.awt.windows.WToolkit.run(WToolkit.java:291)
        at java.lang.Thread.run(Thread.java:619)

"AWT-Shutdown" prio=6 tid=0x2e30b400 nid=0x2e8 in Object.wait() [0x2ec9f000..0x2ec9fc00]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x071a6108> (a java.lang.Object)
        at java.lang.Object.wait(Object.java:485)
        at sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:259)
        - locked <0x071a6108> (a java.lang.Object)
        at java.lang.Thread.run(Thread.java:619)

"Java2D Disposer" daemon prio=10 tid=0x2e304400 nid=0x1278 in Object.wait() [0x2ea9f000..0x2ea9fc80]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x071c59f8> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
        - locked <0x071c59f8> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)
        at sun.java2d.Disposer.run(Disposer.java:125)
        at java.lang.Thread.run(Thread.java:619)

"Active Reference Queue Daemon" daemon prio=2 tid=0x04601c00 nid=0x1c8c in Object.wait() [0x2e2ff000..0x2e2ffd00]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x0718dfc8> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
        - locked <0x0718dfc8> (a java.lang.ref.ReferenceQueue$Lock)
        at org.openide.util.Utilities$ActiveQueue.run(Utilities.java:3076)
        at java.lang.Thread.run(Thread.java:619)

"Timer-0" daemon prio=6 tid=0x04630800 nid=0x1fb0 in Object.wait() [0x04dff000..0x04dffa80]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x071a62c0> (a java.util.TaskQueue)
        at java.util.TimerThread.mainLoop(Timer.java:509)
        - locked <0x071a62c0> (a java.util.TaskQueue)
        at java.util.TimerThread.run(Timer.java:462)

"CLI Requests Server" daemon prio=6 tid=0x0138e000 nid=0x19e0 runnable [0x04bff000..0x04bffb00]
   java.lang.Thread.State: RUNNABLE
        at java.net.PlainSocketImpl.socketAccept(Native Method)
        at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
        - locked <0x071a6398> (a java.net.SocksSocketImpl)
        at java.net.ServerSocket.implAccept(ServerSocket.java:453)
        at java.net.ServerSocket.accept(ServerSocket.java:421)
        at org.netbeans.CLIHandler$Server.run(CLIHandler.java:1002)

"Low Memory Detector" daemon prio=6 tid=0x01341c00 nid=0x1854 runnable [0x00000000..0x00000000]
   java.lang.Thread.State: RUNNABLE

"CompilerThread0" daemon prio=10 tid=0x0133d800 nid=0x1244 waiting on condition
[0x00000000..0x0405f9a8]
   java.lang.Thread.State: RUNNABLE

"Attach Listener" daemon prio=10 tid=0x0133c800 nid=0x70c runnable [0x00000000..0x00000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" daemon prio=10 tid=0x01331c00 nid=0x1814 waiting on condition [0x00000000..0x00000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" daemon prio=8 tid=0x0132a400 nid=0x778 in Object.wait() [0x03c0f000..0x03c0fa80]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x0718e258> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
        - locked <0x0718e258> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)

"Reference Handler" daemon prio=10 tid=0x01325c00 nid=0x1cb4 in Object.wait() [0x03a0f000..0x03a0fb00]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x0718dff0> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:485)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
        - locked <0x0718dff0> (a java.lang.ref.Reference$Lock)

"VM Thread" prio=10 tid=0x01324400 nid=0x1d64 runnable

"VM Periodic Task Thread" prio=10 tid=0x0134c000 nid=0x1a70 waiting on condition


JNI global references: 2277

Heap def new generation   total 4864K, used 2577K [0x05200000, 0x05740000, 0x07180000)
  eden space 4352K,  58% used [0x05200000, 0x0547c998, 0x05640000)
  from space 512K,  23% used [0x056c0000, 0x056de720, 0x05740000)
  to   space 512K,   0% used [0x05640000, 0x05640000, 0x056c0000)
 tenured generation   total 63524K, used 38460K [0x07180000, 0x0af89000, 0x1ec00000)
   the space 63524K,  60% used [0x07180000, 0x0970f290, 0x0970f400, 0x0af89000)
 compacting perm gen  total 41216K, used 40970K [0x1ec00000, 0x21440000, 0x2b400000)
   the space 41216K,  99% used [0x1ec00000, 0x21402aa0, 0x21402c00, 0x21440000)
    ro space 8192K,  67% used [0x2b400000, 0x2b962a18, 0x2b962c00, 0x2bc00000)
    rw space 12288K,  53% used [0x2bc00000, 0x2c26fd60, 0x2c26fe00, 0x2c800000)
Copied from comments section:
==============================

By default (ie. default installation, in particular no look and feel changes/tweaks, etc...) in jdk1.6.0_10 closing of PopupMenu consumes MOUSE_PRESSED, whereis it 
isn't in the jdks before (at least in JDKs 1.5.0_10, 1.6.0_04). 
According to Java API sources bundled with jdk ditsribution 
the behaviour is controlled by the following lines in 

javax.swing.plaf.basic.BasicPopupMenuUI$MouseGrabber.eventDispatched() :

...
                    boolean consumeEvent =
                        UIManager.getBoolean("PopupMenu.consumeEventOnClose");
                    // Consume the event so that normal processing stops.
                    if(consumeEvent && !(src instanceof MenuElement)) {
                        me.consume();
                    }
...

specifically - UIManager.getBoolean("PopupMenu.consumeEventOnClose") started to 
return "true" in jdk1.6.0_10.

That results in that with jdk1.6.0_10 UML element's palette 
PaletteButton doesn't receive MOUSE_PRESSED before receiving 
corresponding MOUSE_RELEASED. 

To workaround the situation i put an additional check. It will 
allow to avoid "frozing" of the diagram. Though it will still not allow 
for the behaviour we have with other jdks - ie. successfull creation 
of the edge on the MOUSE_RELEASED that comes right after MOUSE_PRESSED 
that dismissed the popup menu.

Comments

EVALUATION The "PopupMenu.consumeEventOnClose" value was intentionally changed for WindowsLookAndFeel in 6u10 to emulate the Windows system behaviour, thus this is a bug fix and not a regression. As a workaround you can manually change this value to false UIManager.put("PopupMenu.consumeEventOnClose", Boolean.FALSE); but keep in mind that this value is depending on current LaF and it is better not to change it
25-06-2009
EVALUATION Looks like Netbeans team incorrectly works with Swing from multiple threads and that leads to the deadlock However they complained to the change of the PopupMenu.consumeEventOnClose' value which was introduced by the recent fix
04-09-2008
EVALUATION This is a regression of the fix for 6646781
04-09-2008
EVALUATION Looking to stack trace i do not see any deadlocks and i do not see anything bad happening on java client side. There are several threads in the WAIT state but they all seems to be doing something Netbeans specific. Most notably: "AWT-EventQueue-1" prio=6 tid=0x2e61a000 nid=0x1050 in Object.wait() [0x3248f000..0x3248fa80] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x07da6250> (a org.netbeans.core.TimableEventQueue) at java.lang.Object.wait(Object.java:485) at java.awt.EventQueue.getNextEvent(EventQueue.java:479) - locked <0x07da6250> (a org.netbeans.core.TimableEventQueue) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:236) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161) at java.awt.EventDispatchThread.run(EventDispatchThread.java:122) "TimerQueue" daemon prio=6 tid=0x2e619c00 nid=0x1490 in Object.wait() [0x3041f000..0x3041fb00] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x07da6328> (a javax.swing.TimerQueue) at javax.swing.TimerQueue.run(TimerQueue.java:236) - locked <0x07da6328> (a javax.swing.TimerQueue) at java.lang.Thread.run(Thread.java:619) Something that is executed on AWT event dispatch thread is waiting for event on org.netbeans.core.TimableEventQueue. I do not know why it does not get one. But this explains why UI is frozen - due to blocked dispatch thread. Note that the reason of blocking seems to be Netbeans related. The question remains why this was not reproducible with previous build of JDK. I have no answer for this but this could be some timing issue or some other bug. I am closing this as not a JDK bug for now. Please reopen if you will get more info proving that this problem is caused by bug in JDK.
20-08-2008
EVALUATION It sounds like there is a deadlock in the code and it is unlikely that this happens in 2D code. Please provide more detailed description of the problem. Please see client troubleshooting guide for troubleshooting hints for client stack http://java.sun.com/javase/6/webnotes/trouble/TSG-Desktop/html/gceyf.html and VM http://java.sun.com/javase/6/webnotes/trouble/TSG-VM/html/index.html In particular, please identify the reason of hang and provide stacktrace dumps. Here is instructions on how to troubleshoot this http://java.sun.com/javase/6/webnotes/trouble/TSG-VM/html/hangloop.html
19-08-2008