TOP

Mozilla 1.0 and higherMSIE 5 and higherOpera 6 and higherMozilla 1.0 and higherMSIE 5 and higherOpera 6 and higher
Mozilla 1.0 and higherMozilla 1.0 and higher
Mozilla 1.0 and higherMSIE 5 and higherOpera 6 and higherMozilla 1.0 and higherMSIE 5 and higherOpera 6 and higher
Mozilla 1.0 and higherMozilla 1.0 and higher
Mozilla 1.0 and higherMozilla 1.0 and higher
Mozilla 1.0 and higher
Mozilla 1.0 and higher
Mozilla 1.0 and higherMSIE 5 and higher
Mozilla 1.0 and higherMSIE 5 and higherMozilla 1.0 and higherMSIE 5 and higher
Mozilla 1.0 and higherMSIE 5 and higherMozilla 1.0 and higherMSIE 5 and higherOpera 6 and higher
Mozilla 1.0 and higherMSIE 5 and higherMozilla 1.0 and higher
Mozilla 1.0 and higherMSIE 5 and higherMozilla 1.0 and higherMSIE 5 and higher
Mozilla 1.0 and higherMozilla 1.0 and higher
Mozilla 1.0 and higherMozilla 1.0 and higher
Mozilla 1.0 and higher MSIE 5 and higher

Notes on this demo

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Minimal values for popup window dimensions (as gotten from Mozilla 1.2 beta 2002101908)

width and innerWidth: 105 pixels (one hundred five)
height and innerHeight: 150 pixels (one hundred fifty) (there is bug 176320 here; empirically, a secondary child [popup] window can be created and have 0 pixel of viewable content area because its outer dimensions will be truncated and the top chrome elements will be the ones viewable.)
outerWidth: 113 pixels (= 105 + 2 * width of window [re-]sizing borders/handles)
outerHeight: 100 pixels


Definitions of terms and to what they refer exactly

outerWidth/outerHeight is the width/height of the browser window including all chrome elements.

width/height is the width/height of the content area of the browser, the client area of the browser, the browser viewport (and it includes scrollbars if present). width/height is crossbrowser compatible with MSIE 5+ and Opera 7.

innerWidth/innerHeight is also the width/height of the content area of the browser, the client area of the browser, the browser viewport (and it also includes scrollbars if present). innerWidth/innerHeight is NOT crossbrowser compatible with MSIE.

refer to the Personal Toolbar in Mozilla-based browsers. In the window features list string, one can refer to "personalbar=yes" or to "directories=yes". The only but relevant difference is that directories is supported by MSIE 5+ whereas "personalbar=yes" is not supported by MSIE 5+. Directories in MSIE 5+ refers to the Links bar.


How conflictual values are resolved when creating a popup

outerWidth/outerHeight have precedence over width/height and innerWidth/Height settings. In other words, if you set outerWidth to 500 and width to 300 and in case it is impossible to meet both conditions, then only the outerWidth setting to 500 will be complied.
If you set outerWidth but do not set outerHeight, then the outerHeight value will be equal to the screen.availHeight value and this even if you have set a value to height or to innerHeight. In other words, the outerWidth value or the outerHeight value have both and respectively decisive precedence over width, innerWidth, height and innerHeight values. Here is the code where the precedence branching is made:
http://lxr.mozilla.org/seamonkey/source/embedding/components/windowwatcher/src/nsWindowWatcher.cpp#1510

width/height have precedence over innerWidth/innerHeight settings.
E.g. width set to 234
height set to 246
innerWidth set to 357
innerHeight set to 389
the popup created will have an innerWidth of 234 and innerHeight of 246.

If width is set and innerWidth is also set to a different value, then the width value will be taken and applied. If height is set and innerHeight is also set to a different value, then the width value will be taken and applied.

In case height is set and innerWidth is set but not width, then the values will be completed. width/height have precedence over innerWidth/innerHeight but not a precedence as strong as outerWidth/outerHeight.

left and top have precedence over screenX and screenY. If left and screenX have a setting, then left will be chosen. If left is set but top has no value and screenY has a value, then left and screenY will be the values of the popup. Here is the code where the precedence is made
http://lxr.mozilla.org/seamonkey/source/embedding/components/windowwatcher/src/nsWindowWatcher.cpp#1496

