31220 - Applet keeps running after leaving the page

Status: VERIFIED FIXED

(Core Graveyard :: Java: OJI, defect, P3)

Description

[edburns]

Builds:

Mozilla MOZ_DEBUG=1 build with code from 7pm 08 March 2000
JRE RC1 from Sun website, with Stanley's first patched JPI

Reproducible: always

Steps to reproduce

0. Build mozilla, install the JPI, set up proxies, all that jazz.

1. Visit http://java.sun.com/people/edburns/work/cams.html, or if you're inside 
sun, visit http://javaweb.eng.sun.com/~edburns/cams.html

2. Let the cam page load until you see the picture of the buildings in 
Duesseldorf and the street in Vienna

3. Observe in the command line console from which you ran mozilla.exe the 
following text:

Init applet...
Opening http://www.duesseldorf.de/cam/axislogo.gif proxy=webcache-cup.eng.sun.co
m:8080
Opening http://www.duesseldorf.de/pub/images/axislogo.gif proxy=webcache-cup.eng
.sun.com:8080
Start applet...
Run applet...
Opening http://www.duesseldorf.de/webcam/fullsize.jpg proxy=webcache-cup.eng.sun
.com:8080
[1593] [ 0 | 1 | 1 | 1663 ]
Opening http://www.duesseldorf.de/webcam/fullsize.jpg proxy=webcache-cup.eng.sun
.com:8080
[551] [ 0 | 2 | 1 | 611 ]
Opening http://www.duesseldorf.de/webcam/fullsize.jpg proxy=webcache-cup.eng.sun
.com:8080
[1532]

4. Let about 5 of the above strings go by on the console.

5. Press back, and keep pressing back until you get back to the page you were 
on before loading the cams.html url.

Note that you see the following message on the console:

Exception in thread "main" java.lang.NullPointerException: null pData
        at sun.awt.windows.WComponentPeer.hide(Native Method)
        at java.awt.Component.hide(Unknown Source)
        at java.awt.Window.hide(Unknown Source)
        at java.awt.Component.show(Unknown Source)
        at java.awt.Component.setVisible(Unknown Source)
        at sun.plugin.navig.win32.PluginObject.setWindow(PluginObject.java:201)
java.lang.NullPointerException: null pData
        at sun.awt.windows.WComponentPeer.hide(Native Method)
        at java.awt.Component.hide(Unknown Source)
        at sun.applet.AppletPanel.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)

Furthermore, note that the applet keeps loading images, even though it's not 
running.

After this happens, one can no longer view applets without rebooting the 
browser.  Trying to do so may cause something like this:

java.lang.NullPointerException: component argument pData
        at sun.awt.windows.WGraphics.createFromComponent(Native Method)
        at sun.awt.windows.WGraphics.<init>(Unknown Source)
        at sun.awt.windows.WComponentPeer.getGraphics(Unknown Source)
        at java.awt.Component.getGraphics(Unknown Source)
        at sun.awt.RepaintArea.update(Unknown Source)
        at sun.awt.windows.WComponentPeer.handleEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)

This is probably related to 27486, again.

One more VERY important thing.  I tried loading the URL from the src of the top 
part of the frameset, just the duesseldorf applet, and I couldn't get it to 
crash.  I think it has something to do with applets in FRAMES.

Comment 1

[shrirang khanzode]

*** Bug 36934 has been marked as a duplicate of this bug. ***

Comment 2

[drapeau]

Nominating for Beta 2, since it appears to be part of the lifecycle bug in
Plug-In.  Stanley, please check this?  If it really is related to the Plug-In
lifecycle problem, comment here as specifically as you can about where the cause
of the problem might be.  If it's indeed an OJI or Java Plug-In problem, comment
here as well, please.

Comment 3

[edburns]

dependency

Comment 4

[Michael La Guardia]

Putting on nsbeta2- radar.  We won't hold beta for this, but we will take the
fix from our friends at Sun if it comes.

Comment 5

[drapeau]

Ed, can you elaborate on the dependency claimed here?  I can't see it, and 
Stanley just closed out the bug on which this depends.  That bug, bug 40723, is 
a problem with an old Java class file which uses an errant class file format.
Anything more you can say about the dependency from there to here would be 
helpful.

Comment 6

[stanley.ho]

After looking closely with this bug, I found that the bug was caused by the 
fact that by the time the OJI plug-in's SetWindow() and Stop() are called 
during page switch, the native window is already destroyed. Therefore, when 
Java Plug-in tries to stop the applet and remove the applet from AWT's embedded 
frame, the native peer window is already gone. This is why we keep seeing null 
pData error.

The code for stopping the applet is in layout/html/base/src/nsObjectFrame.cpp

NS_IMETHODIMP
nsObjectFrame::Destroy(nsIPresContext* aPresContext)
{
  // we need to finish with the plugin before native window is destroyed
  // doing this in the destructor is too late.
  if(mInstanceOwner != nsnull)
  {
    nsIPluginInstance *inst;
    if(NS_OK == mInstanceOwner->GetInstance(inst))
    {
      inst->SetWindow(nsnull);
      inst->Stop();
      NS_RELEASE(inst);
    }
  }
  return nsObjectFrameSuper::Destroy(aPresContext);
}

The fix should be to ensure the native window is not destroyed when this method 
is called.

Ed, since the problem is in the layout/plugin modules, I will reassign this bug 
to you and hope you will have time to take a look at it.

Comment 7

[edburns]

I accept.

Comment 8

[edburns]

Added Stanley to CC list.

Comment 9

[edburns]

This appears to be fixed in a 4 Sept 00 Mozilla build with a 2 Sept 00 java 
plugin build.

Comment 10

[Paul Wyskoczka]

Verified in Windows build 2000102308-mn6