home / bulletins / 16

 

HierMenus 6.0.2: Release Notes

D.M Ragle, August 25, 2004

A pair of minor Internet Explorer problems are addressed with this HierMenus maintenance release. It is recommended that current users upgrade if they are--or expect that they may--encounter these specific issues.

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).

Large Scrolling Menus are Goofy

In some Internet Explorer situations, it was brought to our attention that scrolling menus can sometimes appear distorted after they are scrolled. Specifics of the distortion vary, but in general some of the lower menu items will sometimes appear at the top of the menu, and the menu scroll bars will not be positioned properly, sometimes appearing within the menu itself, and sometimes appearing with the top scroll bar beneath the bottom scroll bar!

This menu consists of items numbered 1 through 40, from top to bottom. As the menu is scrolled down, notice that some of the lower numbered menu items incorrectly appear at the top of the scrolling menu.

In a more drastic example, the lower menu items appear at the top of the menu, and the lower scrollbar is incorrectly displayed almost at the top of the menu.

After testing, we were able to narrow this behavior down to two variables. First, a large number of menu items--in our tests, over 30--had to be visible in the scrolling menu on the page (i.e., at least 30 items had to be visible on the page at the same time without scrolling). Second, the user's monitor had to be set to a higher resolution; at least 800x600, with the problem appearing more readily in higher resolutions. We were unable to trigger the problem in 640x480 resolutions no matter how many menu items were displayed on the page; and in higher resolutions if we reduced the number of menu items displayed simultaneously (by increasing the font size for the menu items, for example) the problem went away.

We believe this to be a display bug in Internet Explorer; both because it only seems to affect certain resolution displays, and because we found that updating some other, unrelated area of the page--such as firing an alert or updating a text input box--while the menu was scrolling removed the problem. Additionally, the problem does not seem to effect any other DOM browsers (Opera, Safari, Mozilla) even though they use nearly identical logic.

As a work around, we've decided to momentarily hide the menu while it is scrolling, and then make it reappear again after the scroll movement has been processed; which seems to be enough of a hint to Internet Explorer to properly readjust the menu display on the screen. The actual hiding/displaying of the menu is handled within the same thread without any other display logic intervening; so it is not actually seen by the user. After making this minor change, we were unable to reproduce the original problem in any window resolution, with no noticeable change in the scrolling menu displays themselves.

It's Better to be Greedy

One user reported to us another Internet Explorer problem that, despite our best efforts, we were unable to replicate on our own test machines. Specifically, one of our regular expressions was triggering this error as soon as HM was loaded on the page:

Error: Unexpected Quantifier

Unfortunately, since we are unable to replicate the problem on any of our own machines, we can only guess at the cause; and we believe that to be spotty support for "non-greedy" quantifiers. In basic terms, a non-greedy quantifier--indicated by a question mark following the general quantifiers of + or *--allows a regular expression to match as few of the tokens prior to the quantifiers as possible; as opposed to the default behavior which is to match as many of the preceeding tokens as possible. Whether you understand that or not isn't all that important; but the interesting thing to note is that support for non-greedy quantifiers was added to JavaScript after support for other quantifiers was.

Our original belief was that all IE5+ browsers supported non-greedy quantifiers, and again, that is indeed what we saw in our own testing. Nonetheless, we don't really need them; as the problem RegExp that used them can easily be written another way. This is in fact what we've done in HM6.0.2; so hopefully the Unexpected Quantifier will not resurface on those few machines and configurations that seem to spawn it.

Conclusion

The above two changes are the only changes made to HierMenus v6.0.2; and in fact the only file that saw any significant changes in this release is HM_ScriptDOM.js (so if you are upgrading from 6.0.1, it should be adequate to simply replace your existing HM_ScriptDOM.js with the new version, if you like). Again, if you suspect these two problems may occur in your particular implementation, it is recommended that you apply the upgrade.