home / bulletins / 2 / page 7

[previous]

HierMenus 5.0: Cross-Browser Development Issues

The following is a sampler of some of the more interesting browser-specific issues we encountered while working through the HM5 code.

Internet Explorer

The biggest cross-browser issue pertaining specifically to Internet Explorer applies to IE5.5 and 6 and was described in detail on the previous page. In this browser, it would appear as though we cannot programatically set the load event of a frame, and thus we have to resort to a more user-dependent method of identifying and hooking the frame load handler.

We also came across an interesting IE specific issue in regards to access checking of the content page document. While we specifically avoid the firing of events from all browsers while the content page is reloading (to avoid firing an event on a page element that is in the process of being unloaded), we found that in IE6 if the page you are clicking through to triggers access denied errors (i.e., because it comes from another domain), then it is possible to fire events that receive those access denied errors before the unload of the existing page is fired. Or, in other words, the access denied errors begin before the unload of the page fires--the same unload that has the job of letting us know that it's not safe to fire the events against the document in the first place! Therefore, it's important for this browser to check the accessibility of the content frame's document before each and every HM event is fired.

Internet Explorer 5.x for Macintosh deserves special mention here. Though we tried multiple solutions (including some suggested by our testers), we were unable to find a combination of workarounds that would allow cross-frames usage in this browser. We've therefore disabled cross-frames functionality in this browser (and only cross-frames functionality, standard use of HM will continue to work fine). Some of the many problems we witnessed were corruption of elements when created and the disappearance or seemingly spontaneous resetting of element properties even after the elements were initially created and properly displayed. In another test case, we found that the on page menus appeared to be invisible, in that they could not be seen, but waving over the section of the page where the menu was supposed to be revealed that the menu was actually there. Clicking through to these "invisible" elements allowed the browser to follow the link, and the cursor changed to the link pointer cursor as the invisible links were rolled over! Though we were able to get IE5 Mac working in a few, very limited scenarios, we were unable to make it work consistently enough to support in the actual HM release. If you're interested in trying out Mac IE5 compatibility on your own system, drop us a note and we'll show you what to change to allow Mac IE5 through to the frames functionality (you'll be on your own, of course, though we'd love to hear about your results).

One other interesting Mac IE5 tidbit: when going forward or backward in your browser history to a page that is the same as the page you are currently on, the page you are currently on becomes the "historical" page, and the onload of this page is refired. In HM, we assume that the firing of the onload means that the menus must be rebuilt, and the result created errors when the menu creation logic attempted to recreate menu elements that already existed. Therefore, in Mac IE5 we check our HM_AreCreated variable before allowing the onload logic to refire.

Early Netscape 6

We all know the error handling capabilities of the earliest Netscape 6 releases (6.0/6.01) were problematic. In this browser we found that even after we had handled certain errors, they still appeared in the JavaScript console. Another interesting oddity is that the error message parameter passed to our event handlers in Netscape 6/6.01 itself cannot be accessed; as it triggers another access error! We therefore assume that all "caught" errors in Netscape 6/6.01 are access errors and proceed accordingly (this is not as bad an assumption as it sounds, remember that with our DOM based code we're using try..catch so access errors are the only ones we're legitimately expecting when our error handler is invoked).

Opera 7

Most of our Opera specific issues have already been discussed in our earlier HM5 status update. We're pleased to report that all but one of the issues described in that bulletin have been corrected in the latest Opera release, v7.10. The one remaining issue from that write-up is minor enough (when scrolling menus pass beneath an element that the mouse is over, even if you cannot see the text that passes beneath the element it is still "selected" by the browser) that we are supporting scrolling menus in Opera beginning with version 7.10.

Though not specifically frames related, an additional Opera concern that we discovered is the fact that, when going forward or backward to a page in the browser history using the browser's navigation buttons, the onunload of the page you are leaving does not fire, nor does the onload of the page you are going to. The net result of this is that the page can appear virtually instantly, however, this causes the HM script some confusion because of the fact that HM typically uses the onload handler to initialize the elements of the page and the unload handler to clear them. Thus, it's possible in Opera to go back to a page that has since had its menus cleared, and since the onload of that page won't fire the menus will not be rebuilt. The result? At best, no menus display or work at all; at worst what menus are there trigger JavaScript errors.

We've been able to work around this behavior for the most part by ensuring that HM does not clear its elements when moving from page to page in Opera. This seems to work quite well in almost all scenarios, however, we do occasionally still receive related errors especially in frames- based settings that we'll keep an eye on and hopefully rectify in a future release.

Konqueror 3.1

A minor rendering bug has been discovered by the Konquerer team specifically related to the display of variable-width vertical menus in Konquerer 3.1.x. This bug does not appear in Konquerer 3.0.x, and causes the menu widths and more image settings on some variable width menus to be incorrectly displayed (see the screen shot below). Interestingly, the error does not seem to appear on pages that are XHTML compliant, only in non-compliant pages that trigger Konquerer's "quirks" mode.

Still, the menus work properly, and the Konquerer team is analyzing the problem.

Safari

With the release of HierMenus 5.0 we are pleased to announce preliminary support for the Safari Web browser. "Preliminary" means that we have added (and will continue to add, if and when necessary) some Safari specific code in HM in an attempt to rectify some minor differences in that browser, but we will not, for the time being, officially support the use of Safari in HM. Also, bear in mind that Safari itself is currently in beta status, so it will no doubt continue to see changes and improvements as it steams towards its first milestone release.

Having said that, however, our first looks at Safari in HM are extremely encouraging; in fact, Safari users may have noticed that Safari already works in previous versions of HM! This is due to the fact that Safari identifies itself as a "Gecko" browser, and thus the conditional code we employ specific to Gecko based browsers applies to Safari as well. We have noticed a few minor problems with HM on Safari, however, and we mention them here for the curious.

In Safari, the CSS overflow property does not seem to function, causing us some problems in scrolling menus not totally unlike our early Opera 7 problems (see our previous status update). In Safari, overflow does not seem to be recognized at all, which means the items of our scrolling menus can be seen as they scroll up and down beyond the top and bottom borders of the menus themselves. To counter this, we've adjusted the window padding for Safari to be zero, which allows scrolling menus to occupy the entire of the visible window (thus the "visible" portion of the scrolling menu is outside the window boundary completely). Not perfect, but a decent initial workaround.

The resize event of windows also appears to not function correctly in Safari, which means once a permanently visible menu is displayed on a Web page, it will forever remain in that place (until the page is manually reloaded). This minor glitch will affect only those who are using permanently visible menus that are not absolutely positioned (i.e., that are positioned using some custom function that depends on the layout of the Web page itself, such as the HM_f_CenterMenu() function supplied in the loader file), or any menu configuration where HM_GL/PG_ClickKill is true. In this latter scenario, a menu could remain visible throughout the resize and be lost behind the new borders of the window itself.

Conclusion

HierMenus continues to thrive in large part due to the enthusiastic and helpful responses we receive directly from the Web development community. We'd like to thank all those (way too many to name) who have helped us out along the way by testing the HM code, suggesting new features, or even providing coding suggestions to improve HM. Keep those comments coming, as they allow us to continue providing the features and improvements that you most want to see!

[previous]