JavaScript - JavaScript Mini-FAQ by Danny Goodman
JavaScript - JavaScript Mini-FAQ by Danny Goodman
By Danny Goodman
All materials Copyright © 1997−2002 Developer Shed, Inc. except where otherwise noted.
This Mini−FAQ is posted periodically to the comp.lang.javascript newsgroup. It covers the language through
JavaScript 1.2, the version deployed in Netscape Communicator 4.0x, plus some compatibility items with
Microsoft Internet Explorer 3.0x. The focus here is on client−side JavaScript.
Documentation for Microsoft's implementation of its core language (called JScript) is at:
• http://www.microsoft.com/JScript/us/techinfo/jsdocs.htm
Also be sure to download Microsoft's document object model description. You can find a link from:
• http://www.microsoft.com/JScript/
Documentation for JScript in Internet Explorer 4 is part of Microsoft's Internet Client SDK documentation:
• http://www.microsoft.com/msdn/sdk/inetsdk/asetup/
• read or write random text files on the local disk or on the server?
• invoke automatic printing of the current document?
• control browser e−mail, news reader, or bookmark windows and menus?
• access or modify browser preferences settings?
• capture a visitor's e−mail address or IP address?
• quietly send me an e−mail when a visitor loads my page?
• launch client processes (e.g.,Unix sendmail,Win apps,Mac scripts)?
• capture individual keystrokes?
• change a document's background .gif after the page has loaded?
• change the current browser window size, location, or options?
• get rid of that dumb "JavaScript Alert:" line in alert dialogs?
No, however many of these items are possible in Communicator 4.0. Those items perceived to be security
risks (e.g., access browser settings) require "signed JavaScript". MSIE JScript version 2 (see below) can
read/write local files via ActiveX−−but only from server−side scripting.
1
JavaScript Mini−FAQ
Why won't my script work under MS Internet Explorer 3 for the Mac? JScript is available on the Macintosh
starting with 3.0.1 (which is different from the Windows 3.01). I am still evaluating the Mac implementation,
whose object model and other support for JavaScript does not necessarily jive with the Windows version (e.g.,
the Mac version supports the Image object for mouse rollovers). MSIE 3.0.1 runs on Mac 68K and PPC.
Why won't my Navigator 3.0x script run under MSIE 3 for Windows 95?
Most language features and objects that are new in Navigator 3.0 are not supported in MSIE 3.0, although
several Navigator 3.0 items have been added to JScript version 2 (see below). Here's the quick list of items not
available in MSIE 3.0:
UNSUPPORTED OBJECTS
• Window
onerror closed blur() focus() scroll() onBlur= onFocus=
• Location
reload() replace()
• Document
applets[] domain embeds[] images[] URL
• Link
onMouseOut=
• Form
reset() onReset=
• (All Form Elements)
type
• Navigator
mimeTypes[] plugins[] javaEnabled()
• String
prototype split()
One more item: the <SCRIPT SRC="xxx.js"> facility for loading external JavaScript library files runs on the
copy of MSIE 3.02 for Windows that I use (with JScript.dll versions 1 and 2). However there are also reports
that this is not working for some users. Try specifying a complete URL for the SRC attribute.
2
JavaScript Mini−FAQ
IE4 adheres closely to a standard called ECMAScript, which is essentially the core JavaScript 1.1 language.
This does not cover the document object model (another standard being studied). Navigator 3 document
objects not supported in IE4 are:
FileUpload navigator.mimeTypes[] navigator.plugins[]
The JScript.dll shipping with IE4 is version 3.
3
JavaScript Mini−FAQ
After window.open(), how do I access objects and scripts in the other window?
First, be sure to assign an 'opener' property to the new window if you are using a version of JS that doesn't
do it automatically (Nav 3.0x and MSIE 3.0x do it automatically). The following script should be a part of
_every_ new window creation:
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.property
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.property
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. ...
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 (unfortunately, you cannot extract the
value property of a password object in Navigator 2.0x). 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.
What does the IE4 "Access Denied" error mean when accessing a new window?
The "Access Denied" error in any browser usually means that a script in one window or frame is trying to
4
JavaScript Mini−FAQ
access another window or frame whose document's domain is different from the document containing the
script. What can seem odd about this is that you get this error in IE4 frequently when a script in one window
generates a new window (with window.open()), and content for that other window is dynamically created
from the same script doing the opening. The focus() method also triggers the error.
In my experience, this occurs only 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).)
...............................................................................................................................................................................15