205771 - All parameters not available to Java Applet after page refresh

Status: RESOLVED EXPIRED

(Core Graveyard :: Java: OJI, defect)

Description

[Kevin Yank]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030507
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3.1) Gecko/20030425

The sample page (http://www.editize.com/democms.php) contains a Java applet that
acts as a rich text editor. It is passed a number of configuration parameters
(<param> tags) to control the features that are available as well as any
browser-specific behaviour.

When the page is first loaded in Mozilla 1.3.1 for Mac OS X (also tested in
1.2b), the applet gets all the parameters and behaves correctly. If you click
the Back and then Forward buttons to unload and then reload the page, the applet
continues to behave correctly.

Now, with the applet displayed, click Mozilla's Reload button. The page and
applet reloads, but this time the applet will exhibit incorrect behavior.
Debugging indicates that some of the parameters being passed to the applet as
<param> tags are not being received by the applet (a getParameter("name") call
returns null within the applet).

The most common symptom of this is an error message from the applet saying
"Editize could not access the form element", which is symptomatic of the "osx"
parameter not being sent to the applet, but more subtle effects can also occur
(e.g. the "WYSIWYG View" and "Code View" tabs may not appear, or text in the
field may be displayed in a serif font).

Repeated testing seems to indicate that the first <param> tags are usually
received by the applet, while the last couple of <param> tags are most often
left out. This would seem to indicate a race condition between the parameters
loading and the applet loading.

Reproducible: Always

Steps to Reproduce:
1. Load http://www.editize.com/democms.php in Mozilla 1.3.1 for Mac OS X.
2. Wait until the applet is loaded -- accept the security prompt if displayed.
3. Once the applet is running, click the Refresh button in the browser's toolbar.

Actual Results:  
The applet displayed symptoms that indicated it was not receiving all the
<param> tags it was being given. Debugging the applet confirmed this diagnosis.

Expected Results:  
The applet should have received all its <param> values, as it did when the page
was first loaded.

The applet in this test case is signed; however, there is no evidence that this
affects the behaviour described in this bug one way or the other.

Comment 1

[Greg K.]

Seems to WorkForMe using FizzillaMach/2003-05-07-14-1.4b. I see no "symptoms;"
the applet displays the same the second time as it did the first.

Kevin, can you reproduce this problem using a current nightly build? What
version of OS X are you using? What MRJ version?

Comment 2

[Kevin Yank]

100% reproducible on Mozilla 1.4b. 100% reproducible on current nightly build
(15 May 2003).

My Mac OS X version is 10.2.6.

The Java version is shown in the Java Console as 1.3.1. All Software Updates
from Apple have been applied.

I do not know how to check the MRJ version.

The applet works fine in Internet Explorer 5.2.2.

Comment 3

[Kevin Yank]

Further testing (with the current nightly build) strongly indicates a race
condition dependent on the load speed of the page. When loading a copy of the
exact same site (all applet and file versions are identical) from a server on
our LAN, the applet obtains all its parameters every time. The only explanation
we can find for this is that the HTML code for the parameters loads in time for
all of them to be passed to the applet.

Your failure to reproduce this bug may therefore simply be due to a faster
Internet connection than ours.

Comment 4

[Joshua Xia]

MacOS->[e-mail]

Comment 5

[石庭豐 (Seak, Teng-Fong)]

It would be interesting if you could test this bug in the same network condition
but using Windows or Linux, because the "audience" would be bigger and more
people would be interested, as a matter of fact unfortunately :(

I can't reproduce your bug, but suppose the bug exists, it might be a sign that
init(), start() or paint() methods are called too early.  IMHO, the browser
should wait for the whole <applet> element to be downloaded before calling the
applet.

Comment 6

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 7

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.