Most preference callbacks use literal strings for their domain filters, which
means that there's no need to make copies of them at all. Currently, however,
every preference observer node makes a separate heap-allocated copy of its
domain string.
This patch switches the domain string storage to nsCString instances, which
dramatically reduces the amount of unnecessary copies, at the expense of
making the callback nodes slightly larger.
MozReview-Commit-ID: 8NA3t2JS2UI
--HG--
extra : rebase_source : 628ad9af65cec16fb8be0c8dddc608b5ee5602e2
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
This reduces memory usage because we only need one allocation instead of two
for the dynamic atom and its chars, and because we don't need to store a
refcount and a size. It precludes sharing of chars between dynamic atoms, but
we weren't benefiting much from that anyway.
This reduces per-process memory usage by up to several hundred KiB on my
Linux64 box.
One consequence of this change is that we need to allocate + copy in
DOMString::SetKnownLiveAtom(), which could make some things slower.
--HG--
extra : rebase_source : ba4065ea31e509dd985c003614199f73def0596c
After fixing the document.domain exceptions to conform to the html
spec, NS_ERROR_DOM_BAD_DOCUMENT_DOMAIN is no longer used, and can be
removed.
MozReview-Commit-ID: 9CwrUSGy2K3
--HG--
extra : rebase_source : 6c624e407fd714f8c61e1e43d44089c0c1e64558
This adds 'CorruptionCanaryForStatics', which as the name implies is suitable
for use in objects that are statically declared. It has a trivial destructor
which allows us to avoid the need for static constructors.
--HG--
extra : amend_source : 27f8eff9ead21fde9f5f5d17f16c322d2c995a27
HashStore::ApplyUpdate() is a V2-only function and so we can be
explicit about that and remove unnecessary casts.
Add a new update error code for when we fail to cast a TableUpdate
object to the expected protocol version.
MozReview-Commit-ID: 65BBwiZJw6J
--HG--
extra : rebase_source : 3f4bb0f7594d4015e2614ef747526ec5e8168a08
Inheriting PerThreadAtomCache on CycleCollectedJSContext permits use of
static_cast, avoiding one level of indirection compared to adding a
CycleCollectedJSContext* to PerThreadAtomCache.
PerThreadAtomCache is over 18kB, and so WorkerJSContext and WorkletJSContext
are moved from the stack to the heap.
MozReview-Commit-ID: 6jdJeZcviK4
--HG--
extra : rebase_source : 3c2accb71faf3f017a44c405ae0484e57aaf039c
Currently we call JSPurpleBuffer::Destroy from
nsCycleCollector::PrepareForGarbageCollection. If the CC is shut down after a call to
nsCycleCollector::GetJSPurpleBuffer (which creates a JSPurpleBuffer) but before a GC
happens, we'll release the strong reference in mJSPurpleBuffer from nsCycleCollector's
destructor but we won't call JSPurpleBuffer::Destroy. That leaves a stale pointer to the
JSPurpleBuffer in the JSHolder's hash.
--HG--
extra : rebase_source : b21a0953ae5b3a470dbd22b8285bffb858f87f13
extra : histedit_source : 1959a4480066fc0920830428023ce01e0768c08e
Same approach as the other bug, mostly replacing automatically by removing
'using mozilla::Forward;' and then:
s/mozilla::Forward/std::forward/
s/Forward</std::forward</
The only file that required manual fixup was TestTreeTraversal.cpp, which had
a class called TestNodeForward with template parameters :)
MozReview-Commit-ID: A88qFG5AccP
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
This patch defines NS_ERROR_EDITOR_DESTROYED error code as an editor module
specific error code.
And creates TextEditRules::CanHandleEditAction() to check if the instance
can keep handling edit action.
MozReview-Commit-ID: 4qECwNBO0yz
--HG--
extra : rebase_source : a925a9b6840d4d06e2792b9fe276e062288b0806
They're very similar as far as most users of the profiler are concerned, I'd
say, and I don't believe it's worth giving them two different colors in the
activity graphs.
MozReview-Commit-ID: HTqjp56naL3
--HG--
extra : rebase_source : cf8d64bc3e76ed9bb07100081aebfc404845b8bc
They're very similar as far as most users of the profiler are concerned, I'd
say, and I don't believe it's worth giving them two different colors in the
activity graphs.
MozReview-Commit-ID: HTqjp56naL3
--HG--
extra : rebase_source : ed1dc54efd143ad64bc21cfc39853ae90477cc9d
They're very similar as far as most users of the profiler are concerned, I'd
say, and I don't believe it's worth giving them two different colors in the
activity graphs.
MozReview-Commit-ID: HTqjp56naL3
--HG--
extra : rebase_source : f172424042fab18a514201ba4b6c67c03c209cdb
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
When memory-pressure events were first used in an e10s environment it was
to implement memory minimization from about:memory. However when low memory
detection was first introduced in Firefox OS an issue arised with this scheme:
every process was using a kernel-based low-latency mechanism to detect low
memory scenarios and send memory-pressure events; but the main process events
were also being forwarded to all child processes causing listeners to be
triggered twice. Because of this -no-forward events were introduced and used.
Currently however low-memory is detected via polling, so there will always be
a significant delay between the beginning of the low-memory scenario and its
detection. Because of this there is no value in having content processes poll
on their own and it's best to have only the main process do it and then
forward the memory-pressure events to all child processes.
MozReview-Commit-ID: AMQOsEgECme
--HG--
extra : rebase_source : 1b408b31dd27940981407f50f2e5f07e354b16d7
This patch introduces a new polling mechanism to detect low-memory scenarios.
The timer fires at a relatively slow pace and stops whenever the user stops
interacting with Firefox to avoid consuming power needlessly. The polling rate
is up to 3 orders of magnitude slower than the current tracker and is
throttled when memory is running low. It also doesn't suffer from data races
that were possible with existing tracker.
Contrary to the old available memory tracker which relied on a
Windows-specific mechanism, this one could be made to work on other platforms
too. The current implementation only supports Windows 64-bit builds though.
MozReview-Commit-ID: CFHuTDqjPbL
--HG--
extra : rebase_source : 92d1f801cc680f9fde8ecfa46c570e3c562a3d01
This type is fairly simple on the idl parsing side of things. I handle it in the
same way that special types such as ns[C]String, nsid, and jsval are handled, by
using a special native type.
The logic for converting the value between C++ and JS follows the existing logic
from the nsISupports <=> JS Promise conversions.
"alloc-failure" is completely unused apart from the description text in nsI-
Memory.idl (and has been since before Firefox 17), while "lowering-priority" is
still being checked for in the PuppetWidget, but otherwise unused as well since
the feature using it was decommissioned in bug 1234176.
Since we're touching the PuppetWidget code anyway, we take the opportunity to
add a check for "low-memory-ongoing" instead, since similar as to how things
used to be with "lowering-priority", we want to drop the LayerManager's cached
resources only when receiving a real full memory-pressure event, but not for
subsequent ongoing notifications.
MozReview-Commit-ID: HL03SOU8axe
--HG--
extra : rebase_source : c988769df36d8d77f4770c71d5c5e0d75c3b99af
For some reason, the CC spends a lot of time tracing jsids on
ObjectGroups when an addon is installed. This patch avoids that by
adding a canSkipJsids flag to JSTracer, and using it in
ObjectGroup::traceChildren. If this is true, then the tracer is free
to not report every jsid. This flag is set to true for the two CC
tracers.
MozReview-Commit-ID: CWFqQEr0SxV
--HG--
extra : rebase_source : cc31c22717f8990166454db191e0d40c145e09f0
Use fatal MOZ_ASSERT or non-fatal NS_ASSERTION instead.
MozReview-Commit-ID: 1QAsgoWpXDn
--HG--
extra : source : 9ca972b6b3e7d3b576e20a0bf412df51d82aad9f
extra : intermediate-source : a909a9d7bc9a53095e963a4bea45f4fc4aa85b72
...on Windows, at least. Apparently if you have environment variables
set that contain multibyte characters, and ask for them with getenv, you
get garbage. Or perhaps you get something sensible, but then passing it
to fopen produces garbage. Either way, the most reasonable way to
handle this is to use the Windows wide-character APIs all over.
Currently static atoms are stored on the heap, but their char buffers are
stored in read-only static memory.
This patch changes the representation of nsStaticAtom (thus making it a
non-trivial subclass of nsAtom). Instead of a pointer to the string, it now has
an mStringOffset field which is a 32-bit offset to the string. (This requires
placement of the string and the atom within the same object so that the offset
is known to be small. The docs and macros in nsStaticAtom.h handle that.)
Static and dynamic atoms now store their chars in different ways: nsStaticAtom
stores them inline, nsDynamicAtom has a pointer to separate storage. So
`mString` and GetStringBuffer() move from nsAtom to nsDynamicAtom.
The change to static atoms means they can be made constexpr and stored in
read-only memory instead of on the heap. On 64-bit this reduces the per-process
overhead by 16 bytes; on 32-bit the saving is 12 bytes. (Further reductions
will be possible in follow-up patches.)
The increased use of constexpr required multiple workarounds for MSVC.
- Multiple uses of MOZ_{PUSH,POP}_DISABLE_INTEGRAL_CONSTANT_OVERFLOW_WARNING to
disable warnings about (well-defined!) overflow of unsigned integer
arithmetic.
- The use of -Zc:externConstexpr on all files defining static atoms, to make
MSVC follow the C++ standard(!) and let constexpr variables have external
linkage.
- The use of -constexpr:steps300000 to increase the number of operations
allowed in a constexpr value, in order to handle gGkAtoms, which requires
hashing ~2,500 atom strings.
The patch also changes how HTML5 atoms are handled. They are now treated as
dynamic atoms, i.e. we have "dynamic normal" atoms and "dynamic HTML5 atoms",
and "dynamic atoms" covers both cases, and both are represented via
nsDynamicAtom. The main difference between the two kinds is that dynamic HTML5
atoms still aren't allowed to be used in various operations, most notably
AddRef()/Release(). All this also required moving nsDynamicAtom into the header
file.
There is a slight performance cost to all these changes: now that nsStaticAtom
and nsDynamicAtom store their chars in different ways, a conditional branch is
required in the following functions: Equals(), GetUTF16String(),
WeakAtom::as_slice().
Finally, in about:memory the "explicit/atoms/static/atom-objects" value is no
longer needed, because that memory is static instead of heap-allocated.
MozReview-Commit-ID: 4AxPv05ngZy
MOZ_LOG=modules:4,raw now outputs the log without prefixes with the thread name
and date and stuff, just the exact string that was specified.
MozReview-Commit-ID: HACT5EM4BFm
--HG--
extra : rebase_source : 93590ee405f013791ad63565be6e6d83cad3567f
extra : source : d79d7130b28275c8eb2a475bdc685a345b070888
clang-tidy is complaining about an extra else in
NS_INTERFACE_MAP_ENTRIES_CYCLE_COLLECTION. Not hurting anything, but
could be cleaned up anyways.
MozReview-Commit-ID: 36Lkdhs3fyN
--HG--
extra : rebase_source : 74088c9c2668f43d55133be240d4591880b60dab
The old output had a single value: "atoms-table". The new output looks like
this:
> 649,904 B (00.39%) -- atoms
> ├──350,256 B (00.21%) -- dynamic
> │ ├──235,056 B (00.14%) ── unshared-buffers
> │ └──115,200 B (00.07%) ── atom-objects
> ├──212,992 B (00.13%) ── table
> └───86,656 B (00.05%) ── static/atom-objects
MozReview-Commit-ID: 924vUmxHAlh
--HG--
extra : rebase_source : 6c977546a69eeee62ebc87e335982e8278217484
Various atom-related things have improved recently.
- The main atom table is now threadsafe (bug 1275755) and so can be accessed on
any thread. It has also been split into pieces (bug 1440824), which greatly
reduces lock contention.
- A cache has been added to the HTML5 parser (bug 1352874) that removes the
need for most of the full table lookups.
As a result, there is no point having a separate static atom table. This patch
removes it.
MozReview-Commit-ID: 8ou1BrnPAwd
--HG--
extra : rebase_source : 0c6ab073b1a20b703705582d28731a68456741e1
This also changes a few MOZ_LOG() messages to use the error name
instead of the raw numerical nsresult value.
MozReview-Commit-ID: Jcngd0S9j2z
--HG--
extra : rebase_source : f6e974569d8845211e0b25dabef2c41dda2ca1b6
nsSetDllDirectory.h consists of just one function definition, SanitizeEnvironmentVariables, which is now only called from nsWindowsMain.cpp. nsSetDllDirectory.h used to define its namesake NS_SetDllDirectory, but the function was removed in bug 699247.
Also remove some #includes that are no longer necessary.
MozReview-Commit-ID: E8OsXycdfO8
--HG--
extra : rebase_source : d9e63a50a782ab1fb0fde24646a777b882860fb9
extra : histedit_source : 63c41846db2bb6a1def03c343e6f336373f1fba6
This adds some assertions to make the intended usage of LogModuleManager::Init
more clear.
--HG--
extra : rebase_source : c61e1736cedfbeaa96951ba40cdc954bbc0094d5
The change to RootAccessible.cpp fixes an obvious bug introduced in bug 741707.
The visibility changes in gfx/thebes are because NS_DECL_ISUPPORTS has a
trailing "public:" that those classes were relying on to have public
constructors.
MozReview-Commit-ID: IeB8KIJCGhU
This macro is identical to NS_INTERFACE_MAP_END and encourages the
reader to think that there's something extra-special threadsafe about QI
implementations that use the macro, when in reality there's nothing of
the sort.
This patch adds a new environment variable XPCOM_MEM_LOG_JS_STACK that
changes XPCOM leakchecking to record a JS stack for all objects, in
addition to a C++ stack. This is useful when a C++ object is being
leaked due to JS. The JS stack will be printed if the object leaks, if
it is used in combination with XPCOM_MEM_BLOAT_LOG=1 and
XPCOM_MEM_LOG_CLASSES=nsFoo, if nsFoo is the class of interest.
This patch moves a few XPConnect functions for recording the stack
into xpcpublic.h so they can be called from nsTraceRefcnt.cpp.
MozReview-Commit-ID: FX2QVCSXz4f
--HG--
extra : rebase_source : 5bd4e341072f4cf7d3be774b63d2107479fe9985
This commit adds a paint worker thread pool to PaintThread, and dispatches
tiled paints to it. The thread pool is only created if tiling is enabled,
and its size is set by 'layers.omtp.paint-workers' and defaults to 1. If
-1 is specified, it will be sized to 'max((cpu_cores * 3) / 4, 1)'.
The one tricky part of dispatching tiled paints to a thread pool is the
AsyncEndLayerTransaction message that must execute once all paints are
finished. Previously, this runnable would be queued after all the paints
had been queued, ensuring it would be run after they had all completed.
With a thread pool, there is no guarantee. Instead this commit, uses
a flag on CompositorBridgeChild to signify whether all of the paints
have been queued ('mOutstandingAsyncEndLayerTransaction'), and after
every tiled paint it is examined to see if that paint was the last
paint, and if it is to run AsyncEndLayerTransaction. In addition,
if the async paints complete before we even mark the end of the
layer transaction, we queue it like normal.
The profiler markers are also complicated by using a thread pool.
I don't know of a great way to keep them working as they are per
thread, so for now I've removed them. I may have been the only
one using them anyway.
MozReview-Commit-ID: 5LIJ9GWSfCn
--HG--
extra : rebase_source : 0c26806f337a1b4b1511945f9c72e787b426c5ba
We had to force-include Char16.h to simulate char16_t on older MSVC versions.
But it is no longer the case. We should not rebuild the world whenever we
touch this file.
MozReview-Commit-ID: 1XY7tQD8LoK
--HG--
extra : rebase_source : a08ccfc9b6a4abf90f6f8b97a42079865724c9ec
Most subclasses of Runnable don't bother to override AddRef and
Release, so XPCOM leak checking ends up reporting Runnable, which
makes it impossible to know what is actually leaking.
Each subclass of Runnable is already required to pass in the name of
the class, which is stored in the field mName. This patch changes
Runnable to use mName as the class name for XPCOM leak checking, thus
giving each subclass a specific name without needing to change the
hundreds of existing subclasses of Runnable.
The limitation of this approach is the classes that DO use
NS_IMPL_ADDREF/RELEASE_INHERITED end up using the same class name that
is used by the superclass AddRef/Release, but with a different size,
which causes assertions in the leak checker. To work around this, I
change NS_IMPL_ADDREF/RELEASE_INHERITED to not call into
NS_LOG_ADDREF/RELEASE for classes that are a subclass of
Runnable. This needs to use IsConvertible<> and not IsBaseOf<> because
the latter requires the classes involved to be defined, and headers
can use nsISupportsImpl.h without nsThreadUtils.h.
MozReview-Commit-ID: H0pgvwQSZAE
--HG--
extra : rebase_source : 0be13fe2e649e62be1f9471fc03fac43024eb0aa
Remove the headers included for "backwards compatibility" and just include them
where required.
--HG--
extra : source : e2beba7e6875120ebbbcadf24bcbcb5b86411a94
extra : amend_source : 11f07a27431cd468511f0bd45afe36150c6e342c
Remove the headers included for "backwards compatibility" and just include them
where required.
--HG--
extra : rebase_source : 03e703a81ed4b80f4f116ff36d8787464ce5acba
This removes an unnecessary level of indirection by replacing all
nsStringGlue.h instances with just nsString.h.
--HG--
extra : rebase_source : 340989240af4018f3ebfd92826ae11b0cb46d019
Back when mozalloc was a separate library, the xpcom glue code could not
use the infallible allocator API. But since bug 868814, that's not the
case anymore, so we can safely include mozalloc.h when XPCOM_GLUE is
set.
--HG--
extra : rebase_source : a8fbf8dc7020765d7287e2eb7ceaf41c99be8b18
NoteIntentionalCrash is supposed to leave a marker that a process has crashed
intentionally, but if it can't open the target file it will crash the process
itself. This can cause difficulty debugging and false-positive results for
tests expecting crashes.
MozReview-Commit-ID: CgLauJIEAKD
--HG--
extra : rebase_source : 689bfaa0e93b96f8ebbbaf31e17e80547004506f
There's no good reason why these should't just be constants. The patch also
appends "MiB" to some of the C++ values to make their meaning clearer.
This patch fixes one outright bug, and one inconsistency.
The bug is due to a prefname mismatch:
- ContentPrefs.cpp and AvailableMemoryTracker.cpp use
"memory.low_virtual_mem_threshold_mb".
- all.js uses "memory.low_virtual_memory_threshold_mb".
Which means that "memory.low_virtual_memory_threshold_mb" showed up in
about:config, but if you changed it nothing would happen because the callback
listened for changes to to "memory.low_virtual_mem_threshold_mb"!
Now for the inconsistency. The above means we actually use a value of 256 for
the virtual memory threshold, even though all.js says 128. But we *do* use a
value of 128 for the commit space threshold, because that's what all.js says
and that prefname is used correctly everywhere. The patch changes the commit
space threshold to 256 for consistency with the virtual memory threshold.
What a mess!
--HG--
extra : rebase_source : d3842c732efa9ab0e90eeb6a4f341aeb289589ed
This was originally added for b2g, where the pref had a different value.
Bug 1398033 enabled it everywhere.
--HG--
extra : rebase_source : c8bb03190cd00d25e6c2ec62a99ed8e911e08197
Use MOZ_CRASH, MOZ_CRASH_UNSAFE_OOL, or MOZ_CRASH_UNSAFE_PRINTF instead.
MozReview-Commit-ID: 1kCCHMlgbGP
--HG--
extra : rebase_source : 2f07ced16bccebf30cd3b2b5fea35e9868d32dad
extra : source : 0bf2c8425b828e71de55dd175fd0dad635b4e67d
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.
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
This lets us replace moz_xstrdup() of string literals with AssignLiteral(),
among other improvements.
--HG--
extra : rebase_source : 9994d8ccb4f196cf63564b0dac2ae6c4370defb4
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
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
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.
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
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
There is no use mozilla namespace statement in this compilation unit, so the
call to GetErrorName() has to be prefixed with the mozilla namespace.
MozReview-Commit-ID: G3caP2v9PFF
--HG--
extra : rebase_source : 9aebe0711cf8ad81dc47592521a4f29b4f75caab
