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.
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?
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.
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.
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.
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/
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.