NullPrincipal::Create() (will null OA) may cause an OriginAttributes bypass.
We change Create() so OriginAttributes is no longer optional, and rename
Create() with no arguments to make it more explicit about what the caller is doing.
MozReview-Commit-ID: 7DQGlgh1tgJ
When SetSize etc. are called before OnChromeLoaded has been invoked,
the functions assume that the window initialization code wants to size
the window specifically, and thus ignore the values from the <window>
element.
However, bug 1439875 changes the behavior so that SizeShell is also
invoked before OnChromeLoaded, which confuses the functions above, and
causes some of the attributes not to be loaded properly.
This patch adds a separate flag to avoid ignoring those attributes when
those functions are invoked as part of SizeShell itself.
It can cause extra reflow if the window is opened in maximized state,
and thus the new whitelist items. They may be fixed by bug 1448199.
MozReview-Commit-ID: 7jT8w9KGmzy
--HG--
extra : rebase_source : d970be5b1ae0588f6b0b63e2bd6a711853c82478
I want this behind a pref so that I can investigate other bugs without building
locally.
MozReview-Commit-ID: FWbGUxNbbm
--HG--
extra : rebase_source : 546ace867858f17b543bd11ef908c10fa63a022f
When SetSize etc. are called before OnChromeLoaded has been invoked,
the functions assume that the window initialization code wants to size
the window specifically, and thus ignore the values from the <window>
element.
However, bug 1439875 changes the behavior so that SizeShell is also
invoked before OnChromeLoaded, which confuses the functions above, and
causes some of the attributes not to be loaded properly.
This patch adds a separate flag to avoid ignoring those attributes when
those functions are invoked as part of SizeShell itself.
MozReview-Commit-ID: 7jT8w9KGmzy
--HG--
extra : rebase_source : 7bcc0b1fe96207561fbfd255c976cce695c1da8f
The only subtle thing is the mCenterAfterLoad stuff, which is gated after a
mChromeLoaded.
Other than that it follows the same pattern as bug 345560.
MozReview-Commit-ID: 8qDiA2yn9DB
The only subtle thing is the mCenterAfterLoad stuff, which is gated after a
mChromeLoaded.
Other than that it follows the same pattern as bug 345560.
MozReview-Commit-ID: 8qDiA2yn9DB
--HG--
extra : rebase_source : 8ad309e3f449cea1536bfbff8e8b1585fefbc186
extra : source : f582644f846cee16b554d694d24b4eb8ca3c5106
The only subtle thing is the mCenterAfterLoad stuff, which is gated after a
mChromeLoaded.
Other than that it follows the same pattern as bug 345560.
MozReview-Commit-ID: 8qDiA2yn9DB
The only subtle thing is the mCenterAfterLoad stuff, which is gated after a
mChromeLoaded.
Other than that it follows the same pattern as bug 345560.
MozReview-Commit-ID: 8qDiA2yn9DB
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 {, <