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.
(That test thinks it passes because of bug 581863.)
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.
Component: DOM: Core & HTML → Widget: Gtk
QA Contact: general → gtk
Assignee: diogo.gmt → nobody
Hardware: x86_64 → All
You need to log in before you can comment on or make changes to this bug.