A user on the Java Plug-In forum has indicated that IE 7 can lock up when the new Java Plug-In is running JOGL applets and certain user interface gestures are performed. Initial investigation did not turn up anything obvious. It is unclear whether the bug is in the Java Plug-In, the message processing in the AWT, the browser itself, or somewhere else. It is unclear whether there is a fix or workaround that can be introduced for example in the Java Plug-In.

The forum thread on which the issue was posted is

http://forums.java.net/jive/thread.jspa?threadID=38256&tstart=0
I was able to provoke this failure (right mouse button menu inducing livelock == 100% CPU consumption in the IE process) with the simplest Clock example applet from the Sun web site, so the deeper issue is unrelated to JOGL. At this point it is still unclear whether the bug is in IE, the new plug-in, or the AWT. The following stack trace was captured from the main thread of the IE process using the Visual Studio debugger while the livelock was occurring.

ntdll.dll!7c90eb94()
  user32.dll!7e418b8c()
  mshtml.dll!438aff02()
  mshtml.dll!4364d96e()
  mshtml.dll!43778e8e()
  ieframe.dll!42f9ee5c()
  user32.dll!7e418b26()
  user32.dll!7e4188d1()
  user32.dll!7e4188da()
  mshtml.dll!4368e1a7()
  user32.dll!7e418734()
  user32.dll!7e418816()
  user32.dll!7e41f84a()
  user32.dll!7e41b4c0()
  user32.dll!7e41f805()
  user32.dll!7e41b50c()
  ntdll.dll!7c90eae3()
  user32.dll!7e46cd34()
  user32.dll!7e465109()
  ieframe.dll!4305a552()
  mshtml.dll!4374d741()
  mshtml.dll!43654a89()
  ieframe.dll!4304663e()
  mshtml.dll!437ff69b()
  mshtml.dll!437e410a()
  mshtml.dll!437e40b3()

It is apparent from the module names that no code associated with the new plug-in is running on the stack of the browser's main thread, which in my opinion basically exonerates the new plug-in as the cause of the problem. The only problems we have seen in this area with the new plug-in have been related to causing Java modal dialogs to block the browser window.

Unfortunately a stack trace from the AWT toolkit thread in the attached JVM was not captured at the time the lockup occurred. Freezing the IE process for as long as was done caused the attached JVM to exit thinking the browser had exited. A stack trace will be captured if possible to see whether the AWT toolkit thread is busy at the time the livelock occurs.

Note that killing the attached Java process did not cause the IE process to recover. This in my opinion even more strongly indicates a bug in IE since one would expect that if it were busy looping waiting for something like a focus transfer to happen to a window in another process, then if that other process was killed then the IE process should recover.