Raw Cr.ERROR don't get stack information, same as throwing JS literals instead
of `new Error()`s.
This was done automatically with a new eslint rule that will be introduced in
the next commit. One instance of a raw Cr.ERROR was not replaced since it is
used in a test that specifically checks the preservation of raw Cr values in
XPCJS. The rule will be disabled for that instance.
Differential Revision: https://phabricator.services.mozilla.com/D28073
In non-DEBUG builds, `OffTheBooksCondVar::Wait` has `AUTO_PROFILER_THREAD_SLEEP`, but it's not in DEBUG builds.
`profiler_thread_sleep` does a `MOZ_ASSERT(mSleep == AWAKE)` in DEBUG builds, so the double call that happens in non-DEBUG wouldn't trigger the assertion!
This patch adds `AUTO_PROFILER_THREAD_SLEEP` in DEBUG `OffTheBooksCondVar::Wait`, to catch more misuses during development.
Depends on D72851
Differential Revision: https://phabricator.services.mozilla.com/D72852
CondVar already calls `AUTO_PROFILER_THREAD_SLEEP`, which shouldn't be called recursively.
mozilla::Monitor also uses CondVar, so it shouldn't be surrounded by `AUTO_PROFILER_THREAD_SLEEP` either.
Depends on D72850
Differential Revision: https://phabricator.services.mozilla.com/D72851
In the tests we now explicitly use "Main Process" (or similar) for the process
name in various places to avoid having to filter out a PID.
Also in `test_aboutmemory[34].xhtml`, the main process entries now appear
first, as they should, because the sorting code now looks for a "Main Process"
prefix, rather than an exact match.
Depends on D72995
Differential Revision: https://phabricator.services.mozilla.com/D73164
In practice this shouldn't substantially change the behavior, but
it gets around being UB, and it shouldn't really cost us in terms
of performance. The alternative would be adding it to the TSAN
whitelist, which feels worse.
Differential Revision: https://phabricator.services.mozilla.com/D72015
After the recent simplifications to the zoom code, they only take care
of forwarding the enlarge / decrease zoom messages.
We can do that via PBrowser instead, and get rid of the actors. We can
also remove ZoomChangeUsingMouseWheel. Zooming with the mouse wheel will
end up in a *ZoomChange event anyways, and the only consumer already
listened for them.
Differential Revision: https://phabricator.services.mozilla.com/D73175
Implement org.gnome.Shell.SearchProvider2 D-Bus interface and enable it when
widget.gnome-search-provider.enabled pref is set, so this feature is disabled
by default.
Differential Revision: https://phabricator.services.mozilla.com/D69181
This is in preparation for running the tail dispatcher off
nsIThreadObserver callbacks, which only work during regular
event processing.
Differential Revision: https://phabricator.services.mozilla.com/D72264
This is how it used to be, before the Quantum DOM stuff. We use
nsIThreadInternal because that supports thread observers, which we
leverage in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D71709
The `mozilla::IsPod<HashMapEntry` specialisation was only needed for the static
assertions in "js/src/frontend/NameCollections.h". Part 3 removed those, so we
can now also remove `mozilla::IsPod<HashMapEntry`.
Drive-by change:
- Remove no longer needed "mozilla/PodOperations.h" include in mfbt/HashTable.h.
- And then fix up previously transitively included files for RootingAPI.h,
jsfriendapi.h, and Bench.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D69201
The problem in https://bugzilla.mozilla.org/show_bug.cgi?id=325392 was
misdiagnosed and then a generic fix in
https://bugzilla.mozilla.org/show_bug.cgi?id=485834 (the kungFuDeathGrip
in nsObserverService::RemoveObserver) was based on the wrong diagnosis.
The root problem in bug 325392 was not that we were calling
nsObserverService::RemoveObserver from the destructor, and then
reentering the destructor. The refcounting code stabilizes the refcount
to 1 before calling the destructor to avoid reentering a destructor. The
real problem was that we were deleting an XPCOM object manually after
creation but without ever holding a strong reference to it, and so not
going through the refcount stabilization (and then the destructor can
reenter of course).
The generic fix in bug 485834 was based on the spotfix in bug 325392,
that was then backed out when the proper fix for that bug landed. I
don't think we should keep this kungfuDeathGrip, I ran into it because
it causes issues with refcount logging (refcount logging always had an
issue with refcounting from a destructor).
Differential Revision: https://phabricator.services.mozilla.com/D72300
CLOSED TREE
Backed out changeset 939611f65438 (bug 1630655)
Backed out changeset 2e05e81cc858 (bug 1630655)
Backed out changeset bfb074351550 (bug 1630655)
Ian Moody
Simon Giesecke
Razvan Maries
Bill Gianopoulos
Stephen A Pohl
Dorel Luca
Emilio Cobos Álvarez
Cosmin Sabou
Mihai Alexandru Michis
Mozilla Releng Treescript
Gerald Squelart
Bogdan Tara
Ricky Stewart
Tom Tung
Nicholas Nethercote
Mike Hommey
Doug Thayer
Martin Stransky
Daniel Varga
Eric Rahm
Jon Coppeard
Bobby Holley
André Bargull
Peter Van der Beken
Tom Schuster
Sylvestre Ledru
Bob Clary