This avoids a redundant alloc and copy in `PutBuffer`. All existing callers
were destroying the passed in buffer after the call.
--HG--
extra : rebase_source : 065505219d70d26bad49c7eba2cec8edf0e9939d
extra : amend_source : 118eddad4dc901da02817c788fb98f6f4c85a3f0
extra : source : 7f0cedfb4bd85bfe1a523168019864c9c6c0e665
This avoids a redundant alloc and copy in `PutBuffer`. All existing callers
were destroying the passed in buffer after the call.
--HG--
extra : rebase_source : 39a21686becedf32c38e58fa832ae47845b2f5e0
"Include what you use."
--HG--
extra : rebase_source : 2239a380029e0efbc9dd3042459222a67c38d70f
extra : amend_source : 4453c32cc469caa592049167205666997f1a1e7b
extra : histedit_source : a533edd4a4d3d0642b08989e93674661d27baa6a%2C37d27eeef9580381ccc0de8507f60166dabf1730
The error handling logic here would fail to remove a stale raw pointer from
mInProgressImports if the EnsureURI() call failed. Fortunately, it's not
actually possible for EnsureURI() to fail in this case, because the
EnsureResolvedURI() call above already implies EnsureURI(). That said, we're
better off structuring this code to ensure that we never leave a value in
mInProgressImports after we exit the scope.
MozReview-Commit-ID: 8mnKcHL75x
--HG--
extra : rebase_source : 332b48fde97adacfefd7771185df35c217dfbe84
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
This helper makes it easy to lazily import a JavaScript module the first time
one of its exports is required. It is intended to replace
XPCOMUtils.defineLazyModuleGetter, which has similar functionality but is much
less efficient.
MozReview-Commit-ID: 2zxXYwrn3Dr
--HG--
extra : rebase_source : 998de7388ee03fdec0a0949b4e43bd9169dbb592
extra : histedit_source : 414d0ed1842b2270146d37b2788a56c682d3d695
Looking up and copying exported properties each time a module is loaded is
fairly expensive at the best of times. It's even more expensive when we only
want to export a subset of symbols, which generally requires creating a
temporary object to hold the exports, or fetching them directly from the
returned global.
Aside from making the general case a bit faster, storing exports on an object
allows us to optimize lazy module imports by fetching imported symbols
directly from the exports object with very little additional overhead.
MozReview-Commit-ID: C9PGoXPNmsh
--HG--
extra : rebase_source : 6232cf7a52fd69ebeb8b6e39680646f287c272a8
extra : histedit_source : b223c73a6e9092491f4fb09f8c795f5aa4b43df3
This removes an unnecessary level of indirection by replacing all
nsStringGlue.h instances with just nsString.h.
--HG--
extra : rebase_source : 340989240af4018f3ebfd92826ae11b0cb46d019
The crash reports for this section of code suggest that in some cases, we're
ending up with a null Omnijar archive when trying to pre-load files. Since the
pre-load file list is determined in the previous session, and the startup
cache (where the pre-load list is stored) is cleared whenever the build ID
changes, it should never be possible for the given omnijar archive to be
missing here.
These crashes also tend to appear in conjunction with crashes due to failures
in the GetSharedGlobal function, and may have a similar cause.
This change adds better diagnostic information to these crashes, and should at
least tell us which omnijar archive we're failing to get, and the archive path
that caused us to load that archive. It may not tell us much, but it may point
to data corruption, or provide some other clues.
MozReview-Commit-ID: EKq3r4eG5ii
--HG--
extra : rebase_source : 745f99b8d5d7fbbf8511b62082d224899cdff947
Since we don't currently know where or how loading the service is failing, we
need logging in two places:
1) In ServiceWorkerRegistrar, which will tell us about any JS errors that
occur in the factory constructor.
2) In the XPConnect module loader, which will tell us about any JS errors
which happen while loading the top-level module script.
If the load fails due to a non-JS error, we'll simply get a nsresult failure
code, which well be less informative, but will still tell us something about
the failure mode.
MozReview-Commit-ID: 1CsDegJfiho
--HG--
extra : rebase_source : c998e0393d3cb8aca008da47dfce985d0c3affb6
mozJSComponentLoader is created using XPCOM. However, you can only
call it once or it'll crash. This patch fixes that by using a
singleton macro.
MozReview-Commit-ID: Bq2k7nv9dKA
--HG--
extra : rebase_source : d2008da7628edf5db283c8a44c17e741f7ae0a96
It's easy to mess up the scoping so that (a) the label is pushed and then
immediately popped, and/or (b) the string doesn't live long enough. It's also
easy to do a utf16-to-utf8 conversion unnecessarily when the profiler is
inactive. This patch splits that macro into three new ones that are harder to
mess up.
- AUTO_PROFILER_LABEL_DYNAMIC_CSTR: same as current.
- AUTO_PROFILER_LABEL_DYNAMIC_NSCSTRING: for nsCStrings.
- AUTO_PROFILER_LABEL_DYNAMIC_LOSSY_NSSTRING: for nsStrings.
--HG--
extra : rebase_source : 3e2bbec4737b696e1c86579ae54be4cb3186c100
The URLPreloader's initialization code accesses the Omnijar cache off-main
thread. It can do so safely only as long as the main thread is blocked, or
running code which is guaranteed never to touch Omnijar, while its critical
section runs.
While that was guaranteed for previous versions of the code, some invariants
changed when we began using the component loader's shared global for initial
compilation. Once the global is created, we can safely use it to initialize
compilation. But creating the global invokes a large amount of Gecko code,
some of which touches Omnijar in the process.
MozReview-Commit-ID: 48WoIZtGPTo
--HG--
extra : rebase_source : 9bd5d884e32cfa59c022edb00078aac050acb20b
XPCOM's string API doesn't have the notion of a "null string". But it does have
the notion of a "void string" (or "voided string"), and that's what these
functions are returning. So the names should reflect that.
--HG--
extra : rebase_source : 4e3f982e0873877174a08a25413595ff66f7d20e
The script precompiler needs to begin its work very early in the startup
process in order to be effective. At the moment, this means before user
preferences are loaded. It also needs to be able to compile scripts into
the shared JSM global when that's in use, in order to avoid unnecessary script
clones.
Since we can't know whether global sharing is enabled by that point, instead,
we just always compile module scripts into the shared module global rather
than the XPC compillation scope.
This also changes the global sharing tests to make a failure to respect the
user preference value a fatal error.
MozReview-Commit-ID: G0NkSOl2vU9
--HG--
extra : rebase_source : 4b5e1b10c14dd5cc6609bc589310d12b44f830f5