385345 - Firefox doesn't call applet init(), start(), stop(), destroy() at proper times.

Status: RESOLVED INVALID

(Core Graveyard :: Plug-ins, defect)

Description

[Ken Warner]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.11) Gecko/20070312 Firefox/1.5.0.11
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.11) Gecko/20070312 Firefox/1.5.0.11

The four methods which control an applet are not properly called at the right time.  When the browser is showing a page with an applet and is iconified, the applet method stop() should be called.  When the browser is de-iconified, the applet method start() should be called.  Right now, this sequence does not happen so the applet is still running full speed.  If stop() is called, the applet programmer can put the applet into a sleep mode awaiting to be start()'ed again.  If the applet is a very resource hungry applet, it can affect the operation of other applications.

When the user goes to a different page from a page that is showing the applet, the sequence described above should be called.  Now the applet is stop()'ed and destroy()'ed.  It should be only stop()'ed because if the user returns to the applet page, a whole new applet is created which forces the loss of the previous state of the applet.  All content and state is lost if the user goes to another page.  THIS IS WRONG!  



Reproducible: Always

Steps to Reproduce:
1.start an applet, change state of applet
2.go to another page
3.return and notice that all your work is lost
Actual Results:  
see above

Expected Results:  
The state of the applet should be preserved across page changes.

A new applet should not be created upon returning to the page that has the applet.

Applet state should be preserved across page changes calling stop() and start() appropriately.

Destroying the applet when the user goes to another page is inconvienent and discouraging to applet use.  Thoughtless managment of user time and effort diminishes Firefox.

Consider:  A user is working on some task that uses an applet to accomplish that task.  The user needs some information from another page.  Instead of opening a new tab, he types in a new URL; gets the required information and returns expecting to find his work still in place -- BUT IT'S GONE.

Bad news for the user -- bad news for Firefox.

Please address this problem.  If your suite of test applets do not provide you with enough information, I will provide you with a test applet.

Comment 1

[Ken Warner]

http://java.sun.com/developer/technicalArticles/Threads/applet/index.html

Stopping the Applet

The applet's stop method is called whenever you minimize applet viewer, or if the applet is running in a Web page, whenever you go to another Web page. At this point the setPaused method is called to put the applet in a paused state.

  public void stop() {
    setPaused(true);
    printThreadName("stop is ");
  }

The last line of the stop method calls printThreadName to get the name of the current thread and print it to the command line. The sample run above shows that at this point in the applet's execution the current thread is the the applet thread:

  stop is thread applet-SlideShow.class

Exiting the Applet

When you exit applet viewer or close the browser, the applet's destroy method is called to stop the thread and perform cleanup. The image and text arrays are set to null to make them ready for garbage collection.

The call to images[i].flush flushes all resources used by the Image array, including any pixel data being cached for rendering to the screen and any system resources used to store data or pixels for the images. The images are reset to a state similar to when they were first created so that if they are rendered again, the image data has to be recreated or fetched from its source. 

Comment 2

[Adam Guthrie]

Does this work OK in Firefox 2.0.0.x or Gran Paradiso? Mozilla doesn't even support Firefox 1.5.0.x anymore...

Comment 3

[Ken Warner]

I don't know.  What if it does?  Does that mean that everybody has to upgrade to Firefox 2.x???

Poor analysis -- poor strategy -- ...  And why -- after all these years -- am I the first person to notice this?  It's a major Java integration problem.

Comment 4

[Adam Guthrie]

Would you please just humor me and test this in Firefox 2? Or provide a testcase that I can use to test? Once we establish whether it's a problem in Firefox 2, we can move forward.

Comment 5

[Ken Warner]

Ok....

http://pancyl.com/appletbug.htm

It's a panorama viewer.  Right click / drag the mouse to move -- mousewheel zooms as does cntl / shift keys...

If you open the Java console, you will see that the applet creation method; the init method; start method; stop method; destroy method all print out their name when they are called as you run the applet.

ALSO:

If you open two windows on this applet and then close one of the windows, both applets are destroyed even though only one of them should be destroyed.

I really hope this is fixed in FF 2.0.  Honest.  I just don't have the time to
switch right now....

Ken

Comment 6

[Ken Warner]

...I meant Left Click...

Comment 7

[Peter Gaarde]

This problem is still a serious issue in FF 2.0! In fact there may be a general problem with the handling of embedded objects in FF. Objects are rerendered/reinstantiated eg. https://bugzilla.mozilla.org/show_bug.cgi?id=262354 showing that the problem is the same for Flash objects (http://www.zelph.com/sandbox/flashBugs.html).

We have started doing heavy ugly stuff to limit the damage in our Java Applets. But the behaviour of FF to applets is absolutely incorrect. Applets should be createde and init()/start() called at load-time. After that only start() and stop() should be called - when the applet moves in and out of sight. Finally when the PAGE is disposed from FF the destroy() method should be called. 

This is fairly understandable for an object, that must keep state and reflect user-actions. But FF disposes the object instead of just calling stop - so the result is, that the object that comes in sight the next time is not the same INSTANCE that the user worked with a few seconds ago - puf the magic dragon. 

This will leave any user frustrated and confused.    

