Applets using lightweight components don't get destroyed.

VERIFIED FIXED in M17

Status

defect
P3
major
VERIFIED FIXED
20 years ago
9 years ago

People

(Reporter: leilag, Assigned: edburns)

Tracking

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [please attach a copy of that page, sanitize if necessary], )

Reporter

Description

20 years ago
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.

Updated

20 years ago
Assignee: drapeau → mark.lin

Updated

20 years ago
Status: NEW → ASSIGNED

Comment 1

19 years ago
Mark Lin no longer works for Sun. Reassigning his bugs to George
Drapeau
Assignee: mark.lin → drapeau
Status: ASSIGNED → NEW

Comment 2

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

Comment 3

19 years ago
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 5

19 years ago
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

19 years ago
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.
Status: NEW → ASSIGNED
Target Milestone: --- → M17

Comment 7

19 years ago
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

19 years ago
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.

Updated

19 years ago
OS: Solaris → All
Hardware: Other → PC
Whiteboard: [please attach a copy of that page, sanitize if necessary]

Comment 9

19 years ago
Per Addt'l Comments From rpallath@eng.sun.com 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 rpallath@eng.sun.com 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.
Assignee

Comment 10

19 years ago
Still occurring.
Assignee: drapeau → stanley.ho
Status: ASSIGNED → NEW

Comment 11

19 years ago
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.
Assignee: stanley.ho → edburns
Assignee

Comment 12

19 years ago
Depends on bug 50547, accept.
Status: NEW → ASSIGNED
Depends on: 50547
Assignee

Comment 14

19 years ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 15

19 years ago
Updating QA Contact
QA Contact: paw → shrir

Comment 16

19 years ago
Leilag, can you pls verify this bug for me. I do not have access to the 'lonely'
server testcases.Thanx.
QA Contact: shrir → leilag

Comment 17

19 years ago
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

18 years ago
Verified per rpallath's comments.
Status: RESOLVED → VERIFIED

Updated

9 years ago
Component: Java: OJI → Java: OJI
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.