home / bulletins / 10

[next]

HierMenus 5.3.1: Release Notes

D.M Ragle, November 20, 2003

With new browsers come new problems, prompting this HierMenus maintenance release. Both the latest Safari (1.1) and Opera (7.21, 7.22) releases triggered errors, specifically in cross-frames scenarios, which are now corrected in HierMenus 5.3.1. If you have a cross-frames implementation and you need to support Opera and/or Safari, upgrading to HM 5.3.1 is highly recommended.

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

Sample Pages

Our sample pages demonstrate both frames and non-frames HierMenus displays. Each sample page opens in a new window.

Safari 1.1 and the Spinning Wheel

Safari 1.1 was made available in late October, as part of the Mac OS X Panther release. Shortly thereafter we were alerted to a problem in HM cross-frames scenarios; specifically, when attempting to click through to the second or subsequent pages of a frameset, the browser would lock up, displaying the colored spinning wheel icon and requiring that we force quit the browser. Needless to say, this made cross-frames HM sites all but unusable for Safari 1.1.

The "lock up" was an infinite loop, triggered due to Safari's unique handling of prototype values. While most other browsers resolve prototype values based on where (i.e., in which window) the function being called was originally defined, Safari instead appears to resolve prototype values based on where (in which window) the function was actually assigned. Assume, for example, that a function, say someFunction were defined in Frame A, but then assigned to a handler in Frame B from within Frame B (i.e., the actual assignment occured within Frame B). When this handler was triggered, the function would resolve prototype values based on the prototype settings of Frame B, and not Frame A. The same function, however, if assigned to a handler in Frame B from Frame A (the actual assignment occured within Frame A) would resolve prototype values as they were set in Frame A. This unique behavior appears to occur only with primitive values (i.e., numbers, booleans, etc). Reference values always appear to be resolved based on the window in which the value was defined.

The following example page, which will open in a new window, may help to demonstrate this point. In this two frame page, we assign prototypes to both numbers and arrays. In the top frame, we assign these prototype parameters a value of true, while in the lower frame we assign them a value of false:

Number.prototype.z=true;
Array.prototype.z=true;

By clicking each of the "Show Values" links, you will execute a function defined in the top frame that reports the values of various variables defined within that frame, and others that are local to the function itself. "Show Values 1" simply calls the function directly from within the top frame, while "Show Values 2" calls the same function from within the lower frame. The final two links in the lower frame initially have no onclick handler; you assign it by clicking the assignment links. "Show Values 3" is assigned by clicking the assignment link in the lower frame, "Show Values 4" is assigned by clicking the assignment link in the top frame. After assigning these functions, go ahead and click the remaining "Show Values" links.

Safari and prototypes in cross-frame scenarios

The result of your clicks is that Safari will report differing results depending on where the function was assigned. Since "Show Values 1" and "Show Values 4" are both assigned within the top frame, you would expect that they would produce identical results; likewise for "Show Values 2" and "Show Values 3." And that is indeed the case with Safari 1.1. In most other browsers, however, all four "Show Values" links produce identical results.

Note: In the case of "Show Values 2", even though the handler of the link is set via attribute (with an embedded function call):

onclick="return top.frames['nav'].doThingies();"

It still reports prototypes based on the lower frame. Or, in other words, all sub-functions within the main function will resolve prototype values based on the first function in the chain, in this case the onclick handler itself (and more specifically, based on the window where the topmost function was assigned).

As it turns out, this specific scenario only occurs once in HierMenus. It can be worked around in various ways, including duplicating our prototype assignments in all frames of a frameset to ensure that they're available regardless of where the function was actually assigned (we implemented a similar type of fix for Opera 7 when HM 5 was first released). Of greater interest is to ask ourselves why this problem only surfaces in Safari 1.1, and not 1.0. The HM code, after all, was not changed between these two releases.

The answer lies in our handling of the onload handler for frame tags. Recall from earlier discussions that we cannot reliably set this onload handler directly in Internet Explorer (even though it is supported), and further, that the handler itself is not available at all in Safari 1.0. Safari 1.1, however, changes this, by offering support both for the frame onload and its direct assignment via the frameElement.addEventListener method. Our fix, therefore, is simple: for Safari 1.1 we allow the direct assignment of this load handler (the preferred method for monitoring page reloads, anyway) and for earlier Safaris (or Safaris in which we cannot reliably determine the version number due to spoofing), we bypass the indirect handler assignment method which was intended to catch those browsers that supported frame onloads but did not support their direct assignments. Since this change results in the frame load being assigned directly from within our navigation frame (where the prototypes are also assigned), or being bypassed completely, the prototype problem is effectively removed.

We'd like to thank Pete Gomersall of Northern Arizona University for being the first to point out this problem.

One new browser down, one new browser to go. Read on for changes to help deal with a page scrolling related menu problem in the latest Opera browsers...

[next]