15179 - Applets using lightweight components don't get destroyed.

Status: VERIFIED FIXED

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

Description

[Leila Garin]

Using the daily (9/27/99) Mozilla build on Windows NT, and jdk1.3.
This bug also occurs in Mozilla M9 build on MAC using the MRJ Plugin.

To reproduce,
- Bring up the apprunner/viewer.
- Load any of these applets that use lightweight components.

http://passage/browser/src/Applets/Misc/html/awt-1.1/lightweight/Gauge/example.html
http://passage/browser/src/Applets/Misc/html/awt-1.1/lightweight/OpenlookButtons/example.html
http://passage/browser/src/Applets/Misc/html/awt-1.1/lightweight/RoundButtons/example.html
http://passage/browser/src/Applets/Misc/html/awt-1.1/lightweight/Spinner/example.html

- Load another applet from the list.

  Notice that the html page changes, but the applet that is shown is the
  first one. This is the same with other applets in the list. It seems that
  the first applet never gets destroyed. Because of this, you need to quit the
  browser to load the succeeding applet, which is very bad.

Comment 1

[Dawn Endico]

Mark Lin no longer works for Sun. Reassigning his bugs to George
Drapeau

Comment 2

[loki der quaeler]

could i please get an external URL to these pages? thanks, loki

Comment 3

[drapeau]

Raju: I'm adding you to this bug's CC: list so you can help get Loki the tests. 
 I'm guessing Leila is busy, as it's no longer her job.

Comment 4

[rpallath]

See
http://java.sun.com/products/jdk/1.1/docs/guide/awt/demos/lightweight/

Comment 5

[loki der quaeler]

this functions correctly under the mac platform with v. 1.1eqd2 plugins... very 
interestingly however, they appear to obey scrolling as well, where as the heavy 
weight applets do not (which is lumped under bug 7366).

thanks for the pointer raju!

Comment 6

[drapeau]

I'm going to push this off to the next milestone, to give others time to work on 
 crashers, etc.  In the mean time, Raju, does this error occur on the Windows 
Java Plug-In as well?  The bug was reported for Solaris only, but I don't know 
if this occurs on Windows as well.

Comment 7

[rpallath]

Yes it does occur on Windows 
Tried this on WinNT4.0 SP5 with M15 with internal Plugin
and Netscape Preview 1  with bundled plugin

Comment 8

[rpallath]

Looks like it is a Codebase problem

If I try the external URL 
http://java.sun.com/products/jdk/1.1/docs/guide/awt/demos/lightweight/
It does show up correctly. If u look at the HTML sources, it does not have a
codebase entry.

However if u try the
http://passage/browser/src/Applets/Misc/html/awt-1.1/lightweight/
examples it will however exhibit the problem reported in the bug.
If u view the source, the only difference is that it has an extra codebase
entry.

Looks like it is not able to resolve that entry correctly.

Comment 9

[timeless]

Per Addt'l Comments From [e-mail] 2000-05-16 10:54 marking PC/All
I'm guessing that this problem is actually All/All [ie Mac too] based on Addt'l 
Comments From [e-mail] 2000-05-22 13:18.  If someone inside sun.com 
wants to assert All/ by testing Mac that's nice. Otherwise, it would be really 
helpful to mozilla.org if a 
http://passage/browser/src/Applets/Misc/html/awt-1.1/lightweight/
was attached to the bug.

Comment 10

[edburns]

Still occurring.

Comment 11

[stanley.ho]

This is the classic problem of the Netscape 6 implementation of the applet 
lifecycle. Apparently, when the browser encounters an applet, it will 
init/start it, and caches it after the page switch. However, when it encounters 
another applets which has similar codebase/params, instead of creating a new 
applet, it tries to find any stopped applet in its cache. In this case, it 
thought it found the right one and restarted it. This is why the same applet 
keeps showing up even a different page is encountered. This problem will go 
away with the applet lifecycle fix by Ed. I will reassign this bug to Ed.

Comment 12

[edburns]

Depends on bug 50547, accept.

Comment 13

[edburns]

Updated URL.

Comment 14

[edburns]

Using Netscape_20000922 branch pulled at 11pm on 10/2 and Java Plugin 
from /usr/local/java/jdk1.3.0_01-beta_refresh-2/bundles at 9am on 10/3, I find 
this bug no longer manifests.  Therefore I'm marking it fixed.

Comment 15

[Paul Wyskoczka]

Updating QA Contact

Comment 16

[shrirang khanzode]

Leilag, can you pls verify this bug for me. I do not have access to the 'lonely'
server testcases.Thanx.

Comment 17

[rpallath]

I just verified this  on Win NT/98 with latest nightly build of mozilla and FCS
jre bits.

It does load  all applets appropriately.
Fixed.

Comment 18

[John Unruh]

Verified per rpallath's comments.