 |
Appendix B |  |
|
Appendix B | |
Contents:
Known JavaScript Bugs in Navigator 3.0
Known JavaScript Bugs in Internet Explorer 3.0
Commonly Encountered JavaScript Bugs in Navigator 2.0
In order to program effectively in JavaScript, or any language, it is important to have an idea of what features don't work as advertised. This appendix discusses the known bugs in various versions of JavaScript.
The bugs detailed in the sections below comprise the complete list of JavaScript bugs that were known to the developers of JavaScript at Netscape when this book went to press. Unfortunately, not all of these bugs have been fully researched, and some of the descriptions are vague. They've been arranged by topic, and in approximate order of severity and the frequency with which they are encountered.
The History.go() method may not work correctly when a window contains multiple frames. Use History.back() and History.forward() instead.
There are a couple of JavaScript bugs in Navigator 3.0 that relate to HTML 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.
}
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.
Navigator 3.0 contained a lot of changes that allow it to print and save the dynamically generated content of documents, which is something that was not possible in Navigator 2.0. Unfortunately, these changes seem to have left (or created) some residual bugs, and the exact circumstances under which these bugs can occur are not always clear.
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.
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>
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.
LiveConnect, described in Chapter 19, LiveConnect: JavaScript and Java, is a new and powerful addition to Navigator 3.0. As such, it is not surprising that some bugs remain. Actually, most LiveConnect bugs are really missing features, rather than actual buggy implementation.
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.
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.
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.
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.
There are a few bugs related to event handlers and form elements that occur on Windows platforms only.
onBlur() and onFocus() event handlers of Form elements are never invoked on Windows platforms.
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.
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.
On Unix platforms, when you open a new window with the Window.open() method, the width and height specifications may be overridden and ignored if X resources specify window width and height, or if Navigator was started with the standard X -geometry command line argument. The only workaround to this bug is to be satisfied with the default window size and not try to override it with X resources or command-line arguments.
