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
They have been already enabled on all channels in bug 1386021.
MozReview-Commit-ID: BCin6tCweqV
--HG--
extra : rebase_source : dfa156466e223fbc7e73c2c6a7d9662c6f4d6aac
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 : 5dcc252160694a72e30ae41689f173cc0886edd6
Replace it with NS_INTERFACE_MAP_BEGIN_CYCLE_COLLECTION, because it
has been the same for a while.
MozReview-Commit-ID: 5agRGFyUry1
--HG--
extra : rebase_source : 5388c56b2f6905c6ef969150f0c5b77bf247624d