Current Document Object Model reference documentation for Microsoft Internet Explorer is available at:
  <http://msdn.microsoft.com/workshop/author/dhtml/reference/dhtml_reference_entry.asp>

Current Document Object Model reference documentation for Mozilla (Netscape) is available at:
  <http://www.mozilla.org/docs/dom/domref/>

• intercept the "Back" or "Forward" browser buttons?
• read or write random text files on the local disk or on the server?
• automatically print the current document without user interaction?
• control browser e-mail or news reader windows and menus?
• access or modify browser preferences settings?
• capture a visitor's e-mail address without the user's knowledge?
• quietly send me an e-mail when a visitor comes to my Web site?
• launch client processes (e.g.,Unix sendmail,Win apps,Mac scripts)?
• change the current browser window "chrome" (menus, bars, etc.)?
• get rid of that dumb "JavaScript Alert:" line in alert dialogs?
• insert my site into the Favorites/Bookmarks list wiihout user interaction?

Add to that the difficulties surrounding the proprietary Netscape 4 stuff that was abandoned in Netscape 6 and later in favor of standards (um, recommendations) published by the World Wide Web Consortium (W3C), and it's a pickle.

The scripting and object models of today's browsers are far more complex than the early days. My books address the strategic questions you need to ask yourself before undertaking JavaScript and Dynamic HTML development projects.

If you have a pressing need for a solution, I recommend getting help from public forums where experts hang out. Two of my favorites are the JS-Jive Yahoo Group and the evolt.org mailing list. The comp.lang.javascript newsgroup can also help.

var newWind;
function makeNewWindow() {
    newWind = window.open("xxx","xxx","xxx"); // u fill in blanks
}


To access items in the new window from the original window, the 'newWind' variable must not be damaged (by unloading), because it contains the only reference to the other window you can use (the name you assign as the second parameter of open() is not valid for scripted window references; only for TARGET attributes). To access a form element property in the new window, use:

newWind.document.formName.elementName.propertyName

From the new window, the 'opener' property is a reference to the original window (or frame, if the window.open() call was made from a frame). To reference a form element in the original window:

opener.document.formName.elementName.propertyName

Finally, if the new window was opened from one frame in the main browser window, and a script in the new window needs access to another frame in the main browser window, use:

opener.parent.otherFrameName.document.formName. ...

Going in the other direction, a subwindow may only attempt to close its opener. Even so, security mechanisms always force the display of a user confirmation alert before allowing the close() method to complete its task.

1. Click Start, and then click Run.
2. In the Open box, type the following line: regsvr32 actxprxy.dll
3. Click OK, and then click OK again when you receive the following message: DllRegisterServer in actxprxy.dll succeeded.
4. Click Start, and then click Run.
5. In the Open box, type the following line: regsvr32 shdocvw.dll
6. Click OK, then click OK again when you receive the following message: DllRegisterServer in shdocvw.dll succeeded.
7. Shut down and restart your computer.

Fortunately, the problem occurs less frequently these days, as users have upgraded to newer Windows versions.

A more secure way is to set the password to be the name or pathname of the HTML file on your site that is the 'true' starting page. Set the location to the value entered into the field. Entry of a bogus password yields an 'invalid URL' error.

If the protected pages need additional security (e.g., an infidel has managed to get the complete URL), you might also consider setting a temporary cookie on the password page; then test for the existence of that cookie upon entry to every protected page, and throw the infidel back to the password page.

The error can also occur if scripts try to access objects, properties, or methods that have been locked down by Microsoft's security platoon. For instance, the document.styleSheets.rules property used to be accessible in IE 5 and IE 5.5, but is not in IE 6.

For the new window problem, there is a bit of history associated with the problem and workarounds. For example, the problem occurs frequently when the scripts are being run from the local hard disk. You get a clue about the situation in the titlebar of the new window: It forces an about:blank URL to the new window, which is a protocol:domain that differs from wherever your main window's script comes from. If, however, you put the same main window document on a server, and access it via http:, the problem goes away.

There is a workaround for the local-only problem: In the first parameter of the window.open() method call, load a real document (even if it is a content-free HTML document) into the sub-window before using document.write() to generate content for the subwindow. The loading action 'legitimizes' the window as coming from the same domain as your main window's document.

(This solution does not affect scripts that load a page from a secure server into a separate window or frame. An http: protocol in one window and https: in the other--even if from the same server.domain--yield a security mismatch and "Access Denied." Setting the document.domain properties of both pages may solve the problem (but I am unable to test it for sure).)

For other situations (such as the document.styleSheets.cssRules problem, there are no workarounds, so you'll have to find another way around your task.

One more source of this error in IE occurs if you assign a too-long search string to a URL or a form (using the GET method) has lots of elements and data. The HTTP GET method has a built-in limit of approximately 512 characters. If you run into the problem, change the method to POST, which has no data length limit. But POST won't reflect the search string in the URL of the replacement page (in case you're expecting to parse that data as a way to convey data from one page to the next).

This situation makes debugging incredibly difficult without the help of Microsoft's Script Debugger or (my preference) running the script in another browser brand to get its take on the error. IE 5 for Macintosh and Netscape do a better job of pointing to script errors right off the bat.

Copyright your pages, watermark your images, and apply all the other non-techie ways of protecting your intellectual property. Forget the scripts.