In conclusion, when specifying the dimensions and position coordinates of the popup window to be, the precedence works like this:

outerWidth/outerHeight >>>> width/height >> innerWidth/innerHeight

left/top >> screenX/screenY


Preferences settings necessary in order to best use this demo:
Preferences/Advanced/Scripts & Plugins settings

Edit/Preferences.../Category:Advanced/Scripts & Plugins/Allow scripts to:/Raise or lower windows
checkbox must be checked in order to give back focus to an already opened (but minimized) popup window.

Edit/Preferences.../Category:Advanced/Scripts & Plugins/Allow scripts to:/Move or resize existing windows
checkbox must be checked if you're going to use, test the sizeToContent feature.

On the left, the author settings and requests for the popup; on the right, the user's settings and veto on the author's requests

If you have
Edit/Preferences.../Category:Advanced/Scripts & Plugins/Allow scripts to:/Hide status bar
checkbox unchecked, then the status bar will always appear in the popup.


More info on how this demo works

The titlebar will always be generated; one can only remove the titlebar with a signed script. You can add or remove the string "titlebar=yes" with the checkbox.


The "resizable" setting determines if the popup window can be resized by the user.

Popup windows generated withOUT sizeToContent() have a resize event listener which will simply update the values in the form.

Not included in this demo: hotkeys and copyhistory features. It seems that hotkeys and copyhistory can not be disabled.

Popup window with setting chrome=yesChecking will remove menubar, personalbar (directories), toolbar, location bar and status bar if they were requested: scrollbars will appear if needed, even if they were not specifically requested.

Starting with Mozilla 1.7/Firefox 0.9, the chrome feature requires the UniversalBrowserWrite privilege (bug 244965). Without granted UniversalBrowserWrite privilege, the chrome feature is ignored.

Checking will make the popup stay on top/in front of the opener and will make it gain and keep the focus until the modal popup is disposed, closed: the user is forced to dismiss that window first before doing anything else with the parent window. A default beep (in Netscape 7.0x only) arising from the operating system will remind the user that he must dismiss the modal popup window first. Minimizing a modal popup window is not possible in Netscape 7.0x (but possible in Netscape 7.1) without minimizing the parent-opener window as well.

Starting with Mozilla 1.2.1, the modal feature requires the UniversalBrowserWrite privilege (bug 180048).

Dependent will close the popup windows automatically if the parent is closed. A window will also stay visible on top of, in front of the parent window. On the Windows platform, minimizing a dependent window (on the windows task bar) is possible only by minimizing the parent window.

Popup window in Netscape 7.x with setting dialog=no
Checking dialog will remove the menu system commands (Restore, Move, Size, Minimize, Maximize, Close Alt+F4) on the titlebar. This is only true in Netscape 7.0x. Mozilla 1.2+ and Netscape 7.1 will render menu system commands.
Popup window with setting dialog=yes; it has no minimize and no maximize icon on the titlebar
The minimize icon and the maximize icon on the titlebar will be removed.
Popup window in Netscape 7.x with setting dialog=yes
+

--------------------------------
If the web designer adds dialog=yes and minimizable=yes, then the popup window will display both minimize and close icons in the titlebar
The only usage of minimizable is to be able to have a window without menu system commands but with minimize and close icons. This applies only for Netscape 7.0x; Mozilla 1.2+ and Netscape 7.1 will have available and accessible menu system commands.

:

In the popup window with sizeToContent, there are 2 columns of inputs: the before and the after. The before column show the values before the making of, the call of the sizeToContent() method. The after column show the values before the making of, the call of the sizeToContent() method. That way one can see, evaluate the impact of the sizeToContent() method on the creation of the popup window.


How to best use this demo

To see how the   works, check the checkbox and then create 2 popup windows with the same settings, except, of course, the sizeToContent() setting. You can scroll down both popup windows with the PgUp/PgDn keys (or with the mouse scrollwheel) without resizing the windows.

The 2 popup windows will superpose themselves and you'll see the differentials created by the sizeToContent(). You can make either popup window cover the other by clicking again the "Create a popup window according to these settings"

Here's a screenshot of a possible example you could get.Comparison of 2 popup windows: one has been resized by the sizeToContent() method, the other has not


Findings

