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
One could possibly make larger changes to make the setup less error prone, but hopefully we'll
replace this code with the new scheduler relatively soon.
And the assertion there should still enforce correct behavior.
Differential Revision: https://phabricator.services.mozilla.com/D69988
--HG--
extra : moz-landing-system : lando
