No two browsers are alike. They all have their own set of features, quirks and bugs. Whilst Joust tries to behave in a consistent way in all browsers, this is not always possible. This page discusses some of the differences and problems you may encounter with certain browsers.
Netscape Communicator 4 will not re-calculate the scroll bars on a frame when objects are moved. Given the choice of "no scroll bar ever" or "a long scroll bar all the time", I decided that a long scroll bar all the time was the better option. So, Joust forces Netscape to draw the long scroll bar by positioning an invisible object at the lowest possible point in the menu frame. Hopefully, a future version of Netscape will address this problem.
There is a well know bug in Netscape Communicator 4 on all platforms (earlier versions in particular) that occurs when a frameset is resized. Netscape does not properly redraw any content that was created or modified after the page was originally rendered. The exact behaviour can vary from computer to computer - anything from redrawing perfectly to drawing nothing. The solution to this problem is to add an onResize event handler to your frameset document (index.htm and index2.htm) that forces a reload of any frames that contain dynamic content.
Joust (from version 2.4) includes a handler which will reload the menu frame in index.htm when a resize occurs. If you have other frames that contain dynamic content that also need reloading, you should create your own resize handler and update the FRAMESET tag to call it instead of the default handler. For example, here is a function that reloads all the frames:
function myResize() { if ((theBrowser.code == "NS") && theBrowser.hasDHTML) { for (var i = 0; i < self.frames.length; i++) { self.frames[i].location.reload(false); } } }
This function can be attached to the onResize event of the frameset like this:
self.document.writeln('<frameset cols="100%" rows="70,*" onResize="myResize();">');
Note that, if you have nested framesets, you only need this once - in the outermost frameset.
If you don't need to reload every frame then you can use frame names to reload just the ones that contain dynamic content:
function myResize() { if ((theBrowser.code == "NS") && theBrowser.hasDHTML) { self.menu.location.reload(false); } }
Hopefully, the new rendering engine (Gecko) will fix this when it is released.
Note that there have been some reports of Netscape 4 on a Mac crashing when the window is resized. This appears to get more likely as the outline gets larger but does not affect all users. If you are concerned about this, you can solve it by turning off DHTML support for these particular browsers by putting this in your initialise:
if ((theBrowser.code == 'NS') && (theBrowser.version < 5) && (theBrowser.platform == 'Mac)) { theBrowser.hasDHTML = false; }
(Note that the above is assuming that the problem will be fixed in Netscape 5)
16 bit versions of Netscape have a limitation of 32K on the total size of all JavaScript in a document. If you have a large menu with hundreds of entries, it is easy to exceed this limit. When this happens, Netscape starts producing all sorts of strange JavaScript errors. The only solutions to this are to make the menu smaller (perhaps using dynamic menus to spread the code around several pages) or have a different default page that redirects the browser to to a no-frames version of your site as appropriate. For example:
if (navigator.userAgent.indexOf('Win16') >= 0) { //Can't be IE because IE uses "Windows" document.writeln("The menu system on this site requires a 32 bit browser to view. "); document.writeln("There is a " + "NoFrames".link("/noframes/index.html")); document.writeln(" version of this site that you can view instead."); } else { document.writeln("Loading site menu. One moment please..."); location.href = "/index.htm"; }
MSIE is not particularly fast at rendering DHTML content. A large menu may take a long time to draw or react to mouse clicks on MSIE. The solution to this is to turn off DHTML support on this browser. You can do this by placing the following line of code at the top of your initialise function:
if (theBrowser.code == 'MSIE') {theBrowser.hasDHTML = false;}
MSIE 4.0 on Windows has an intermittent bug which causes an "Interface not supported" error when attempting to open a window. Joust will trap this error, think that it is a security error and display the security message (see the discussion on floating Mode for more details). Downloading Service Pack 1 from Microsoft (or upgrading to 4.0.1) will fix the problem.
Joust uses a cookie to store information about it's current mode. MSIE 3 does not support the use of cookies with files loaded from disk. So, when you try to change modes, you will get a message telling you that cookies must be enabled.
If you want to load Joust from your own PC for development and testing purposes then I suggest that you get a small web server to run on your PC. There are lots of free/cheap server applications around (I use one called OmniHTTPd which you can get for free from Omnicron Technologies. Microsoft also has one you can download for free from their web site). This is a good idea, not just because you can switch modes in MSIE, but because most browsers behave slightly differently when loading documents from disk to how they behave when loading from a web server. By testing with a web server, you can make sure that what you test is what your users will see.
If you need to load Joust from a disk (you are doing a CD ROM index, for example) then you may want to give MSIE 3 users a more meaningful error message when they try to select Floating mode (Joust will currently tell them that cookies must be enabled). In the smSetCookie function in index.htm, you will find the following lines of code:
if (getMode() != theMode) { alert(smCookieMsg); } else {
Changing them to the following will give these particular users a more meaningful message:
if (getMode() != theMode) { if ((self.location.protocol == "file:") && (theBrowser.code == 'MSIE') && (theBrowser.version < 4)) { alert('Sorry, your browser does not support this feature!'); } else { alert(smCookieMsg); } } else {
JScript 1.0 has a limitation of 64K on the total size of all JavaScript in a document. If you have a large menu with hundreds of entries, it is easy to exceed this limit. When this happens, MSIE starts producing all sorts of strange JScript errors. The solution is for the user to upgrade their version of JScript.
Placing the following code at the top of index.htm will detect if the browser has JScript 1.0 and will redirect the user to the Microsoft JScript download page:
if (navigator.userAgent.indexOf('MSIE') >= 0) { if (typeof(ScriptEngineMajorVersion) + "" == "undefined") { if (confirm("This page requires a newer version of JScript to view. Do you want to upgrade now?")) { location.href = "http://www.microsoft.com/msdownload/vbscript/scripting.asp" } } }
Opera has a limit of 32K on the amount of generated content in a page. A fully expanded large menu can easily exceed this, resulting in the menu being truncated. If you have a large menu you may want to turn on "Modal Folders" for Opera browsers.
if (theBrowser.code == 'OP') {theMenu.modalFolders = true;}