Images in tables

When an <IMG> tag appears in a table cell, two JavaScript Image objects will be created to represent it. If the <IMG> tag appears in a table nested within a table, four Image objects may be created. Only the last Image object created for a given <IMG> tag has a working src property. Because an unexpected number of Image objects are created, it is difficult to correctly use the Document.images[] array to refer to them.

As a workaround, give all of your images names with the NAME attribute, and refer to them by name as properties of the Document object. When JavaScript creates multiple objects with the same name, it stores them in an array by that name. If an image named "outside" is specified outside of any HTML tables, you can refer to it as document.outside. However, if an image named "inside" is created within a table, two Image objects with this name will be created, and they can be referred to as document.inside[0] and document.inside[1]. It is the latter image that has the correctly working src property.

The following function demonstrates a workaround to this bug. Given an image name, it returns the working Image object with that name. It works correctly for images that are not part of tables, and will continue to work correctly even after this bug has been patched.

function getImage(image_name)
{
    var i = document[image_name];
    if (i.length)                  // If the image is actually an array...
        return i[i.length-1];      // then return the last image in it.
    else return i;                 // Otherwise return the single Image.
}

Document.write() in nested tables

Calling document.write() from within a nested table can sometimes result in incorrectly formatted text, which may include portions of JavaScript code that appears within <SCRIPT> and </SCRIPT> tags.

Using document.write() within tables is not nearly so buggy as it could be in Navigator 2.0, but nevertheless, it is still a good idea to sidestep these problems by using document.write() to dynamically generate the entire table, including all relevant HTML tags, rather than just generating the contents of a static HTML table.

Event handlers in regenerated documents

For very complex implementation-specific reasons, if your JavaScript program generates a document into a separate window or frame, you may find that the event handlers in the generated document stop working if your program ever regenerates that document. There are two steps you can take to avoid this problem. The first is to not call document.open() for the window or frame into which you are generating your document. While it is good style to call this function, it is not actually necessary, because calling document.write() on a closed document implicitly re-opens the document. The only time document.open() is actually necessary is when you want to open a document for some MIME type other than "text/html".

The other way to avoid this problem, if you really do want to call document.open(), is to store the return value of document.open() into a global variable. The return value of this method is typically ignored but it is actually the new Document object. Because of the particular genesis of this bug, simply storing this return value is sufficient to prevent the event handlers from breaking.

Content disappears upon resize

In some generated documents, at least those containing Applets, resizing the browser may cause document content to disappear. As a workaround to this problem, you can try calling document.write() with the empty string before each <APPLET> tag in the document. That is, insert do-nothing lines like the following before your <APPLET> tags:

<!-- Bug workaround for NN 3.0 -->
<SCRIPT LANGUAGE="JavaScript">document.write("");</SCRIPT>
      

onClick() event handlers ignored

Under certain conditions, which are not yet understood, an onClick() event handler in a generated document may fail to work. Since it is not yet understood what triggers this problem, no standard workaround has been found yet.

Can't call Java method with nonsystem object arguments

JavaScript cannot call any Java method that takes an object as an argument if the type of that object is not one of the standard system classes. For example, if an applet defines a helper class called Helper, JavaScript could not invoke a method that expected an argument of type Helper. The workaround is to define any affected methods so that they take arguments of type java.lang.Object, and then, within the method, to cast those arguments to the actual desired type.

Java network activity can cause exception

If JavaScript invokes Java code that performs networking, it may cause an exception to be thrown. If you encounter this problem, a workaround you can try is to perform the networking in a separate thread, and have JavaScript call the method that starts the networking thread.

Accessing applets before they are loaded

If you attempt to use LiveConnect to interact with a Java applet before the applet is fully loaded, you will see an error dialog, and the applet will be inaccessible to JavaScript even after it has finished loading. To avoid this situation, use the onLoad() event handler of the Window object to be sure that everything has finished loading before attempting to interact with applets.

Problems with overloaded methods

If a class contains overloaded methods (i.e., methods with the same name but different arguments), JavaScript may not be able to correctly figure out which one to call. In beta releases of Navigator 3.0, JavaScript could only invoke the first overloaded method that it found in the class. That problem has been resolved, however, and overloaded methods usually work now.

If you encounter trouble with overloaded methods, a workaround is to give them different names, or to add a new method that simply calls the correct overloaded method for you.

onBlur() and onFocus()

onBlur() and onFocus() event handlers of Form elements are never invoked on Windows platforms.

onClick() in reset button

On Windows platforms, you can't prevent a Form from being reset by returning false from the onClick() event handler of the Reset button object.

FileUpload bug

For important security reasons, the value field of the FileUpload object cannot be set by JavaScript programs. This is not a bug. Unfortunately, on Windows platforms, you cannot correctly read the the value property after the user has clicked the Browse button of the form element to select a file. The value property is only correct if the user actually types in the filename. As a workaround, you can try calling the focus() and blur() methods of the FileUpload object before attempting to read the value property.