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)
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
This allows us to explicitly specify BrowsingContextGroups when synchronizing
them. A major advantage of this is that it means we can handle an attempt to
create a BrowsingContext with a parent which the content process is unaware of,
which is possible due to changes to the EnsureSubscribed logic in earlier
patches in this stack.
This is OK, because in the case where the content process cannot see its parent,
the parent must be imminently discarding.
Differential Revision: https://phabricator.services.mozilla.com/D71668
The AppendElements overload accepting a mozilla::Array<Item, Length> is
redundant, since that is convertible to a mozilla::Span<const Item>, for which
a separate overload exists.
Differential Revision: https://phabricator.services.mozilla.com/D70386
This allows us to explicitly specify BrowsingContextGroups when synchronizing
them. A major advantage of this is that it means we can handle an attempt to
create a BrowsingContext with a parent which the content process is unaware of,
which is possible due to changes to the EnsureSubscribed logic in earlier
patches in this stack.
This is OK, because in the case where the content process cannot see its parent,
the parent must be imminently discarding.
Differential Revision: https://phabricator.services.mozilla.com/D71668
- Clones selection ranges to the static document for printing
- Static docs can remove selections without referring to original doc
Differential Revision: https://phabricator.services.mozilla.com/D71110
This allows us to explicitly specify BrowsingContextGroups when synchronizing
them. A major advantage of this is that it means we can handle an attempt to
create a BrowsingContext with a parent which the content process is unaware of,
which is possible due to changes to the EnsureSubscribed logic in earlier
patches in this stack.
This is OK, because in the case where the content process cannot see its parent,
the parent must be imminently discarding.
Differential Revision: https://phabricator.services.mozilla.com/D71668
This allows us to explicitly specify BrowsingContextGroups when synchronizing
them. A major advantage of this is that it means we can handle an attempt to
create a BrowsingContext with a parent which the content process is unaware of,
which is possible due to changes to the EnsureSubscribed logic in earlier
patches in this stack.
This is OK, because in the case where the content process cannot see its parent,
the parent must be imminently discarding.
Differential Revision: https://phabricator.services.mozilla.com/D71668
This allows us to explicitly specify BrowsingContextGroups when synchronizing
them. A major advantage of this is that it means we can handle an attempt to
create a BrowsingContext with a parent which the content process is unaware of,
which is possible due to changes to the EnsureSubscribed logic in earlier
patches in this stack.
This is OK, because in the case where the content process cannot see its parent,
the parent must be imminently discarding.
Differential Revision: https://phabricator.services.mozilla.com/D71668
It was required once upon a time to be able to use MozPromise on Workers.
Today a MozPromise work with nsISerialEventTarget and no longer rely on this. It can go.
Differential Revision: https://phabricator.services.mozilla.com/D71442
AutoEnter was an attempt around a race between AbstractThread and MessageLoopAbstractThreadWrap that would cause AbstractThread::GetCurrent() to return an incorrect value. MessageLoopAbstractThreadWrapper is no more and as such AutoEnter is no longer required.
Differential Revision: https://phabricator.services.mozilla.com/D71279
prior bug 1364821, AbstractThread::GetCurrent() would always return AbstractThread::MainThread() when called from the main thread.
After this change, we had to run within an AutoEnter scope.
A hidden side effect of this change was that under most cases AbstractThread::MainThread::Dispatch() would no longer use the tail dispatcher to dispatch a task.
It can be safely assume that whenever you're on the main thread, the equivalent AbstractThread is usable.
In the next commit, we will be removing AutoEnter entirely.
Differential Revision: https://phabricator.services.mozilla.com/D71148
Currently the JS holders table is represented as a map which contains pointers to entries in a SegmentedVector. This patch keeps the single map but use a vector per zone and also has a catch-all vector for where we don't know the zone or the holder can have pointers to more than one zone.
Differential Revision: https://phabricator.services.mozilla.com/D68522
Currently we get a rooting hazard when nsWrapperCache::UpdateWrapperForNewGlobal calls ReleaseWrapper because the analysis can't see through the virtual method call.
Differential Revision: https://phabricator.services.mozilla.com/D71600
Currently, to remove a holder entry from a vector we swap the entry with the last one in the vector and then shrink the vector (and fix up the map). With per-zone vectors we won't have a reference to the vector to get the last entry. One solution would be to store the zone in the entry and look up the vector in a map but I'd like to avoid this if possible because of the space overhead and the extra lookup.
This patch defers clears the entry's pointers when it is removed and actually removes it when the vector is next iterated.
Differential Revision: https://phabricator.services.mozilla.com/D68518
Relaxes the type constraints for span overloads on `nsTArray`, such as
`AppendElements`. They previously took `Span<const Item>`, which could cause
build errors when attempting to pass a non const-qualified Item such as in
`Span<RefPtr<BrowsingContext>>`.
Differential Revision: https://phabricator.services.mozilla.com/D71232
Prior to this patch, the startupcache created its own mWriteThread off which it
wrote to disk. It's initialized by MaybeSpawnWriteThread, which got called
at shutdown, to do the shutdown write if there was any reason to do so, and
from a timer that is re-initialized after every addition to the startup cache,
to run 60s after the last change to the cache.
It then joined that write thread on the main thread (in other words, blocks
on that off-main-thread write completing from the main thread) when:
- xpcom-shutdown fired
- the startupcache itself gets destroyed
- someone calls any of:
* HasEntry
* GetBuffer
* PutBuffer
* InvalidateCache
This patch removes the separate write thread, and instead dispatches a task to
the background task queue, indicating it can block. The task is started in
the same circumstances where we previously used to write (timer from the last
PutBuffer call, and shutdown if necessary).
To ensure it cannot be trying to use the data it writes out (mTable) from
the other thread while that data changes on the main thread, we use a mutex.
The task locks the mutex before starting, and unlocks when finished.
Enumerating the cases that we used to block on joining the thread:
In terms of application shutdown, we expect the background task queue to
either finish the write task, or fail to run it if it hasn't started it yet.
In the FastStartup case, we check if a write was necessary; if so, we
attempt to gain the lock without waiting. If we're successful, the write has
not yet started, and we instead run the write on the main thread. Otherwise,
we retry gaining the lock, blocking this time, thus guaranteeing the
off-the-main-thread write completes.
The task keeps a reference to the startupcache object, so it cannot be
destroyed while the task is pending.
Because the write does not modify `mTable`, and neither does `HasEntry`,
we do not need to do anything there.
In the `GetBuffer` case, we do not modify the table unless we have to read
the entry off disk (memmapped into `mCacheData`). This can only happen if
`mCacheData.initialized()` returns true, and we specifically call
`mCacheData.reset()` before firing off the write task to avoid this.
`mCacheData` is only re-initialized if someone calls `LoadArchive()`,
which can only happen from `Init()` (which is guaranteed not to run
again because this is a singleton), or `InvalidateCache()`, where we lock
the mutex (see below). So this is safe - but we assert on the lock to try
and avoid people breaking this chain of assumptions in the future.
When `PutBuffer` is called, we try to lock the mutex - but if locking fails
(ie the background thread is writing), we simply fail to store the entry
in the startupcache. In practice, this should be rare - it'd happen if
new calls to PutBuffer happen while writing during shutdown (when really,
we don't care) or when it's been 60 seconds since the last PutBuffer so
we started writing the startupcache.
When InvalidateCache is called, we lock the mutex - we shouldn't try to
write while invalidating, or invalidate while writing. This may be slow,
but in practice nothing should call `InvalidateCache` except developer
restarts or the `-purgecaches` commandline flag, so it shouldn't
matter a great deal.
Differential Revision: https://phabricator.services.mozilla.com/D70413
--HG--
extra : moz-landing-system : lando
Unlinking, such as in UnbindFromTree, can add runnables that keep alive CCed
objects after they have been unlinked. In combination with some unknown
fields not being traversed and unlinked this could cause intermittent shutdown
leaks, if those unknown fields hold alive objects that need the CC to be
collected. Work around this by clearing out these runnables after every
shutdown CC.
Also, fix the order of these two steps, which was apparently wrong
before.
Differential Revision: https://phabricator.services.mozilla.com/D71049
--HG--
extra : moz-landing-system : lando
This pattern:
```
native nsSize (nsSize);
^
```
Causes a parsing error in `ply` 3.10. This can be easily fixed by removing the space and reformatting to this:
```
native nsSize(nsSize);
```
Differential Revision: https://phabricator.services.mozilla.com/D70711
--HG--
extra : moz-landing-system : lando
L3 cache being present in /proc/cpuinfo is an Intel-ism. Use the cross-platform
/sys/devices instead.
Differential Revision: https://phabricator.services.mozilla.com/D70892
--HG--
extra : moz-landing-system : lando
The patch makes sure the checkSingleZoneHolders variable is always present. I expect it will get optimised away in builds where it's unused.
Differential Revision: https://phabricator.services.mozilla.com/D70818
--HG--
extra : moz-landing-system : lando
The patch makes sure the checkSingleZoneHolders variable is always present. I expect it will get optimised away in builds where it's unused.
Differential Revision: https://phabricator.services.mozilla.com/D70818
--HG--
extra : moz-landing-system : lando
Bogdan Tara
Ricky Stewart
Tom Tung
Nicholas Nethercote
Mike Hommey
Doug Thayer
Emilio Cobos Álvarez
Simon Giesecke
Martin Stransky
Daniel Varga
Eric Rahm
Jon Coppeard
Bobby Holley
André Bargull
Peter Van der Beken
Tom Schuster
Sylvestre Ledru
Mihai Alexandru Michis
Bob Clary
Nika Layzell
Narcis Beleuzu
Erik Nordin
Andreea Pavel
Dorel Luca
Alexander Surkov
Lina Cambridge
Emma Malysz
Jean-Yves Avenard
Ciure Andrei
Noemi Erli
Andrew McCreight
Robert Longson
Cosmin Sabou
Valentin Gosu
Konstantin Morozov
Gijs Kruitbosch
Kristen Wright
Chris H-C