I think this is a SERIOUS matter, and like described under reproducibility it can be documented with ANY applet that contains state eg. a simple textfield or by looking at the principle in the fine Flash example.

I'm very confused, that this bug is having status of not being confirmed - because I can only nod towards all the things Ken has been writing above.

I really like and recommend FF - so please pull the knife out of my chest!

/Peter  

Comment 8

[Nils Fredrik Gjerull]

I can confirm this bug in Firefox 3.0.3. In my opinion the init() method should be called when the applet is loaded and the destroy() should only be called when the tab/window containing the applet is closed. 

The start() method should be called when the applet become visible and the stop() method should be called when the applet become hidden. This should happen no mater what the reason, if it is caused by CSS, changing tab or leaving the page. 

I am a bit uncertain about what should be done when changing browser window because someone might be interested to have two browser windows visible at the same time.

At this time FF calling of applet lifecycle methods is unpredictable. I have done some experimentation. Using 'disblay none/block' to hide/show a section of the page the init() and start() method is called when showing and the stop() and destroy() method is called when hiding.

If a block containing an applet is initially hidden (using 'display: none') it is not possible to call methods on it before the section is shown. This is because the applet is not instantiated before it is shown.

Hiding using the CSS attribute 'visibility' has no effect on the applet lifecycle, neither has changing tabs, or changing browser window for that matter.

The calling of lifecycle methods on plugins, be it flash or java, should be consolidated. This unpredictability is causing headaches.

Comment 9

[Nils Fredrik Gjerull]

I did the previously mentioned experiment using the new java plugin (libnpjp2) on a linux platform.

Comment 10

[Tyler Downer [He/Him]]

This bug was reported on Firefox 2.x or older, which is no longer supported and will not be receiving any more updates. I strongly suggest that you update to Firefox 3.6.3 or later, update your plugins (flash, adobe, etc.), and retest in a new profile. If you still see the issue with the updated Firefox, please post here. Otherwise, please close as RESOLVED > WORKSFORME
http://www.mozilla.com
http://support.mozilla.com/kb/Managing+profiles
http://support.mozilla.com/kb/Safe+mode

Comment 11

[Tyler Downer [He/Him]]

No reply, INCOMPLETE. Please retest with Firefox 3.6.x or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.

Comment 12

[Nils Fredrik Gjerull]

I can confirm exactly the same behaviour in Firefox 3.6.3, nothing has changed. Please repoen this bug. It is a showstopper for combining AJAX with applets, because of the CSS display:none/block issue.

Comment 13

[Nils Fredrik Gjerull]

The javaplugin I used is: Java(TM) Plug-in 1.6.0_20 (libnpjp2.so)

Comment 14

[Tyler Downer [He/Him]]

How about Firefox 4 and jave 6 update 25?

Comment 15

[Gili Tzabari]

With all due respect, instead of asking users to keep on trying to reproduce the problem with newer and newer versions, how about letting us know once you actually commit a fix and then we'll re-verify for you. What makes you believe this is fixed in update 25? I thought the bug is in FireFox, not in the Java plugin. If it's in the Java plugin we should have a BugParade issue to point at (as far as I can tell, no such issue exists).

Comment 16

[Swarnava Sengupta (:Swarnava)]

Firefox 3.6 is now EOL, please try latest version of Firefox and feel free to open if it reproducible on latest build
* http://getfirefox.com
for support
* https://support.mozilla.org/ask/

Comment 17

[Gili Tzabari]

Attachment: Testcase: index.html

Comment 18

[Gili Tzabari]

Attachment: Testcase: Lifecycle.java

Comment 19

[Gili Tzabari]

Attachment: Testcase: Lifecycle.class

Comment 20

[Gili Tzabari]

Reproduced under Firefox 13.0, Java7 update 4. I've attached a simple testcase to help you out.

*Please* stop closing this issue without attempting to reproduce it yourself. This is the third time you've done so and it's getting annoying. What's the point of asking us to retest this issue unless you've committed a fix? It won't magically fix itself.

Comment 21

[Stuart Cook]

The lifecycle methods are called by the Java plugin, not by Firefox, and NPAPI doesn't provide any way for Firefox to tell the plugin precisely when they should be called. Restoring the old lifecycle behaviour would require changes to the plugin itself.

(This assumes that we're talking about the new-style Java plugin. Support for the old-style Java plugin was removed from Firefox a long time ago [bug 485984], and will almost certainly never be restored. I have no idea whether newer Java releases even include the old-style plugin.)

Comment 22

[Masatoshi Kimura [:emk]]

Other browsers (at least Chrome and IE8) also call destroy() when an user leaves a page. I bet people will start complaining a "memory leak" if this bug is "fixed".

Comment 23

[Gili Tzabari]

I guess the question is when stop() should be called. Currently its meaning is identical to destroy(), isn't it?

The way I see it, stop() should be called when you leave the page and destroy() may be called at any later time (at the browser's prerogative) when it runs short on memory. That should take care of the memory leak you mentioned.

Comment 24

[Benjamin Smedberg]

We provide some methods to the Java plugin via NPAPI, including information about when the plugin is visible (for painting purposes). We don't plan on changing that life cycle. Exactly how Java exposes that to applets is not part of our product and so we aren't going to track it here.