In the previous release of Arachnophilia, by far the most common complaint was about preview browsers — they would close when they shouldn't, or wouldn't close when they should, or they caused Arachnophilia to crash, or they locked up the system, and so forth.

When things were working perfectly, the browser would launch just once, not 0 times or 20 times. It would show the page to be previewed, and it would refresh itself without crashing or cloning itself, so you could look at changes in your page without an excessive amount of time spent waiting for another browser launch. But, on the strength on e-mail feedback, it seems that outcome was the minor, aberrant case.

In Java, in exchange for portability and much less tendency to crash, one has somewhat less intimate control over the system browser. In the current version, the browser is launched, then, for the next preview, typically that process is terminated and the browser is launched again. This is by far the most reliable and portable approach.

But, consistent with the entire Arachnophilia design philosophy, you can change this if you want. There are any number of special browser features that might, in some cases, allow the browser to simply refresh itself, without any great strain. Therefore the browser configuration dialog (by default on the HTML menu) allows you to choose whether or not to terminate the previous browser process (with "close before opening"), you may choose whether or not to use the feature that usually causes a jump to the editing position in the launched page (see below) (especially convenient if the browser is relaunched on each preview), and you can enter custom browser launching instructions.

The Internet (and Usenet in particular) is awash with suggestions about how to launch Web browsers in various interesting ways. Arachnophilia will accommodate most of them, using the browser setup dialog's data fields. The only pedestrian requirement is that the symbol "$1" be included somewhere in the command string, to allow the temporary preview file to be included as the browser's target.

Actually, on second thought, you might choose not to use the temporary file at all, and instead save your document to preview it, in which case you would need to include your document's name as "file:/[FullPath]", or something like that, instead of "$1". In this case, a feature to be described below won't work.

A few more details. For various reasons, Arachnophilia creates a temporary file for browser previewing. The temporary file is located in the same directory as the file being previewed if the file has been saved, or in the user's home directory if the file has yet to be saved. This temporary file is deleted either in the course of changing pages and browsers, or it is deleted when the user exits Arachnophilia.

The original reason for the temporary file was to make it possible for an HTML beginner to view a page he had not saved, or wasn't considering saving, or perhaps thought "saving" was only something that Jehovah's Witnesses do. But it turns out having a separate preview file has a rather nice side effect — read on.

In the new version of Arachnophilia, as soon as I realized I wasn't going to be able to simply refresh any browser on any platform without also relaunching the browser, I also realized that the new browser view would inevitably show the top of the previewed page. So I thought up a way to make the browser scroll to the editing position — I insert a document reference tag (sort of an HTML bookmark) in the temporary preview file, and I specify that reference in the browser launch URL, which ordinarily makes the browser seek out and display the reference. This scheme doesn't always work — I place the tag in the preview file without exhaustively trying to avoid places where the reference will not be found (such as in a table, but outside <td></td> pairs). This method usually gets the browser to show the editing area of the current page - usually. :)