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
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <
Emilio Cobos Álvarez
Xidorn Quan
Florian Quèze
Andrew McCreight
Boris Zbarsky
Cosmin Sabou
Kris Maglione
Brindusan Cristian
Chris Peterson
Nika Layzell
Milan Sreckovic
Cameron McCormack
Samael Wang
Sebastian Hengst
Gijs Kruitbosch
Stephen A Pohl
Thomas Nguyen
Nicholas Nethercote
Eugen Sawin
Masatoshi Kimura
Brendan Dahl
Julian Seward