The nsISimpleEnumerator contract specifies that GetNext() returns
NS_ERROR_FAILURE when iteration is complete. Several implementations, however,
either return NS_OK and a null result, or return some other error code, when
iteration is complete.
Since my initial implementation of the JS iteration stubs rely on the
contract-defined behavior of GetNext(), these need to be fixed before it can
land.
Differential Revision: https://phabricator.services.mozilla.com/D3726
--HG--
extra : rebase_source : aab0395df52e18ccff5b0a2489a983013bf484b1
extra : histedit_source : a5644f0a88799b4463af9dd01dfec33b373b1f58
In order to allow JS callers to use nsISimpleEnumerator instances with the JS
iteration protocol, we'll need to additional methods to every instance. Since
we currently have a large number of unrelated implementations, it would be
best if they could share the same implementation for the JS portion of the
protocol.
This patch adds a stub nsSimpleEnumerator base class, and updates all existing
implementations to inherit from it. A follow-up will add a new base interface
to this class, and implement the additional functionality required for JS
iteration.
Differential Revision: https://phabricator.services.mozilla.com/D3725
--HG--
extra : rebase_source : ad66d7b266856d5a750c772e4710679fab9434b1
extra : histedit_source : a83ebffbf2f0b191ba7de9007f73def6b9a955b8
Add BrowsingContext to allow the tree structure of docshells to exist
in several processes simultaneously. This is a first step towards
allowing a tree structure preserving separation of docshells across
processes.
--HG--
extra : histedit_source : d3c7f6ab4b9ae76f170c126d669ebd570e52f348
This changes the fingerprint resistance code to set mIgnoreXULSize and
mIgnoreXULSizeMode even when there isn't yet a primary content container,
if this is a browser window.
It also removes some dead code and reorders some other logic wrt
mIgnoreXULSizeMode to make it more obvious what that code is doing, and
renames the containing method to distinguish it more clearly from some
other Load...Attributes methods.
MozReview-Commit-ID: LJqRWeta6XV
--HG--
extra : rebase_source : 9d83c83aa2ee8d3314e3f94f157b956608e927d8
Add an anonymous XUL tooltip node to toplevel non-XUL windows. Setup a
nsXULTooltipListener on non-XUL nsXULWindows. Make nsXULTooltipListener
always use the default tooltip in the non-XUL case.
MozReview-Commit-ID: Koe5m8PwMQM
--HG--
extra : rebase_source : 242180e957758b51c589452e35deadac5ab06d9e
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
Previously, with early first paint enabled, nsXULWindow incorrectly loaded the
persisted window settings from about:blank and would only load them once.
Instead, load the settings before starting layout.
MozReview-Commit-ID: 6K4ofkbmHHb
--HG--
extra : rebase_source : 7bcd804cfabbd47ee5a747800a2ef81852213889
This should allow us to figure out what's killing the window mid-flight, in case
there's something to fix in the chrome JS code.
MozReview-Commit-ID: 1xx1AVdspB2
Using concrete class types with static IIDs in QueryInterface methods is a
pretty common pattern which isn't supported by any existing helper macros.
That's lead to separate ad-hoc implementations, with varying degrees of
dodginess, being scattered around the tree.
This patch adds a helper macro with a canonical (and safe) implementation, and
updates existing ad-hoc users to use it.
MozReview-Commit-ID: HaTGF7MN5Cv
--HG--
extra : rebase_source : ace930129d85960d22bc3048ca3bb19bbbd4a63e
extra : histedit_source : 03a87f746d957789d41381e4e1bfcc4fd7eebaf2%2C9c5bae9feeeef7721105db67be0f83e0ded66bb7
Move tracking of persistent window state into nsXULWindow. Also, move
special handling of the width/height of the window into nsXULWindow.
MozReview-Commit-ID: LOmHGyYeNSU
--HG--
extra : rebase_source : bcea16eb6209ff789948644a64968a7325cea4ef
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 {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
These were originally exposed directly as static methods on nsGlobalWindow, but
as they are clearly associated with either the inner or outer window, it makes
more sense for them to be called as such.
MozReview-Commit-ID: LFq8EfnhDlo
This is a large patch which tries to switch many of the external consumers of
nsGlobalWindow to instead use the new Inner or Outer variants.
MozReview-Commit-ID: 99648Lm46T5
Because nsAString is nicer to work with than char16_t*. The patch relatedly
changes nsIEmbeddingSiteWindow::title and nsIWindowMediator::updateWindowTitle
as well.
--HG--
extra : rebase_source : 0bf332dec3e09af6c39c676f8795b368768a6046
This is straightforward, with only two notable things.
- `#include "nsXPIDLString.h" is replaced with `#include "nsString.h"`
throughout, because all nsXPIDLString.h did was include nsString.h. The
exception is for files which already include nsString.h, in which case the
patch just removes the nsXPIDLString.h inclusion.
- The patch removes the |xpidl_string| gtest, but improves the |voided| test to
cover some of its ground, e.g. testing Adopt(nullptr).
--HG--
extra : rebase_source : 452cc4a08046a1adb1a8099a7e85a1917de5add8