home / bulletins / 15

 

HierMenus 6.0.1: Release Notes

D.M Ragle, June 17, 2004

A few bugs are squashed in this purely maintenance release version of HierMenus, including a nasty mouse wheel related regression bug from the HM 5 code base, and a minor fix for incorrect menu placements when using HM_default_x_position and/or HM_default_y_position on permanently displayed menus. Also: Konqueror 3.2 support is reinstated in HierMenus 6.0.1. Because the mouse wheel bug in particular could strike Internet Explorer 6 users in any ScrollEnabled HierMenus implementation, version 6.0.1 is a recommended upgrade for all current HierMenus 6.0 users.

As a reminder, though our release articles can be appreciated by and may be useful to all DHTML developers and HierMenus fans, the HierMenus script itself is a licensed product and its use on your site(s) requires a paid license agreement. Contact Barry Pullen or call him at (203) 662-2868 for further information (be sure to let him know how you plan to use HierMenus and tell him a bit about your organization, as well).

Mouse Wheel Errors in Internet Explorer

When rolling over a menu in Internet Explorer 6 and attempting to use the mouse wheel (assuming you have a mouse with a mouse wheel), HierMenus 6.0 will greet you with this rather annoying error message:

Error: 'this.eMenu.MoveTimer' is null or not an object

(In the space optimized code set, the offending property is this.mh.sp.)

Regrettably, this was the result of a silly regression bug on our part, where a portion of the HM 5 code was not properly ported for use in the HM6 architecture. We've corrected the problem by replacing the entire mouse wheel handler for IE. On a historical note, Internet Explorer mouse wheel support was first introduced in HierMenus way back in version 4.2.2.

Welcome (Back) Konqueror

Our initial release of HierMenus version 6 disabled support for the Konqueror Web browser entirely. At that time, our Konqueror testing was limited only to Konqueror 3.1.x versions; and multiple incompatiblities were encountered between Konqueror and the HM6 code base. We've since been able to test HM6 in Konqueror 3.2.x versions, and are pleased to report that the results were more than satisfactory. Nearly all the problems we had encountered with the Konqueror 3.1.x/HierMenus 6.0 combination were not present in Konqueror 3.2; therefore we are reinstating support for Konqueror 3.2 and later in HierMenus 6.0.1.

There are, however, some minor HierMenus problems that remain when using Konqueror, including:

• Browser scrollbars sometimes appear on menu creation
  When menus are initially created, Konqueror will occasionally alter or display page scrollbars where they are unnecessary (as if Konqueror believes some component to now be visible in a currently non-visible portion of the page). As all HierMenus are created off screen (upwards and to the left of the current browser window), we don't know why this behavior occurs. Other than being visually distracting, the behavior does not seem to adversely effect the page or menus.

• Standard Cross-Frames Not Supported
  Konqueror does not refire page loads when historical pages are loaded in frames. This causes problems in HierMenus similar to those that we've previously encountered in Opera. Unlike Opera, however, we were unable to create workarounds that effectively counter this behavior. Therefore, we have disabled the Standard Cross Frames support for Konqueror entirely. Note that the Alternate Cross Frames implementation methodology, introduced with HierMenus version 6, works fine with Konqueror.

Making Sure Zero Really Is Zero

In HM6, the HM_default_x_position and HM_default_y_position parameters were introduced to help Webmasters fine-tune the positioning of their menus (see the Menu Positioning Mini-Tutorial for further details). While unnecessary, these parameters could also be used in permanently displayed menus. In such instances, they would always assume a value of zero (which is why, strictly speaking, they were unnecessary; since you could remove them from your JavaScript expressions completely and achieve the same result). Nonetheless, one situation was brought to our attention when the variables are not set to zero for permanently displayed menus: specifically, when you resize the document. Doing so with a permanently displayed menu that utilized one of the above parameters in a menu positioning JavaScript expression would generate an error in Internet Explorer, as the uninitialized value would generate an unusable NaN when used in a calculation.

As mentioned above, the easiest fix was to simply remove the HM_default_x_position and HM_default_y_position parameters from permanently displayed menu positioning schemes entirely; but for consistency we've also corrected the problem in HM as well, ensuring that the key values utilized in the positioning of permanently displayed menus are properly initialized so as not to cause an error when used. Now our zeroes should be zeroes in all cases.

Don't Load Empty Configuration Files

When utilizing HM with a database, it is common to blank the default configuration file that is fed to HM_Loader.js; as the developer instead opts to build the configuration file dynamically within the page via server-side tools (see Using HM With A Database for further details). When specifying a blank configuration file, however:

HM_ConfigDir="";
HM_ConfigFiles="";

HM_Loader.js would still attempt to load the "empty" file into the Web page. In Internet Explorer, this attempt is silently ignored; but in Gecko browsers the result was a seemingly impossible to track error message with no file or line number designated. In HierMenus 6.0.1 we avoid this error by checking that the configuration file designation is valid before attempting to use it.

Incorrect Menu Height With Large More Images

If a menu was defined with a more image that was higher than the natural height of a menu item, and that more image appeared in the final menu item of vertical menus, then the menu height itself would be improperly set to include the full height of the more image in the last menu item in Internet Explorer (as opposed to our intended behavior, which was to clip the more image by the natural height of the menu item). We believe we've corrected this problem, by explicitly setting the more image's height both before and after its src is loaded. Our test cases here have not demonstrated the problem since this adjustment; let us know if your own results are showing otherwise.

Mixed Content Security Warnings in IE Frame Masks, HTTPS

Finally, when using the IE IFrame masking technique in Internet Explorer, a security warning would appear indicating that some content was being retrieved from an insecure source. This warning message is the result of not assigning a valid src document to the IFrames themselves, as explained in this Microsoft Knowledgebase Entry:

Security Warning Message With IFRAMEs in SSL

In our IFrame mask implementations we didn't assign IFrame sources, because they were unnecessary (we just need the IFrame container itself, it doesn't matter what is loaded within it). To adjust for this error message, we now load the "document" javascript:void(0) into the src of the IFrame masks. This removed the error warning on our test systems here; but at least one client has noted that it was not fully adequate in removing the security warnings in their implementations. If you continue to see security warnings in this scenario (using the IFrame masks in SSL implementations) then you may need to load a valid (empty) page into your IFrame masks. Contact us and we'll be happy to provide details.

Conclusion

Thanks especially to our initial HM6 adopters for pointing out each of these errors to us, allowing us to add even further stability to HierMenus. We appreciate your feedback on these issues!