MOZ_CRASH_UNSAFE_PRINTF causes data collection because crash strings are annotated to crash-stats and are publicly visible. Firefox data stewards must do data review on usages of this macro. However, all the crash strings this patch collects with MOZ_CRASH_UNSAFE_PRINTF are already collected with NS_RUNTIMEABORT.
MozReview-Commit-ID: 5ujXa9MHH5Z
--HG--
extra : rebase_source : 1367e6ac3c6085341e36cb0859d91417245ea472
extra : source : 3edeb64a40afd79d5c01ae0f0d3ab2777a2e744b
It's no longer needed, now that legacy extensions aren't supported.
Pieces removed include the following.
- The "load-extension-default" observer notification.
- The code for reading defaults/preferences/*.js from extensions.
- The unit test for this stuff.
- A crash reporter annotation relating to very long prefs set by add-ons.
- All references to "ExtPrefDL".
MozReview-Commit-ID: KMBoYn3uZ3x
--HG--
extra : rebase_source : 4dc8ffd425c6cdf06806409090c4f9d04a64930b
This was created for B2G and isn't really useful otherwise. It only works on
Linux, and it's behind the memory.system_memory_reporter pref, which is false
by default.
The patch also removes LinuxUtils.{h,cpp}, which is no longer used.
--HG--
extra : rebase_source : b97a018be11a79f83855a73b88020bfa86e60f78
And remove unreachable code after MOZ_CRASH_UNSAFE_OOL().
MOZ_CRASH_UNSAFE_OOL causes data collection because crash strings are annotated to crash-stats and are publicly visible. Firefox data stewards must do data review on usages of this macro. However, all the crash strings this patch collects with MOZ_CRASH_UNSAFE_OOL are already collected with NS_RUNTIMEABORT.
MozReview-Commit-ID: IHmJfuxXSqw
--HG--
extra : rebase_source : 031f30934b58a7b87f960e57179641d44aefe5c5
extra : source : fe9f638a56a53c8721eecc4273dcc074c988546e
And remove unreachable code after MOZ_CRASH().
MozReview-Commit-ID: 6ShBtPRKYlF
--HG--
extra : rebase_source : 0fe45a59411bda663828336e2686707b550144ae
extra : source : 8473fd7333d2abe1ea1cc176510c292a5b34df45
Now that xpcom strings use templates we can combine their `ArenaStrdup`
implementations. `nsTStringRepr` is used so as to allow handling of both
`nsTLiteralString` and `nsTSubstring` types.
--HG--
extra : rebase_source : e77891da589f320507b45f524a3203b3dc9f38e6
extra : histedit_source : 79d3b9a1add191563e0985f0c0e416bd29f24351
This adds support for duplicating both raw `char*` strings and raw `char16_t*`
strings by making the character type generic.
--HG--
extra : rebase_source : bb5245ed71161c8c785684e5a56ac894f03874ea
extra : histedit_source : e94eb738a3982f0cb63a894a0cdfbdf0be2b9cad
Removes the XPCOM interface for nsIDOMHTMLMenuItemElement, replacing it
with binding class usage.
MozReview-Commit-ID: 9HtCmwKyV1W
--HG--
extra : rebase_source : d56ee91a46d48c9d8698765b520a585361813a26
It's a sub-class of nsAtom, useful for cases where you know you are dealing
exclusively with static atoms. The nice thing about it is that you can use
raw nsStaticAtom pointers instead of RefPtr<>. (In fact, the AddRef/Release
implementations ensure that we'll crash if we use RefPtr<nsStaticAtom>.)
MozReview-Commit-ID: 4Q6QHX5h44V
--HG--
extra : rebase_source : e4237f85b4821b684db0ef84d1f9c5e17cdee428
We can save the entry in the hashtable, and then re-use that entry as a
starting point for removing from the hashtable, should that become
necessary. This saves us having to rehash things, at a minimum.
Right now, NS_GENERIC_FACTORY_SINGLETON_CONSTRUCTOR expects singleton
constructors to return already-addrefed raw pointers, and while it accepts
constructors that return already_AddRefed, most existing don't do so.
Meanwhile, the convention elsewhere is that a raw pointer return value is
owned by the callee, and that the caller needs to addref it if it wants to
keep its own reference to it.
The difference in convention makes it easy to leak (I've definitely caused
more than one shutdown leak this way), so it would be better if we required
the singleton getters to return an explicit already_AddRefed, which would
behave the same for all callers.
This also cleans up several singleton constructors that left a dangling
pointer to their singletons when their initialization methods failed, when
they released their references without clearing their global raw pointers.
MozReview-Commit-ID: 9peyG4pRYcr
--HG--
extra : rebase_source : 2f5bd89c17cb554541be38444672a827c1392f3f
Defining Get() in the declaration of InputEventStatistics implicitly
sticks an "inline" on the function, which is not what we want: inlining
it spreads around a lot of static initialization code. Providing an
out-of-line definition is much better in terms of code size.
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
There are four things that must be provided for every static atom, two of which
have a macro:
- the atom pointer declaration (no macro);
- the atom pointer definition (no macro);
- the atom char buffer (NS_STATIC_ATOM_BUFFER);
- the StaticAtomSetup struct (NS_STATIC_ATOM_SETUP).
This patch introduces new macros for the first two things: NS_STATIC_ATOM_DECL
and NS_STATIC_ATOM_DEFN, and changes the arguments of the existing two macros
to make them easier to use (e.g. all the '##' concatenation now happens within
the macros).
One consequence of the change is that all static atoms must be within a class,
so the patch adds a couple of classes where necessary (DefaultAtoms, TSAtoms).
The patch also adds a big comment explaining how the macros are used, and what
their expansion looks like. This makes it a lot easier to understand how static
atoms work. Correspondingly, the patch removes some small comments scattered
around the macro use points.
MozReview-Commit-ID: wpRyrEOTHE
--HG--
extra : rebase_source : 9f85d477b4d06c9a9e710c757de1f1476edb6efe
Because it's the type we use to set up static atoms at startup, not the static
atom itself.
The patch accordingly renames some parameters, variables, and NS_STATIC_ATOM,
for consistency.
MozReview-Commit-ID: 1a0KvhYNNw2
--HG--
extra : rebase_source : 5c66e5b2dfe053a368bf3584d957198aec4cce91
In order to properly disable template functions with `std::enable_if` we need
to use the resulting type. This only works if we use a dependent type in the
template params, hence the need to shadow the `T` param.
Proper usage is now of the form:
template<typename Q = T, typename EnableIfChar = CharOnlyT<Q>>
Foo();
--HG--
extra : rebase_source : da7855403d9e683d06d3858e26805e9d8e338208
We were extracting elements from the queue and unnecessarily refcounting
them, rather than transferring the owning reference out of the queue and
out to the caller.
This lets us replace moz_xstrdup() of string literals with AssignLiteral(),
among other improvements.
--HG--
extra : rebase_source : 9994d8ccb4f196cf63564b0dac2ae6c4370defb4
Renames are because another location also defined that
variable. Unused definitions are eliminated.
The .eslintrc.js file makes eslint expect XPCShell global variables.
MozReview-Commit-ID: Fafm5o45bme
--HG--
extra : rebase_source : ab71132a60e90bd30f34766bd828b18dd608f8b3
These were generated with |./mach eslint --fix xpcom| with the
.eslintignore and xpcom/tests/unit/.eslintrc.js changes from the next
patch.
MozReview-Commit-ID: 8pKkICSK3JQ
--HG--
extra : rebase_source : bbc98050928f27160d8ca63d38aa0c383be95878
This is non-standard, and eslint can't parse it correctly, so remove
it.
MozReview-Commit-ID: EsfZSyoECB0
--HG--
extra : rebase_source : 561d194e0c466d98d054b2303916be196f983b1b
This change requires introducing nsID::Clone(). Because it's infallible, the
patch also removes some redundant failure-handling code. (nsMemory::Clone() is
also infallible, so this code was redundant even before this change.)
--HG--
extra : rebase_source : ef22757d3fa814320490bf7e19e822b8f0c4bdc3
The new code is slightly less efficient because it requires measuring the
string length, but these strings are all short so it shouldn't matter.
Note that the case in DataToString() is a little different. The std::min() that
was there appears to be excessive caution -- this code is always printf'ing
some kind of number, so 32 chars should never be reached -- but it was bogus
anyway, because if 32 was exceeded then (a) we would have overflowed `buf`, and
(b) we'd be returning a non-null-terminated string.
--HG--
extra : rebase_source : b666ad72c09d8c32b98bb9abc9dce1bd0c912c9b
They are equivalent -- both infallible, both requiring measuring the length of
the string -- but moz_xstrdup is much more readable. (One place deals with
16-bit strings and so uses NS_strdup instead, which is also infallible.)
The patch also removes some failure-path code that will never execute due to
the infallibility.
--HG--
extra : rebase_source : 115574cf55db90b60e6bee59e5dc6ee409374159
There should be no functional change here, but we rely upon the new
structure in the next patch in the series. This separates out the
notions of removing a request from the load group (which is always
final, and must be executed outside of synchronous calls from the owner
of the imgRequestProxy) and wanting to readd a request to the load group
as a background request (for multipart images).
The most important addition is mForceDispatchLoadGroup which if true
when imgRequestProxy::RemoveFromLoadGroup is called, will dispatch the
removal from the load group instead of executing it inline. This ensures
safety for any callers (e.g. to CancelAndForgetObserver) as above.
Currently nsAtom::mString points to the interior of an nsStringBuffer. For
static atoms this requires the use of nsFakeStringBuffer, which is pretty
gross.
This patch changes things so that nsAtom::mString points to a static char
buffer for static atoms. This simplifies a number of things:
- nsFakeStringBuffer and CheckStaticAtomSizes are no longer needed.
- FakeBufferRefCountHelper is no longer needed.
- nsAtom's constructor for static atoms is simpler.
- RegisterStaticAtoms() is simpler.
On the flip-side, a couple of things get more complicated.
- nsAtom::ToString() treats static and dynamic atoms differently.
- nsAtom::GetStringBuffer() is now only valid for dynamic atoms. This
function is only used in two places, both involving DOMString, so those
locations are updated appropriately. This also requires updating some other
code assigning nsStrings to DOMStrings, because we can't assume that
nsStrings are shared.
On Linux64 this change reduces the size of the binary by 8752 B, and moves
81968 B from the .data to the .rodata section, where it can be shared between
processes.
--HG--
extra : rebase_source : 0f6fcdec1c525aa66222e208b66a9f9026f69bcb
This also fixes the Unix part of bug 678369, and fixes bug 147659 as a
convenient side-effect of using LaunchApp (which has the desired
fd-closing behavior already) rather than directly using fork/exec.
The main goal is to work around bug 227246, where PR_CreateProcess on
Unix interferes with anything else that tries to use child processes.
This does not fix that bug -- NSPR will still cause problems if used in
that way -- but it's an adequate workaround for that bug in Gecko in
almost all cases (the one known exception is nsAuthSambaNTLM, which uses
NSPR directly and needs to be fixed separately).
Waiting for the child process uses waitpid() directly, sharing the
existing code used for OS X.
MozReview-Commit-ID: 6zfZ1Zgk2i9
--HG--
extra : rebase_source : e8230503d82943af4563d8d63baa029d8a698683
Bug 1134923 removed the use of those functions in gecko, and left some
for the XPCOM standalone glue. The XPCOM standalone glue was severely
stripped down in bug 1306327, with the effect of removing the
implementation for those functions.
The remains in nsXPCOM.h are:
XPCOM_API(void*) NS_Alloc(size_t aSize);
XPCOM_API(void*) NS_Realloc(void* aPtr, size_t aSize);
XPCOM_API(void) NS_Free(void* aPtr);
With no implementation left, the first arm is never actually used, and
the second arm means every remaining use of those functions in the tree
is a macro expansion to one of moz_xmalloc, moz_xrealloc or free.
--HG--
extra : rebase_source : fd1669abc5a25d8edbd5c3a8522e22a5c3f558e2
nsEscape.cpp doesn't build in non-unified mode, as it uses mozilla::fallible,
mozilla::CheckedInt and mozilla::ASCIIMask::IsMasked without prefixing them
with the mozilla namespace. I suspect this file is usually included in
unified_cpp file which includes a "using namespace mozilla" directive.
MozReview-Commit-ID: GwlsK8kytLj
--HG--
extra : rebase_source : c3063aff7cdf10c416b8ee782c9bee745e643842
We were using a StaticRefPtr without it being fully defined for
SystemGroupImpl::sSingleton, resulting in a non-unified build failure.
MozReview-Commit-ID: AgSuVvGTri7
--HG--
extra : rebase_source : 906e30e8c2c21e13a045a941e9d92e1d2d2af079
This Makefile.in contains a bunch of cruft for Tier-3 platforms. If
someone is still supporting any of them they can make the necessary
fixes to moz.build files themselves.
MozReview-Commit-ID: HxbbCv395Y5
--HG--
extra : rebase_source : 94f04128d2b3dd1285dfeafbfeb320b2f0d0bb19
extra : histedit_source : 2353127161ae58e54b6296e98b6b4b972ae439fe
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 : 53c8b43b6a1be06d00618a133e28bf95c46a3ba3
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 : 59f77df0124249bfd11fee3585420a17b4201d37
Currently the Gecko Profiler defines a moderate amount of stuff when
MOZ_GECKO_PROFILER is undefined. It also #includes various headers, including
JS ones. This is making it difficult to separate Gecko's media stack for
inclusion in Servo.
This patch greatly simplifies how things are exposed. The starting point is:
- GeckoProfiler.h can be #included unconditionally;
- everything else from the profiler must be guarded by MOZ_GECKO_PROFILER.
In practice this introduces way too many #ifdefs, so the patch loosens it by
adding no-op macros for a number of the most common operations.
The net result is that #ifdefs and macros are used a bit more, but almost
nothing is exposed in non-MOZ_GECKO_PROFILER builds (including
ProfilerMarkerPayload.h and GeckoProfiler.h), and understanding what is exposed
is much simpler than before.
Note also that in BHR, ThreadStackHelper is now entirely absent in
non-MOZ_GECKO_PROFILER builds.
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
Adds a new directory provider key "XRESysExtDev" to be used by system extension
developers needing to load system extensions from a directory readable by
sandboxed content processes.
MozReview-Commit-ID: 4BKOZoPzCC3
--HG--
extra : rebase_source : 452db8d53a1f0248a080f858c48492978b5db808
Removes the XPCOM interface for nsIDOMHTMLCanvasElement, replacing it
with binding class usage.
MozReview-Commit-ID: DQJhqGlY8U6
--HG--
extra : rebase_source : a33146a22ee356a0840bb9fef82d51b2b315f6d7
The Windows and OSX code paths were essentially doing the same thing,
and the Unix fallback was using an old convention that is pretty much
outdated.
Under normal conditions (XPCOM initialized by Firefox),
NS_XPCOM_INIT_CURRENT_PROCESS_DIR is set from BinaryPath anyways, so
this only really affects adhoc XPCOM initialization from e.g. C++ unit
tests.
--HG--
extra : rebase_source : b3151fffd4c82159b633a48dead86f2c3b0a03d6
Back in the day, there was no global with an already initialized
DirectoryService. But now there is, and, in fact,
GetCurrentProcessDirectory already errors out if that global is not set
by the time it's called. All calling nsDirectoryService::Create achieves
is doing the check again and calling QueryInterface, which we don't need
to do anyways.
--HG--
extra : rebase_source : 32f5080ecb8165cffd601799e72d278b482b0871
It seemingly hasn't been needed since Mac OS 10.7. A diagnostic assertion that
has been in place for a while hasn't caught any uses of it.
--HG--
extra : rebase_source : 9834849eec9174267c7df8de7fd22840ffa36d8f
This adds an attribute 'noShell' to nsIProcess that is used to launch a process
using CreateProcess() if we are sure we are launching an executable and don't
require the extra work of the Windows shell service.
MozReview-Commit-ID: 7p0iHCZK1uX
Add macro for nsISupports inheriting classes that need cycle
collection and only inherit from one parent, with no interface table
needed. Takes care of map and addref/release calls.
MozReview-Commit-ID: LtTwYH0DeEz
--HG--
extra : rebase_source : d3650209ddd7e28cbf205ac84f152b9763c26bde
