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
Also adds the necessary methods to rust-url-capi and fixes a bug in rusturl_set_username
MozReview-Commit-ID: 9rsPIQAbWBJ
--HG--
extra : rebase_source : a1dee0b0e26a5c816f47a7c7c779c2454f87f51f
Also adds the necessary methods to rust-url-capi and fixes a bug in rusturl_set_username
MozReview-Commit-ID: 9rsPIQAbWBJ
--HG--
extra : rebase_source : 550aafbfb1d57257db49897a7506ebb9f038021f
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
When for some reason the target of a resource: substitution doesn't end
with a / (which can happen when e.g. building a FileURI with a path
that doesn't exist), relative path resolution of the resource URLs end
up rooted under the parent of the non-existing directory.
e.g
resource://foo/bar is substituted with /path/for/bar if
resource://foo/ is registered for file:///path/for/foo (instead of
file:///path/for/foo/)
--HG--
extra : rebase_source : b59dae0337a707a96adfc1c89c27235a856ec58e
When for some reason the target of a resource: substitution doesn't end
with a / (which can happen when e.g. building a FileURI with a path
that doesn't exist), relative path resolution of the resource URLs end
up rooted under the parent of the non-existing directory.
e.g
resource://foo/bar is substituted with /path/for/bar if
resource://foo/ is registered for file:///path/for/foo (instead of
file:///path/for/foo/)
--HG--
extra : rebase_source : 9907f7c54f43851ba1a956a5d278d301013204d2
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
When for some reason the target of a resource: substitution doesn't end
with a / (which can happen when e.g. building a FileURI with a path
that doesn't exist), relative path resolution of the resource URLs end
up rooted under the parent of the non-existing directory.
e.g
resource://foo/bar is substituted with /path/for/bar if
resource://foo/ is registered for file:///path/for/foo (instead of
file:///path/for/foo/)
--HG--
extra : rebase_source : 50a329318a2424bc5679a2e026e755271214224a
