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.
The NS_LITERAL_CSTRING macro creates a temporary nsLiteralCString to encapsulate the string literal and its length, but AssignLiteral() can determine the string literal's length at compile-time without nsLiteralCString.
MozReview-Commit-ID: B5Y8KyExPQ8
--HG--
extra : rebase_source : e27b266c145daa5acd887e998c6d5b408101e1db
extra : source : 33f49977a33cbdb1c7127871b940eefccc018f65
The NS_LITERAL_CSTRING macro creates a temporary nsLiteralCString to encapsulate the string literal and its length, but AssignLiteral() can determine the string literal's length at compile-time without nsLiteralCString.
MozReview-Commit-ID: DbTW5Bhd9E1
--HG--
extra : rebase_source : b27f666e5ca832d814fb6846208474e1ec66e5f4
extra : source : 9ff4e11402a9a43ed90298a9c354b0164cf9414f
browser.sessionhistory.cache_subframes has been disabled for 12yrs. It's not
actually maintained and it leaks content viewers. Using this unreliable feature
in test cases is a bad practice, so remove the pref completely and fix existing
test cases.
MozReview-Commit-ID: 3tQLpsqmmaq
--HG--
extra : rebase_source : 3e5094fed014a5d152e85f21b6de796a9a7abaa9
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
This includes minor shutdown fixes by :asuth as discussed on
https://bugzilla.mozilla.org/show_bug.cgi?id=1047098#c56 and c57.
--HG--
extra : rebase_source : d1a230cc005b2a6a71f16ef84a55851ee2f4f66e
extra : source : e89d2565799b4b02d5ee2c56da8d44dc0067f26a
This is a preexisting issue that makes nsMultiplexInputStream multiple-inherit
from nsIInputStream: once via nsIMultipartInputStream and once via
nsIAsyncInputStream. This causes problems once we end up with more multiplex
streams that are async streams, because then some assingments to
nsCOMPtr<nsIInputStream> start asserting. This patch just removes the footgun
by getting rid of the multiple inheritance.
This is a preexisting issue that makes nsMultiplexInputStream multiple-inherit
from nsIInputStream: once via nsIMultipartInputStream and once via
nsIAsyncInputStream. This causes problems once we end up with more multiplex
streams that are async streams, because then some assingments to
nsCOMPtr<nsIInputStream> start asserting. This patch just removes the footgun
by getting rid of the multiple inheritance.
Because UBSan complains about casting -1:
> runtime error: load of value 4294967295, which is not a valid value for type 'JSGCParamKey'
--HG--
extra : rebase_source : ff972b29f9a89fcbe50d9f105196bcd8f06486bd
Bug 1378949 found test_notificationclick_focus.html timing out because the
ServiceWorker activation raced the creation of an iframe document that wanted
to be controlled by the serviceworker.
The documents that wanted to be controlled had a half-hearted attempt at
dealing with this by using navigator.serviceWorker.ready, but that would only
work if the SW's attempted to claim the clients if they already existed, which
they did not.
This patch cleans up the defective test and its sibling tests that follow the
same idioms.
--HG--
extra : source : fb699d88bb80f27fbfd4805afc2e8feaa55964e0
The current shutdown handling code is susceptible to deadlocks, since it spins
the event loop while it holds mMonitor, and other main thread methods which
try to acquire mMonitor can be called from code that runs while the event loop
is spinning.
My initial solution was just to release mMonitor before spinning the event
loop, but at this point I think it makes more sense to switch to the
standardized AsyncShutdown routines, which provide better diagnostics and
allow us to avoid one more nested event loop during shutdown.
MozReview-Commit-ID: 1RtFN585IR7
--HG--
extra : rebase_source : 978f3bf7cef73e56b3e1c1c838c2bc6efcefb0c0
extra : amend_source : 2b7c9422004b58ad1d38d7dd705ad446bc47cb23
extra : histedit_source : 7a4e80de7d5aa48e074ea03821bb78e5e287842e%2C92c1119a131adaa33f5691c0e534bb243115817b
browser.sessionhistory.cache_subframes has been disabled for 12yrs. It's not
actually maintained and it leaks content viewers. Using this unreliable feature
in test cases is a bad practice, so remove the pref completely and fix existing
test cases.
MozReview-Commit-ID: 3tQLpsqmmaq
--HG--
extra : rebase_source : ce6e27c7d422f32dec858712eba5ed8011ee8039