Karl Tomlinson (:karlt) Reporter
	Description • 14 years ago

https://developer.mozilla.org/en/DOM/window.open#Position_and_size_features says

"outerHeight 
    Specifies the height of the whole browser window in pixels.
    This outerHeight value includes any/all present toolbar, window horizontal
    scrollbar (if present) and top and bottom window resizing borders. Minimal
    required value is 100.

    Note: since titlebar is always rendered, then requesting outerHeight=100
    will make the innerHeight of the browser window under the minimal 100 pixels.

toolkit/content/tests/chrome/test_screenPersistence.xul, for example, uses "outerHeight=200,outerWidth=200", but the window opened has size 200x200 client area *not* including titlebar or resizing borders.

	Karl Tomlinson (:karlt) Reporter
	Comment 1 • 14 years ago

(That test thinks it passes because of bug 581863.)

	Karl Tomlinson (:karlt) Reporter
	Comment 2 • 14 years ago

This may be a widget bug.  It is not clear what dimensions nsIWidget::Resize sets.

There are 3 interesting rectangles for top-level windows:

1) The frame rectangle.
   This includes window manager decorations.  i.e. titlebar and borders.
   This is what nsIWidget::GetScreenBounds returns.

2) The native window rectangle.
   This is the rectangle in which native event coordinates are interpreted.
   Perhaps this is what nsIWidget::GetBounds should return, and seems to
   correspond to the coordiantes in NS_MOVE events.

   This may be equal to the frame rectangle or smaller, depending on platform
   and implementation.

3) The client area rectangle.
   This is portion of the native window that does not include decorations.

The method nsIWidget::ResizeClient probably refers to the client area rectangle, though implementations are inconsistent in how offsets are treated.
nsBaseWidget::ResizeClient treats offsets as relative to the screen for top-level windows, while the WINNT port treats them as relative to the frame top-left.