Java & Netscape 4.x             

Against all the odds, there is still a fair-sized band of people using Netscape Communicator / Navigator 4.x to surf the Web. Ignoring the infamous release in which Netscape Corp forgot to include any Java™ support at all (and apparently to run the odd test before release), there are still some hefty flaws in Navigator's Java implementation that Web authors should take into account when adding applets to their pages. Those we've stumbled across so far are listed below.

Using The Dialog Font
Many applets (not just those designed by CodeBase) place text centrally within an area. Buttons and menus are obvious examples, such as our TextButton. When the applet is run, a browser's own Java Virtual Machine determines the horizontal position of the text by measuring the width of the area available and the length of the text string. Netscape Communicator / Navigator 4.x cannot accurately gauge the width of a string when it uses Java's Dialog font, imagining that it's longer than it actually is, and placing it left of center.

Solution: For aesthetically pleasing results from centered text in this browser, avoid Dialog and use Helvetica, TimesRoman or Courier instead.

Using Any Font At All
Many menu applets place lines of text in vertical columns. Examples are drop-down menus such as our ClassicMenu. In this type of applet, the vertical position of each line is determined as a factor of font-height, which allows Web authors to use a larger font without the lines of text beginning to overlap. Netscape Communicator / Navigator 4.x allows vastly more vertical space between each line of text than any other Java platform. Thus a menu containing 6 items in this browser will be longer than the same menu in Internet Explorer or Sun's own HotJava and Appletviewer. Because the same measurements are used to calculate the size of the menu needed to display these lines of text, Navigator will still create a long enough menu, but in some cases your applet height may not be sufficient for the lower entries to be visible.

Solution: When setting up any applet that creates columns of text, always check the longest column in this browser before publishing the page to ensure that applet-height is sufficient to display the longest columns. In Internet Explorer and other browsers this space at the bottom of the applet will be 'dead-space', but will at least be filled with your chosen background color (usually a parameter named BgColor in CodeBase applets).

View Refresh/Reload
The Reload / Refresh commands do not reread applet parameters. The Reload option will reread the applet dimensions (WIDTH= and HEIGHT=) settings, and will enlarge/reduce the applet area accordingly, but this has little use since it won't actually repaint the applet to take this setting into account. Enlarging the applet area and then reloading, for example, will simply add white space around what you had before.

Solution: To refresh your view of an applet, shut down Navigator, wait a few seconds, then restart it. If you use Windows 95, NT4, or later, and Internet Explorer is your default browser, it helps to have Navigator as a context-menu option for HTML files to make it easier to open them. In 'My Computer', select View, Options (or Folder Options), File Types, double-click the entry named Internet Document (HTML), and click New. In the upper box type something like Navigator 4; in the lower box enter the path to Navigator.

Security: Applets Calling External Files
'External files' can be thought of as anything but a Java .class file and the current HTML document. Many applets call external files such as sound-effects and images, and others (such as our own NewsAgent and Searchlight) read their parameters and other information from text-files. Clearly Java has to have some security measures to prevent a rogue applet on a Web site reading information from a visitor's own computer, but this type of security is largely unnecessary when the applet is reading files from its own host (as it is when you're setting up and testing pages on your home system).

Although Internet Explorer 3.02 suffered from security paranoia, Microsoft recognized how ludicrous and irritating this was and released a patch: IE4 and the patched 3.02 can read local files provided that they are in the same directory as the current HTML document or in a subdirectory.

Netscape Communicator / Navigator 4.x will refuse to run any applet that calls external files on your local system, despite the fact that your local system is the host, displaying a SecurityException message in its statusbar and Java Console window.

Solution: If an applet simply calls non-vital files such as sound effects, turn off the Sound option while testing in this browser. If the requirement to load external files is fundamental to the applet's use, you'll need to upload your pages to the Web server and test them in this browser via HTTP. Alternatively, if you have a registered copy of any CodeBase applet, you have a free utility named ComTest which will overcome this irritation. Click the link below to read about ComTest. To begin using it, however, you will need to close Navigator and restart it, as detailed in the instructions.

Start ComTest



.