6.0 Introduction

Perhaps the most controversial aspect of applying DHTML techniques to web sites is messing with the browser window or windowing system. On the one hand, windows are pretty much outside the scope of Dynamic HTML, in as much as windows are merely containers for documents that adhere to one object model or another. But since the earliest days, windows have been part of the scripter's bag of tricks, standing ready to enhance a user's experience or torment the user with a variety of unexpected nonsense.

Most activity surrounding windows involves the window object. Although the window object has gained a large number of properties and methods over the years, the implementation across browsers is far from uniform. Part of the reason behind the disparity of window object features in browsers is that the window object is the most global context for scripting tasks. Browsers such as Internet Explorer for Windows take advantage of this context to embed numerous properties and methods that are tied to the browser application and the Windows operating system. In contrast, Netscape Navigator (especially since Version 4) empowers the window object with properties that are so potentially threatening to user privacy that they are accessible only through scripts that are electronically tagged on the server as being from a source to whom the user has explicitly given permission to operate (called signed scripts).

6.0.1 Window Abuse

It's unfortunate that unscrupulous web sites have abused the privilege of opening one or more additional windows automatically with JavaScript. The result has been the dreaded "pop-up" or "pop-under" advertisement that so many users find annoying. Most of us at one time or another have accidentally arrived at a web site that drops us into "pop-up hell," where each window you close opens one or more additional windows of equally unwanted content. The problem has gotten so out of hand that some Internet service providers filter web pages to strip out the offending JavaScript code that opens subsidiary windows. As often happens with antiabuse software, however, these kinds of "pop-up blockers" can also block well-intentioned and otherwise harmless secondary windows. Also, some users go so far as to turn off scripting in their browsers, thus preventing them from gaining any advantages added to sites employing Dynamic HTML. As a middle ground, some recent browsers include user preference settings that block some or all scripted window-opening actions.

Pop-up blocking is becoming so prevalent these days, it may be sending you a message with regard to your own development: do your best to keep everything in a single window. If a user wishes to open one of your links in a new window, a choice from the browser's context menu allows this without any difficulty. Or, you can simulate a window in modern browsers with positioned elements (see Recipe 6.10).

6.0.2 Window No-Nos

The more you might like to control the user's window line up to control the viewing experience of your web site, the less that browsers allow such activity. Numerous security holes would exist if the browsers and scripting engines didn't have substantial safeguards built into them (some holes did exist in earlier browsers, but they are patched in the predominant versions surfing the Web today). Therefore, before you get any big ideas about window trickery, here is a compendium of the things you cannot do with scripted windows, even if your intentions are good ones:

Modifying main window chrome: While you can resize and reposition the main browser window (Recipe 6.1, Recipe 6.2, and Recipe 6.3), you cannot add or remove window chromethe menu bar, status bar, scrollbars, resizing widgets, toolbars, and titlebar. Navigator 4 or later lets you do this with signed scripts, but the user is queried for permission first, so you won't be able to do this without the user's knowledge. The only way to customize a window with regard to window chrome is by opening a brand new window. As you can see in Recipe 6.4, you can choose the chrome features that you want on or off in the new window.
Closing the main window from a script in a subwindow: If you attempt to close the main window via the close( ) method (specifically, the opener.close( ) method), the user sees an alert dialog that requests permission to let the main window be closed. This warning prevents a script in a subwindow from automatically closing the main window that contains recent browser history. If the subwindow has no menu bar or titlebar, automatically closing the main window could leave the casual browser user in a pickle.
Closing other windows not created by the main window document's script: As yet, none of the browser object models provides a property that returns an array of available window references. If your page arrives in someone's browser, but is in one of several open windows, scripts in your document cannot reference the other windows, or even know how many windows are open.
Accessing document properties from other windows served by other domains: It could be potentially nasty business if a script in one window could look into another window and retrieve its URL or any of its HTML content. Browsers implement what is known as a same-origin security policy, which means that a script in one window (or frame) can not access critical details (URL, DOM structure, form control settings, text content) from another window (or frame) unless both pages are delivered by the same domain and server and arrived via the same protocol (such as HTTP or HTTPS, but not both).
Intercepting or activating most browser application window buttons: Many scripters would like to intercept the Back and Forward buttons to control navigation, but these user actions do not expose themselves to the window object. At most, JavaScript can recreate the equivalent of clicking the Print button, but the Print dialog window always appears, and the user must click the appropriate button in that dialog box to initiate printing.
Changing the content of the Address/Location text field: Scripts cannot override the browser's display of the current page's URL as requested from the server. The only change scripts can make in this regard is to load another page into the window (via the location.href property), but then the window's rendered content changes to the new destination URL.
Adding or removing entries in the Favorites/Bookmarks list: The closest one can come to automatically adding the current page to the Favorites list is in IE for Windows (via the window.external.AddFavorite("URL", "title") method). But even then, the browser asks for the user's permission before adding the item to the Favorites list. This list is private to the user, and is not exposed to scripts.
Modifying browser preferences: Navigator 4 or later lets signed scripts (again, with the user's permission) modify application preferences. This was built in as a networked administrative function, and is not intended for web site scripts.

The list of things you cannot do with the window object is long, but if you study the items carefully, you'll realize that although these taboo tasks may be common in standalone applications, they can be downright dangerous in an Internet environment. Respect every visitor's right to privacy and window layout.