Open
Bug 581866
Opened 14 years ago
Updated 2 years ago
outerWidth / outerHeight features in window.openDialog do not include window manager decorations
Categories
(Core :: Widget: Gtk, defect, P4)
Tracking
()
NEW
People
(Reporter: karlt, Unassigned)
References
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.
Reporter | ||
Comment 1•14 years ago
|
||
(That test thinks it passes because of bug 581863.)
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.
Reporter | ||
Updated•14 years ago
|
Component: DOM: Core & HTML → Widget: Gtk
QA Contact: general → gtk
Updated•13 years ago
|
Assignee: nobody → diogo.gmt
Updated•8 years ago
|
Priority: -- → P4
Whiteboard: tpi:+
Comment 5•6 years ago
|
||
No update since 7 years since Diogo assigned himself. Unassigning the bug.
Assignee: diogo.gmt → nobody
Hardware: x86_64 → All
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•