If you have not checked resizable but you have selected sizeToContent, then the popup will be resized. Interesting! I think this makes sense too. An author might want to size/resize the popup window to fit perfectly the content and then not allow the user to resize the popup window.

Mozilla should comply with the requested values/settings of screenX and screenY as long as no part of the content area gets outside the view of the user, gets masked, hidden. The statusbar of the popup may be masked or hidden by the window taskbar: I think this causes a small security issue. The scrollbar(s) and the window [re-]sizing borders/handles (4px each) can be masked or hidden.

The browser should comply with the requested values/settings of outerWidth/outerHeight, width/height and innerWidth/innerHeight as long as no part of the content area would get outside the view of the user. If that ever happens, then the popup window will be resized and be given the screen.availWidth/availHeight dimensions or (if given available space) the popup will be repositioned to the leftmost/topmost location/coordinates where all of the content area can be viewed.

If outerWidth is set to a value greater than the screen.availWidth values, then the outerWidth value is the screen.availWidth value and no horizontal scrollbar appear; the window gets truncated.

Setting an outerHeight value greater than the screen.availHeight value should NOT mask the window taskbar.

If outerHeight is set to a value greater than the screen.availHeight values, then the outerHeight value is the screen.availHeight value and no horizontal scrollbar appear; the window gets truncated. (there is still a slight difference here: it involves the height of the titlebar. It's a bug, most likely bug 176342)

A popup [child] window with scrollbars=yes will display scrollbars if a css selector has a declaration with relative, scalable values dependent (indirectly) on the size of the window. E.g.: a popup window with the css rule body {margin: 10%;} will generate scrollbars as the window is enlarged while the normal expectation would be the reverse. This is caused by the computed vertical margin value increasing as the window's width is enlarged. In such cases, the content increases along both x and y axis while only 1 dimension of the window is resized. (The obvious workaround here is to use absolute value units for margin.)

The same phenomenon could be expected with popup windows with css rule(s) where selector(s) use relative, scalable value dependent on the body node width/height value or the document root element width/height value. E.g.: p {width: 100%;} might produce unexpected result when the method sizeToContent is called on the popup window.


Additional documentation, references on the window.open( ) method:

Windows and dialogs:
http://www.mozilla.org/xpfe/xptoolkit/windows.html


List of all possible supported popup window features in Gecko-based browsers
https://bugzilla.mozilla.org/attachment.cgi?id=97365&action=view


interactive nsIDOMWindowInternal:open demo
http://www.din.or.jp/~hagi3/JavaScript/JSTips/Mozilla/Samples/winopen.htm


MDC reference on window.open( ):
http://developer.mozilla.org/en/docs/DOM:window.open


Netscape DevEdge on window.open( ):
http://devedge-temp.mozilla.org/library/manuals/2000/javascript/1.3/reference/window.html#1202731


http://web.archive.org/web/20021220082430/http://developer.netscape.com/ docs/technote/javascript/window/images/display_screen.gif

Signed Scripts in Mozilla: JavaScript Features Requiring Privileges
http://www.mozilla.org/projects/security/components/signed-scripts.html


MSDN2 on window.open( ) MSDN2 on document.open( )

Gecko DOM reference on window.opener:
http://developer.mozilla.org/en/docs/DOM:window.opener


MSDN2 reference on window.opener:
http://msdn2.microsoft.com/en-us/library/ms534309.aspx


List of bugzilla bugfiles on the window.open( ) method

Position and size/dimension related bugs

Bug 176320: Minimal innerWidth/innerHeight values for popup windows

Bug 149077: window.open produces incorrectly sized child-window

Chrome UI element and toolbar related bugs

Bug 75158: 'View' > 'Show/Hide' menu items can't override window.open flags

Bug 176304 (Firefox): Option to disallow scripts from hiding toolbars

Bug 26353: Can't turn chrome back on in chromeless window

Bug 69099: Alt/F10/context menu item to make hidden menubar visible

Enhancement requests and varia

Bug 176905: window.screenX and window.screenY should be read-only values

Bug 179704: Implement sizeToContent as a window feature, a window option in the window.open( ) method

Bug 214867: Don't let web pages use dependent=yes in window.open( )

Many thanks to Jim Ley :) for accepting to host this meta-demo case for me during 6 months. This was very much appreciated.

Valid HTML 4.01! CSS compliant