outerWidth / outerHeight features in window.openDialog do not include window manager decorations

NEW
Unassigned

Status

()

defect
P4
normal
9 years ago
3 months ago

People

(Reporter: karlt, Unassigned)

Tracking

(Blocks 1 bug)

Trunk
All
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: tpi:+)

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.)
(Reporter)

Updated

9 years ago
Blocks: 465880
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.
(Reporter)

Updated

9 years ago
Component: DOM: Core & HTML → Widget: Gtk
QA Contact: general → gtk
Assignee: nobody → diogo.gmt
(Reporter)

Updated

5 years ago
Duplicate of this bug: 1031177
Priority: -- → P4
Whiteboard: tpi:+
Duplicate of this bug: 1422647

No update since 7 years since Diogo assigned himself. Unassigning the bug.

Assignee: diogo.gmt → nobody
Hardware: x86_64 → All
You need to log in before you can comment on or make changes to this bug.