Otherwise the global ImplCycleCollectionUnlink for JS members are shadowed by mozilla::dom::ImplCycleCollectionUnlink and can't be used.
Bug 1756794 is to move all the impls to the single namespace to prevent this, but that requires verbose changes, and currently the only affected uses are from these macros.
Differential Revision: https://phabricator.services.mozilla.com/D147234
Previously this was optimized to trace only gray roots in collecting zones, but
there was a bug in that it also skipped clearing roots because this happens
before the start of GC when zones are selected for collection.
Instead, make sure we only perform this optimziation when marking.
Differential Revision: https://phabricator.services.mozilla.com/D146585
This allows us to replace a number of magic numbers in the
WebRequestError code with automatically generated constants which are
guaranteed to be kept up to date.
This build script is able to run early enough during the build step as
generated files which take a `.jinja` file as an argument are hard-coded
to be run during the pre-export phase for Android builds. As it is just
as simple python script with no other dependencies, this shouldn't
impact geckoview build performance even when using build artifacts.
Differential Revision: https://phabricator.services.mozilla.com/D146356
In order to get better shutdown hang reporting, we want to distinguish also the last phases, namely `XPCOMShutdownThreads`, `XPCOMShutdownMainThread` and `CCPostLastCycleCollection`.
This also makes `XPCOMShutdownNotified()` obsolete and we need to slightly re-arrange the watchdog function.
Differential Revision: https://phabricator.services.mozilla.com/D145433
The concept of a shutdown phase is meant to be a finite and named period of time where:
1. we can query if we are in or beyond a given phase
2. we may want to do a fast shutdown
3. we inform the terminator that we reached the next phase
4. if needed/wanted, we notify observers of the associated topic
5. we KillClearOnShutdown smart pointers associated with this phase
6. we do any further, phase-individual cleanup until the next phase starts
`AdvanceShutdownPhase(WithoutNotify)` now provides the functionality for 1. through 5. and must be the only place that calls `KillClearOnShutdown` in order to avoid misalignments.
In doing so, it becomes also the only caller of `MaybeFastShutdown`.
Please refer to bug 1768581 as working on this patch made us think if we should re-work the order inside AdvanceShutdownPhase.
Differential Revision: https://phabricator.services.mozilla.com/D145083
The Android characters are are from DirectoryPaths.jsm, and almost all consumers of the constants here are either windows-specific or are modified/removed by this bug.
Differential Revision: https://phabricator.services.mozilla.com/D135956
The Android characters are are from DirectoryPaths.jsm, and almost all consumers of the constants here are either windows-specific or are modified/removed by this bug.
Differential Revision: https://phabricator.services.mozilla.com/D135956
The Android characters are are from DirectoryPaths.jsm, and almost all consumers of the constants here are either windows-specific or are modified/removed by this bug.
Differential Revision: https://phabricator.services.mozilla.com/D135956
The strategy of this patch and most following patches is, returning candidate
caret position with `CreateNodeResultBase`, and make each caller choose whether
it updates `Selection` immediately, put it off until exiting from a loop, or
just ignore.
This patch makes `HTMLEditor::HandleInsertBRElement` return
`CreateElementResult` and makes its callers handle selection as same as the
method does.
And note that I've not realized that `NS_FAILED` and `NS_SUCCEEDED` include
`MOZ_(UN)LIKELY`. Therefore, they don't need to be wrapped with them. And
also `NS_WARN_IF` has it too (but it's not in opt build, see bug 1765909).
On the other hand, neither `Result::isErr` nor `Result::isOk` has them
(bug 1765916). Therefore, except in the case of `Result`, this and following
patches will remove unnecessary `MOZ_(UN)LIKELY` from editor.
Differential Revision: https://phabricator.services.mozilla.com/D144644
Due to how this type of threadsafe refcounting is implemented, it needs to be
implemented using a MFBT-style refcounting base class, somewhat similar to
`SupportsWeakPtr`.
This patch makes NS_IMPL_{ADDREF,RELEASE}_INHERITED intelligently not add
refcount logging for types inheriting from SupportsThreadSafeWeakPtr, as the
default behaviour would break due to weak pointer upgrades not calling through
`AddRef` or `Release`.
In MFBT, the return value of `AddRef` and `Release` on
SupportsThreadSafeWeakPtr is changed to be compatible with nsISupports, so that
this type can be used to implement nsISupports refcounting.
Differential Revision: https://phabricator.services.mozilla.com/D142603
HeapObjectPostWriteBarrier adds or removes a store buffer entry for a change in
the GC graph entry based on the second and third arguments which are the target
of the edge before and after the change.
This patch also removes the store buffer entry in
nsWrapperCache::ReleaseWrapper which didn't happen before. This should help
keep less garbage alive unnecessarily.
Differential Revision: https://phabricator.services.mozilla.com/D143736
This stops the checker complaining that locks aren't held by adding further
annotations and doing some locking slightly earlier.
I've tried to adhere to the convention of passing a lock when a function
requires it, though I don't believe we have to do so to make the checker happy.
Differential Revision: https://phabricator.services.mozilla.com/D143003
For example, the SDK class android.media.MediaDrm$KeyStatus will now
be defined as MediaDrm::KeyStatus rather than just KeyStatus.
Not only does this avoid polluting the top-level namespace, but it
also avoids a bug where invalid type names were generated if the
nested class contains a method with a parameter or return of the outer
class' type.
Differential Revision: https://phabricator.services.mozilla.com/D143043