mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-10-09 03:15:11 +00:00
dcd5c4908e
It seems that the layout system assumes those attributes are for size of
the <window> element, i.e. inner window size, not outer window size.
See for example nsContainerFrame::SyncWindowProperties. It reads
{min,max}{width,height} attributes from the element via
nsIFrame::GetXUL{Min,Max}Size, and passes them into SetSizeConstraints.
The latter inflates the sizes with window decoration size before calling
into widget code. It can also be seen that various XUL size related
methods on nsBox and nsIFrame put the same assumption.
The test test_windowminmaxsize.xul apparently puts the same assumption
as the layout system on the meaning of those properties.
(Another test test_resize_move_windows.xul, which tests effectiveness of
features of window.open, also fails if we size the window earlier than
current in bug 1439875, and doesn't fail with this patch on top. It may
indicate that it makes use of the same assumption, but I can't really
figure out how it does so.)
MozReview-Commit-ID: IdMwDc59Ltg
--HG--
extra : rebase_source : ae46c23e450f556cc4608b512890c4e27cf8623e
|
||
|---|---|---|
| .. | ||
| test | ||
| LiveResizeListener.h | ||
| moz.build | ||
| nsAppShellCID.h | ||
| nsAppShellFactory.cpp | ||
| nsAppShellService.cpp | ||
| nsAppShellService.h | ||
| nsAppShellWindowEnumerator.cpp | ||
| nsAppShellWindowEnumerator.h | ||
| nsChromeTreeOwner.cpp | ||
| nsChromeTreeOwner.h | ||
| nsContentTreeOwner.cpp | ||
| nsContentTreeOwner.h | ||
| nsIAppShellService.idl | ||
| nsIPopupWindowManager.idl | ||
| nsIWindowlessBrowser.idl | ||
| nsIWindowMediator.idl | ||
| nsIWindowMediatorListener.idl | ||
| nsIXULBrowserWindow.idl | ||
| nsIXULWindow.idl | ||
| nsWebShellWindow.cpp | ||
| nsWebShellWindow.h | ||
| nsWindowMediator.cpp | ||
| nsWindowMediator.h | ||
| nsXULWindow.cpp | ||
| nsXULWindow.h | ||