DHTML Lab: HierMenus CENTRAL: Version 3.x FAQ #5 - dhtmlab.com
Frequently Asked Question #5
Entered: Feb 15, 1999
|I am using the Hierarchical Menus with frames, a navigation frame and a main frame. Some of my menu items are links to other sites. The menus display properly in the main frame when first loaded but if I navigate to a URL located on a different server, the menus no longer appear. Why? What can I do to avoid this behavior?|
The reasons for the menus not appearing were first discussed in column 21. Below is an extract from the relevant page, explaining the why:
********* extract BEGIN
The hierarchical menus are, of course, DHTML-based. Which, in turn, makes them HTML-based. They are part of the page they appear in. Our script creates new elements in an already existing page. That is, we modify the page.
Since the menus are positioned elements, they float above other elements, giving the illusion that they are an appendage, or elements external to the page. This is not true. They are as much a part of the page as a <P> or <B> tag is.
When we use menus in a frameset, the page loaded into the main frame is modified by our script. The page is changed.
Both Navigator and Explorer do not allow modification of any page that does not reside on the same server as the page with the script that does the modifying. In other words, if you load a page into the main frame that is not yours, you cannot modify it, and by extension, you cannot make menus appear in that page. It is correct, welcome behavior that increases security.
Those of you who have tried, have seen error messages like these:
sample Navigator access error
sample Explorer access error 1
sample Explorer access error 2
********* extract END
In Navigator, you will get the menus back if you use the browser's Back button, since the menu re-creation code is based on the frameset's onload handler. The Explorer code uses the readyState property of the document, and since we cannot read this property from a foreign URL, the menus will not be re-created.
There are two things you can do to avoid this behavior:
If you must link to an external site, you can:
If you are having this problem, not with external URLs, but with pages in your own domain on different servers, you can override the browser security using the document.domain property:
Microsoft discusses it on this page in the INETSDK:
If you have pages on different servers, within the same domain, you may enable a script to access all pages, if you have the document.domain property in all these pages point to the same domain.
You have two servers, named boris and natasha, that reside in the bullwinkle.com domain. Their full domain would be:
boris.bullwinkle.com and natasha.bullwinkle.com
You have a page on boris called sherman.html and one on natasha called peabody.html. Script in sherman.html cannot read or write to peabody.html.
You must physically enter this statement in both pages:
document.domain = "bullwinkle.com"
Now, you can share scripts and read and write freely between the two pages. The menus will appear on both pages.
- Originally, the domain of sherman.html is boris.bullwinkle.com, and we change it with script to bullwinkle.com, that is, to a suffix of itself. We cannot change the domain to rocky.com or any name not in the original domain.
- Once you change the document.domain, it cannot be changed back. It is a write-once-only property.
Produced by Peter Belesis and
All Rights Reserved. Legal Notices.
Created: Dec 29, 1998
Revised: Oct 02, 2001