My name is Dave Meyers. I help develop the Cyberprise product family at Wall Data. We're experiencing a problem when we attempt to use Communicator 4.x to display the HTML we generate from a variety of sources (Word documents, Excel spreadsheets, output from other Wall tools, etc.). In operating the Cyberprise InfoPublisher product, the user uses a browser to select from a list of documents (presented as HTML), at which point we generate HTML that consists of a pair of frames. The actual document content is displayed in a large upper frame, while a "back" button is displayed in a small lower frame. The user presses the back button to return to the list of documents. If the user presses the back button while a (large) document is being loaded into the upper frame, Communicator traps. To prevent this, we have added JavaScript code to the content of both frames and their parent frameset to "disable" the back button until the document has finished loading in the upper frame. This works fine, but there is a further mystery. If the <META> tag specifies "charset=us-ascii", Communicator seems to "reprocess" the document content in the upper frame. The evidence of this reprocessing is that the scroll bar thumb goes through the process of starting large and gradually shrinking to its final size (as if Communicator were actually reloading the document) and the progress meter goes back to 0% and "counts up" to 100%. If the user presses our back button in the lower frame during this reprocessing, again Communicator traps. We are currently working around this problem by ensuring that we never set charset to us-ascii, but this is not a good solution for a couple of reasons: 1) We don't know what other character sets might cause this reprocessing behavior in Communicator. 2) We are changing the character-set specification from us-ascii to windows-1252, but don't have any equivalent operation for foreign character sets if they turn out to be similarly problematic. In addition, we don't really want users to have to wait until the document finishes loading before pressing the back button, so ideally we'd like to remove the JavaScript code that disables the back button while the upper frame's document is loading. (As an aside, with Internet Explorer there is no reprocessing of the document regardless of charset value. Of course, we'd like to support as many browsers as possible, as effectively as possible.) Can you shed any light on what might be going on during the "reprocessing"? Do you know why the reprocessing seems to be a function of character set? Can you shed any light on why attempting to return to the list of documents by pressing our back button while the document is loading or being reprocessed causes a trap in Communicator? Do you have any other thoughts or suggestions about this problem? I have available some simple HTML files that illustrate the problem but don't see any way to enclose them. Let me know how to send them in. Thanks.

Dave, this is actually a bug system for our next generation browser (not 4.x). I would suggest you look at http://help.netscape.com/index.html and especially at the Nuggies newsgroups for help in answering your questions. Sorry for the stock answer but this is not the right place to be looking for tech support.

Changing all Progress Window components to XP Apps: GUI Features. The Progress Window component will be retired shortly.