HierMenus CENTRAL: HierMenus In Progress. HierMenus 5.0.1 Release Notes (3/3)

[previous]

Netscape 4 Returns

When copy-n-pasting some code over to our Netscape 4 specific script (HM_ScriptNS4.js in the distribution file) we forgot about a syntax parser peculiarity in the oldest Netscape 4.0x browsers, specifically Netscape 4.05 and earlier. These browsers insist that if any return statement of a function returns a specific value, then all paths through the function must return a value. To do otherwise results in an immediate error and an aborted script in those browsers. Unfortunately, this is exactly the situation that we inadvertantly created when adding the new HM_IsReloading variable to the various event handlers of the NS4 script. We added code that looked like this:

if(HM_IsReloading)return true;

A goof on our part, since not all of the handlers were set up to return a specific value and those that didn't caused syntax errors in Netscape 4.05 and earlier. We did a little steam cleaning in HM_ScriptNS4.js and have matched up return statements to values where necessary.

While this error caused problems only in the earliest versions of Netscape 4, the next fix applies even to the latest Netscape 4.x browsers.

The Netscape 4 Menu Mix-Up

On our Known Issues page we've documented a glitch in Netscape 4 that occurs when menu items are rolled over very quickly and continuously for some length of time. The exact problem is a little difficult to explain, but in a nutshell the display of menus would be incorrect. When rolling over a parent item (or a hotspot link that triggered a menu) the child menu would not immediately appear. But if you then moved the mouse to the spot where the menu was supposed to appear, it would suddenly be displayed. Likewise, if you moved to another item in the menu, then the child menu for the item you were previously on would be displayed.

While we still don't know exactly what's going on within Netscape 4 when this odd display behavior appears, we do believe we've located the spot that ultimately triggers the madness. Specifically, it appears as though Netscape 4.x does not appreciate the constant setting and cancelling of timers (using the familiar setTimeout function) with a value of zero milliseconds. Doing so ultimately seems to cause some confusion within Netscape 4 (or perhaps directly within the HM Netscape 4 script itself).

In HM this occurs naturally as the result of our HoverTimeTop and HoverTimeTree settings, originally introduced with the release of HierMenus 4.3. These variables were introduced to allow a more Windows-like menu behavior, where the initial display of child menus can be delayed slightly following the user moving the mouse over the parent menu item (to avoid distracting flickering as each child menu popped up and then disappeared when rolling quickly through a menu set). We implemented this feature by introducing code that would allow the child menu displays to be delayed like so:

this.childTimer = setTimeout(TimeoutCommand,this.hoverTime);

What we didn't account for in the above (because we didn't know it even needed to be accounted for) was the case where the hoverTime property is zero, which happens to be the default script setting for the variables. While we properly cancel these timers for all menu children at appropriate points in the code:

var Items = this.scrollParent.layers;
var ItemCount = Items.length;
var TempItem;
for(var i=0;i<ItemCount;i++){
   TempItem = Items[i];
   clearTimeout(TempItem.childTimer);
   TempItem.childTimer = null;
}

this doesn't appear to be enough to prevent the odd menu display behavior described above. Therefore we've added this simple fix (line wrapped here, for better display):

if(this.hoverTime>0) 
   this.childTimer = setTimeout(TimeoutCommand,this.hoverTime);
else this.hoverChild(true);

This should be a safe fix, as it simply bypasses the timer completely for those timer intervals that are zero. After adding this fix, we've been unable to replicate the menu mix-up problem in our test cases.

Slower Display for Opera

Another minor glitch in the HM5 code involved the initial display of permanently visible menus on a site. In Opera 7, such displays will sometimes fail; even though reloading the page (or hitting a different page of the site that displays the same menu structure) will display the menus properly. While no error is reported, no menu appears either. In our early testing we recognized this problem and accounted for it by delaying the appearance of the initial menu by a few milliseconds, in the same manner that we do for Internet Explorer 5 for the Macintosh. It would appear, however, to insure the display of this initial menu we need to lengthen that delay slightly for the Opera browser. We've therefore changed it from 10 milliseconds to 100 milliseconds for Opera, still quick enough that most folks will not notice the delay, but slow enough to allow the menu to actually appear and be usable:

// 5.01
//  setTimeout(TimeoutCommand,10);
    var TimeoutSeconds=(HM_Opera) ? 100 : 10;
    setTimeout(TimeoutCommand,TimeoutSeconds);

It's possible that you may need to tweak this amount further for your own use; if so let us know and if necessary we can add it as a configurable parameter in a later release.

Changed Files

For those upgrading from an earlier version of HM5, only the following files of the distribution received significant changes in version 5.0.1:

• HM_ScriptDOM.js
• HM_ScriptIE4.js
• HM_ScriptNS4.js

[previous]