This page lists issues with the HM script that have either yet to be resolved,
or represent an issue in an older HM version that folks may still encounter from time to
time.
| Issue: | Menus covered by page components |
| Browser: | All |
| Platform: | All |
| [Note: this is the same issue as question #1 on our
Frequently Asked Questions page.] |
| Description: | Certain HTML page components,
most notably form selects (and in some browsers other form elements as well),
Java and Flash Applets, cannot be covered in some browsers by HierMenus. HM
will still work, but the menus will appear behind the problem components. |
| Cause: | Certain page components are
displayed in HTML pages by the browser using a "windowed" mode; i.e., the component
itself is displayed by the browser as if it is in its own, self-contained window.
For some browser/OS combinations, these elements cannot be overlaid with typical
DHTML elements (of the type created in HM), regardless of the Z-order of the
DHTML elements themselves. |
| Comments: | The extent of the problem
depends entirely on the browser and platform being used; later version
browsers, for example, are doing a much better job of eliminating the
problem then earlier version browsers did.
A possible HM work around for form and other select elements
is to hide the select element completely when the menu pops up, using the
UponDisplay/UponHide parameters. This would require the crafting
of some custom code on your part, but you can find some examples at the
pages below.
For a general discussion of the problem, see this page:
http://www.webreference.com/dhtml/diner/seethru/
And for a potential HM specific workaround, see these pages,
documenting the UponDisplay and UponHide parameters:
http://www.webreference.com/dhtml/column36/8.html
http://www.webreference.com/dhtml/column36/9.html
http://www.webreference.com/dhtml/column42/11.html
http://www.webreference.com/dhtml/column42/12.html
And more recently:
/bulletins/6/
Also note this addendum to the "seethru" discussion
above: In some browser/version combinations, Flash supports an
additional parameter called "wmode" (i.e., Windowless Mode) that,
when applied, allows DHTML elements to float over the top of the
Flash animation in certain browsers (IE6 included). See these
pages on Macromedia's site for further details:
http://www.macromedia.com/support/flash/ts/documents/wmode.htm
http://www.macromedia.com/support/flash/ts/documents/flash_top_layer.htm |
|
| Issue: | Frequent Image Rollovers Cause
Browser to Stop Responding |
| Browser: | Internet Explorer 5/5.5/6 |
| Platform: | Windows |
| Description: | In Internet Explorer, rolling
repeatedly and quickly over rollover images (i.e., images which change each
time the mouse rolls over them) can cause the browser to stop responding to
further local downloads (i.e., more images or new pages from the same server).
The page itself remains visible, and
the back buttons of the browser will typically work. But the user will be unable
to click through to any further pages within the same domain. Pages from external domains will be retrievable. In HM this error
can be triggered naturally with the use of "more" image rollovers. |
| Cause: | The cause is connection related, and
Microsoft has confirmed this behavior to be a bug as described in this knowledgebase article:
BUG: Internet Explorer Stops Responding When You Download Images
We've only been able to replicate the problem in HM when the Internet
Explorer cache setting is set to check for new versions on "Every Visit to the Page," however, some users
of customized Internet Explorer versions have noted that they can even receive the
error when the cache settings are set to "automatically." (Could the cache setting
displayed in Internet Options be different from the registry setting used for
cache purposes? See this Microsoft
Knowledge Base Entry for registry setting details.) |
| Comments: | Though not specifically HM
related (we are able to trigger the error via even simple rollover examples,
such as this one), HM can trigger this
error via its use of more image rollovers. Possible workarounds, therefore,
all involve reducing or eliminating the more image rollovers in your design:
- Have users change their cache settings to "Automatically."
- Do not use image rollovers; i.e., specifically set HM_GL_ImageSrcOver
and HM_GL_ImageSrcLeftOver to null. The initial
more images will still be displayed in this scenario; they simply won't
change color when the user rolls over menu items.
- Turn off more images completely via the Top More Images Visible
and Tree More Images Visible parameters of the menu arrays.
Note that when the error occurs, there is typically an accompanying memory
usage spike in the browser. We do not know if the memory spike causes the
error or the error causes the memory spike. Because of this, some users have
reported this issue as the IE Memory leak described below. That error, however,
only effects the loss of memory when moving from page to page; this error
can be triggered entirely within a single page.
Any additional information on this issue would be appreciated. If you have any
further information or other workarounds please feel free to share them:
IE Rollovers
|
| Posted: | April 24, 2003 |
|
| Issue: | Navigation Page Stops Responding After
Using Back Button |
| Browser: | Opera 7 |
| Platform: | Windows |
| Description: | In Opera 7, if you reload
a frameset (clicking the standard reload button on the upper tool bar), use
the back button to return to the previous page (which is the same as the
page you are on, since you reloaded), and then click through from that page
to a new page the navigation frame of the framset will become unresponsive.
It will respond to no further clicks or actions until it is explicitly reloaded
itself. The problem is demonstrated on this test page, which will open in
a new window.
Opera Frame Freezing Example |
| Cause: | Unknown. Appears to be a bug within
Opera itself. |
| Comments: | The bug seems to be completely
unrelated to HM usage; in fact, the example provided above uses no JavaScript
at all. But it can be mistaken for an HM problem since, in cross frames scenarios,
the menus are tied to links in the navigation frame. Since the entire navigation
page appears to freeze, the links will not function and therefore no menus are
displayed when the links are rolled over.
No work arounds are available at this time. Any additional information on this
issue would be greatly appreciated. If you have any further information on this
topic please feel free to share it:
Opera Freeze
|
| Posted: | November 14, 2003 |
|
| Issue: | Menus don't load when returning to
frameset page |
| Browser: | Opera 7 |
| Platform: | Windows |
| Description: | When returning to a frameset page
(via the browser's back/forward buttons) that contained menus the menus may refuse to
rebuild. In addition, a JavaScript Error to the effect of "HM_LoadElement (or Hbt) is
null or undefined" is generated in the JavaScript error console. |
| Cause: | The problem is memory cache related.
With memory caching turned on (the default for Opera), the error all but disappears;
but will still occasionally strike, presumably when the memory cache has been filled
and a historical page needs to be reloaded as a result. With memory caching off, the
error occurs every time you return (using the browser's back and forward buttons) to
an HM frameset page from a non-frameset page. In both cases, the exact cause of the
error is that the parent.document.body parameter of the scripts is reported
as undefined, and cannot therefore be hooked to properly initialize the
menus. |
| Comments: | While we can (and will, in future
releases) prevent the JavaScript error from showing in the console, we cannot
override the loading process in this case. Since the document structure itself
appears to be damaged, it would be unwise for us to attempt further document
manipulation in this instance anyway. Therefore, we know of no graceful work
around for this problem.
Any additional information on this issue would be greatly appreciated. If you have
any further information on this topic please feel free to share it:
Opera Parent
|
| Posted: | March 11, 2004 |
|
| Issue: | HTTP_REFERER environment variable is unavailable |
| Browser: | Internet Explorer, Netscape 6, Gecko Engine Browsers |
| Platform: | All platforms |
| Description: | Pages loaded through HM do not pass the HTTP_REFERER variable to the server. Many sites, especially commercial sites, use it for traffic logging. Its unavailability means that records will be incomplete. |
| Cause: | HM loads new pages dynamically, by setting the location.href property through JavaScript. For the user this is the same as clicking on a link defined with an <A> tag, and so it is for NS4. Browsers other than NS4 do not recognize this tautology and do not consider the current page as the referring page of the linked-to page unless an actual link (<A>) was clicked. |
| Posted: | August 06, 2001 |
|
| Issue: | HM not re-generated upon window resize if Flash embed co-exists on page |
| Browser: | Netscape 4 |
| Platform: | All platforms |
| Description: | Due to the nature of Netscape 4 DHTML, the HM must be re-generated if the user resizes the browser window. See: Ensuring DHTML Layout on Resize. The HM script captures the window resize event and reloads the page. If a Shockwave/Flash object exists on the page, the resize event is not fired when the user resizes the window, so any DHTML on the page is lost. |
| Cause: | The cause is unknown. It seems to be a NS4 bug. |
| Comments: | No workaround exists. Suggestions are requested. For example, how can Flash grab the resize event and pass it to NS4 JavaScript?
Please use this link to send mail if you have any insights and would like to share them:
HM4 FLASH Issue
|
| Posted: | August 06, 2001 |
|
| Issue: | HM Error Stops Menus when pages resized
multiple times in succession |
| Browser: | Netscape 4 |
| Platform: | All platforms |
| Description: | Due to the nature of Netscape
4 DHTML, the HM must be re-generated if the user resizes the browser window. See:
Ensuring DHTML Layout on
Resize. The HM script captures the window resize event and reloads
the page. However, if the resize itself takes place during the building of the
menus, corruption occurs in the script, and the menus from the original page
load cannot continue (nor, apparently, can they be halted by the resize event
itself). The result is a JavaScript error which halts further processing of
the menus. |
| Cause: | The cause is unknown, but appears
to be deeply linked to the Netscape 4 resize logic itself; i.e., code that existed
in the page and was executing before the resize began appears to continue executing
during the physical reload (but before the actual resize event is fired!).
Like the above, this seems to be a NS4 bug. |
| Comments: | No workaround exists (other than
having users reload their pages after resize, not a viable option). Suggestions
are requested. Please use this link to send mail if you have any insights and would
like to share them:
HM4 Resize Issue (NS4)
|
| Posted: | March 27, 2003 |
|
| Issue: | Access Violation Crashes browser when pages loaded
multiple times in succession |
| Browser: | Netscape 4 |
| Platform: | All platforms |
| Description: | A fatal error (browser crash)
can occur in Netscape 4.x when moving very quickly from page to page, loading
the next page before the previous page has finished loading. |
| Cause: | The cause is unknown, but the problem
seems at least similar to the resize problem above in that code that existed
in the page and was executing before the new page load began appears to continue
executing during the physical load. |
| Comments: | No workaround exists as of yet.
Suggestions are requested. Please use this link to send mail if you have any
insights and would like to share them:
Netscape 4 loading issue
|
| Posted: | June 27, 2003 |
|
| Issue: | Page displays square boxes or incorrect characters
in place of valid characters |
| Browser: | Netscape 4.x |
| Platform: | All platforms |
| Description: | After HM menus are created on
a page, Netscape 4 reverts the existing characters on the page to square boxes or
other illegible characters. This is triggered by a page "redraw," and is typically
intensified by scrolling the page. |
| Cause: | This is a known and somewhat infamous
problem when layers are written to dynamically via JavaScript (the technique
used in HM for NS4.x) on pages which utilize utf-8 encoding. When using
server-side page delivery methods such as ASP or PHP, note that the character
encoding for the page may be set by the server-side scripting engine in the page
header delivered to the browser; prompting some folks to note that the problem
"goes away" when they deliver their pages as .html pages instead of .php or
.asp (or .aspx). Typically, the real change is that the script page is
being sent with a different character encoding identifier than the .html
page. |
| Comments: | Unfortunately this is a bug in NS4.x
DHTML that we have no work-around for--other than to change your character encoding
designation on the page (or in your server-side scripting environment). MS has posted
one tip for the problem that you may find of interest (especially for ASP environments)
here:
http://support.microsoft.com/default.aspx?scid=kb;en-us;309548
Other suggestions are requested. Please use this link to send mail if you have any
insights and would like to share them:
Netscape 4 character problems
|
| Posted: | July 7, 2003 |
|
| Issue: | JavaScript Errors/Menus do not display/Permanent menus disappear immediately upon display |
| Browser: | Netscape 4.0x |
| Platform: | All platforms |
| Description: | Various errors can occur the first time
an HM page is loaded in a Netscape 4.0x browser when that page includes a specific charset
setting. Errors we've noted include "Cannot stack a layer on itself," "Can't convert
NaN to an Integer," and permanently displayed menus either not appearing when the
page is loaded or appearing and then instantly disappearing. In all cases, reloading
the page corrects the problem. |
| Cause: | Unknown, but possibly related to the
above issue. |
| Comments: | Note that this problem occurs only
in the 4.0x line of Netscape Navigator (4.0 - 4.08), and not in the later
4.x browsers. One work around is to simply remove the charset settings for only
those browsers, using server side sniffing of the UserAgent.
Other suggestions are requested. Please use this link to send mail if you have any
insights and would like to share them:
Netscape 4.0x charset settings
|
| Posted: | December 4, 2003 |
|
| Issue: | Page with display:block styling on an image will not complete loading |
| Browser: | Netscape 4.x |
| Platform: | All platforms |
| Description: | Pages that contain one or more
images that are forced to be block displays (style="display:block") can hang
during the loading process. |
| Cause: | Unknown. Appears to be a browser bug. |
| Comments: | In Netscape 4.x, the results of setting
images to display:block are often undesirable anyway; therefore the main work around is
to avoid using this display setting for NS4 (perhaps through the @import rule or
some other type of NS4 bypass).
Other suggestions are requested. Please use this link to send mail if you have any
insights and would like to share them:
Netscape 4.x img blocks
|
| Posted: | January 28, 2004 |
|
| Issue: | Variable width menus with word wrapping are forced to maximum width |
| Browser: | Safari |
| Platform: | Mac OS X |
| Description: | Items in variable width menus that
are word-wrapped (because the length of the supplied text is longer than the maximum
width of the menu) will be set to the menu's maximum width; and naturally if the item
in question is part of a vertical menu, then the vertical menu itself will be adjusted
to the maximum width. |
| Cause: | After wrapping the text in the menu item
cell, Safari continues to report the full width of the item as the width of the menu
item cell itself; as opposed to other browsers which report the width of the actual
text in the item. Therefore, HM has no way to know what the actual width of the text
within the item is, and assumes the maximum width of the menu should be applied. |
| Comments: | Typically only a minor annoyance; as the
menu does not expand beyond its maximum width and the line wrapping often occurs close
to the widest edge of the menu, anyway.
Other suggestions are requested. Please use this link to send mail if you have any
insights and would like to share them:
Safari Variable Width Menus
|
| Posted: | January 28, 2004 |
|
| Issue: | Displaying a menu causes page
or menu distortion |
| Browser: | IE 5 |
| Platform: | Macintosh OS X |
| Description: | When rolling over a menu
and displaying a child menu for the first time in Macintosh IE5 in OS X, the page
itself may become distorted (including the menu that spawned the child in
the first place, as it is part of the "page"). This "distortion" could be
a reformatting of the page content (a change in the widths of tables or
positioning of line breaks in text, for example) or even a general hiding
of some page content away from the menus. |
| Cause: | The cause appears to be related
to the process of downloading an image to the Mac IE5 browser; specifically,
the problem seems to appear most frequently when the menus are made visible
while an image is in the process of downloading to the page. This can
happen naturally in HM as the result of a more image rollover, i.e., roll
over a parent item, triggering the load of the new image for the "rolled
over" state. Simultaneously, HM displays the child menu for the item, often
before the more image for the parent item has finished downloading. Subsequent
displays of the menus are typically fine, since presumably the image has
been cached and no new download is required. |
| Comments: | Since the problem seems to
occur most frequently (and most naturally) with the use of more image
rollovers, potential work arounds include removing or delaying the
rollover image behavior. You can remove image rollovers by setting the
HM_GL_ImageSrcOver and HM_GL_ImageSrcLeftOver parameters
to null; and you can remove images entirely by setting the
top_more_images_visible/tree_more_images_visible parameters
of the arrays to 0. A better try, however, is to set the HoverTime
parameters to a higher number, forcing the display of child menus to be
slightly delayed (and therefore allowing the initial more image from the
parent menu to finish downloading before being displayed). Remember that
you can set the HoverTime variables conditionally, if you don't
want this delay to affect other browsers:
HM_GL_HoverTimeTop = (HM_Mac)?200:0;
Further suggestions on this issue are welcome! Please use this
link to send mail if you have any insights and would like to share them:
Mac/IE5 Page Distortion
|
| Posted: | June 11, 2003 |
|
| Issue: | Various Menu Display Inconsistencies |
| Browser: | IE 5 |
| Platform: | Macintosh |
| Description: | Various inconsistencies have
been reported from time to time in the Macintosh Internet Explorer 5 browser.
While these reports are infrequent in nature, they nonetheless occur often
enough to warrant a "Known Issues" entry. Some of the anomalies that we have
seen and or have been reported to us include:
- Menu doesn't appear when CreateTopOnly = true (even
though the menu appears to be built correctly).
- The bottom scroll bar in scrollable menus sometimes allows
portions of the menu items beneath it to "bleed through" the
scrollbar itself.
- Variable width menus are sometimes incorrectly proportioned.
|
| Cause: | We've not been able to
identify concrete causes or workarounds for these issues. Often, we
find that the particular behavior is tied specifically to a particular
HTML page layout. |
| Comments: | While it is one of the--if
not the--oldest of the DOM-standards compatible browsers, we've found that
Mac IE5 can, from time to time, display odd behavior when it comes to the
dynamic creation and display of HTML elements (it's primarily this odd
behavior which prohibits us from supporting IE5 Mac in cross-frames
scenarios). Many problem scenarios, however, can be solved via one or
more of the following adjustments:
- Set HM_GL_CreateTopOnly to false. Remember that you can
do this conditionally, i.e:
HM_GL_CreateTopOnly = (HM_Mac&&HM_IE) ? false : true;
Mac IE5 in particular is sometimes more consistent when menus are
created all at the same time at page load.
- Adjust your HTML. Sometimes the smallest difference in an HTML page
will allow the menus to render more consistently. In one recently
reported situation, we found that simply closing an open paragraph
tag (i.e., specifying <p> </p> instead
of <p> by itself) was enough to trigger correct menu
displays. We suggest a simple divide and conquer approach; start with
a blank page consisting only of a working HM setup, then add smallish
page blocks one at a time until the problem occurs.
- Use fixed-width menus, or set menus to be fixed width conditionally for
IE5 Mac. The following array segment does precisely this:
HM_Array2 = [[((HM_Mac&&HM_IE)?100:300),
,,,,,,,,0,0,0,0,,,,,,,
((HM_Mac&&HM_IE)?0:1), // top_is_variable_width
((HM_Mac&&HM_IE)?0:1)], // tree_is_variable_width
Further suggestions or insights on this issue are welcome!
Please use this link to send mail if you have any insights and/or test cases you
would like to share:
Mac/IE5 Menu Displays
|
| Posted: | June 25, 2003 |
|
| Issue: | Menu display incorrect with dir="rtl" |
| NOTE: This issue has been resolved as of HM version
5.3.
|
| Browser: | Internet Explorer 5+, Netscape 6+, Gecko |
| Platform: | All platforms |
| Description: | Menus do not always display properly on
pages that specify the dir attribute of "rtl" (typically in the body or html tag). Various
problems have been seen; including menus displaying in the wrong place on the page or not
at all, as well as menu items being left out of horizontal menus or incorrectly positioned
in horizontal menus. |
| Cause: | The cause of this problem has been traced
to multiple locations; including some bugs/ommissions in HM code as well as some
unique browser behaviors that required workarounds. These issues are described in
detail in the HM 5.3 release bulletin,
which is also when they were corrected. |
| Posted: | September 18, 2003 |
| Resolved: | HM
5.3
October 23, 2003 |
|
| Issue: | HM causing memory leak |
| NOTE: This issue has been resolved as of HM version
4.1.1.
|
| Browser: | Internet Explorer 5/6 |
| Platform: | Windows NT, Windows 2000, Macintosh |
| Description: | Memory allocated to a page with
HM is not freed when the user navigates away from the page, but only when IE
is closed. On the Macintosh, this causes a notable cumulative sluggishness in HM
creation on subsequent pages. On Windows, no HM creation speed problem is noted,
and user browsing experience is primarily unaffected. Of course, if the user
continues to visit pages with HM throughout the browser session, memory will
eventually run out, causing the browser to crash. |
| Cause: | Microsoft has published an article
in its Knowledge Base describing the basic problem:
Complex DHTML Pages Cause Memory Usage to Increase Beyond Bounds
The article states that it is an IE5.0 for Windows problem and was fixed in IE5.01 for Windows.
However, the HM memory issue has been reported with IE5 and IE6 for Windows
and IE5 for Macintosh.
This leads us to believe that either:
1. Microsoft did not correctly identify the problem, and therefore did not
fix it properly.
or
2. Microsoft identified the problem correctly, fixed it properly, but HM is
exposing a different, but related problem.
(this is our guess)
or
3. It is not an IE problem, but more of an HM problem.
[Many thanks to Phil Maland for bringing the above support link to our attention.]
|
| Comments: | A workaround was published
as part of HM4.1.1 (and all subsequent HM releases). See also "Frequent Image
Rollovers Cause Browser to Stop Responding" above. |
| Posted: | August 06, 2001 |
| Resolved: | HM
4.1.1
October 02, 2001 |
|
| Issue: | Rolling Repeatedly Over Menu Items
Causes Display Errors or Freezes |
| NOTE:
This issue has been resolved as of HM version 5.0.1.
|
| Browser: | Netscape Navigator 4.x |
| Platform: | Windows |
| Description: | Repeatedly rolling over menu
items for several minutes can cause Netscape Navigator 4.x to either crash
completely or incorrectly display menus. Some of the specific display problems we've
noticed include popping up the wrong child menus when rolling over items, and
menus that do not actually appear on the page until you actually roll over
the place where they are supposed to be displayed (i.e., the child menus "popup"
but are not actually visible until you roll over them). |
| Cause: | The exact cause is unknown.
The problem appears to be cross-frames and/or timer specific related, as we've
only seen the error appear in cross-frame settings where the HoverTime settings
were 0 (also the default). |
| Comments: |
This problem was addressed in HM 5.0.1. If you have any further information or
feedback you'd like to share with it, please feel free to send via the E-mail
link below:
NS4 Menu Mixup
|
| Posted: | April 24, 2003 |
| Resolved: | HM
5.0.1
May, 2003 |
|
