This should ensure that any BrowsingContexts racily created during the discard
process don't end up creating a separate BrowsingContextGroup from their
relatives, and triggering group mismatch assertions.
Differential Revision: https://phabricator.services.mozilla.com/D84548
This requires keeping track of the current process used to host documents with a
particular remote type loaded in each BrowsingContextGroup. Due to lifecycle
oddities, this set is kept separate from the existing subscribers set on
BrowsingContextGroup.
Differential Revision: https://phabricator.services.mozilla.com/D84061
This should ensure that any BrowsingContexts racily created during the discard
process don't end up creating a separate BrowsingContextGroup from their
relatives, and triggering group mismatch assertions.
Differential Revision: https://phabricator.services.mozilla.com/D84548
This requires keeping track of the current process used to host documents with a
particular remote type loaded in each BrowsingContextGroup. Due to lifecycle
oddities, this set is kept separate from the existing subscribers set on
BrowsingContextGroup.
Differential Revision: https://phabricator.services.mozilla.com/D84061
This avoids problems where a foreground tab tries to communicate with a background
tab via `window.opener`, but is unable to because the background tab
is suspended.
Differential Revision: https://phabricator.services.mozilla.com/D83693
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 existing infrastructure which stored cached BrowsingContexts on the
BrowsingContextGroup was added before WindowContexts were added, and can cause
racing issues with partially discarded trees during process switches.
Differential Revision: https://phabricator.services.mozilla.com/D71238
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 existing infrastructure which stored cached BrowsingContexts on the
BrowsingContextGroup was added before WindowContexts were added, and can cause
racing issues with partially discarded trees during process switches.
Differential Revision: https://phabricator.services.mozilla.com/D71238
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 existing infrastructure which stored cached BrowsingContexts on the
BrowsingContextGroup was added before WindowContexts were added, and can cause
racing issues with partially discarded trees during process switches.
Differential Revision: https://phabricator.services.mozilla.com/D71238
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 existing infrastructure which stored cached BrowsingContexts on the
BrowsingContextGroup was added before WindowContexts were added, and can cause
racing issues with partially discarded trees during process switches.
Differential Revision: https://phabricator.services.mozilla.com/D71238
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 existing infrastructure which stored cached BrowsingContexts on the
BrowsingContextGroup was added before WindowContexts were added, and can cause
racing issues with partially discarded trees during process switches.
Differential Revision: https://phabricator.services.mozilla.com/D71238
TabGroup never really made any difference in which thread something go
dispatched to. This was the intended use, but development of TabGroups
with abstract main threads never made it that far. The good thing is
that thish makes it safe to also remove to the SystemGroup and instead
switch all SystemGroup dispatches to dispatches to main thread.
Timers for setTimeout and workers were the sole users of wrapped and
throttled event targets, that those throttled queues have been moved
to the BrowsingContextGroup and are now accessed explicitly.
The SchedulerEventTarget has been removed, since there are no longer a
separate event target for every TaskCategory. Instead a
LabellingEventTarget has been added to DocGroup to handle the case
where an event is dispatched do DocGroup or when an AbstractThread is
created using a DocGroup. This means that we'll actually label more
events correctly with the DocGroup that they belong to.
DocGroups have also been moved to BrowsingContextGroup.
Depends on D67636
Differential Revision: https://phabricator.services.mozilla.com/D65936
--HG--
extra : moz-landing-system : lando
By having CollectPerformanceInfo traverse the BrowsingContextGroup and
tree of BrowsingContexts we can hide the task of getting the DocGroups
befind an API in BrowsingContextGroup and ease the removal of
TabGroups.
Differential Revision: https://phabricator.services.mozilla.com/D64390
--HG--
extra : moz-landing-system : lando
Bug 1534012 added a test for postMessage during load and that revealed that mLoading flag isn't always updated
soon enough, so add BrowsingContext::IsLoading which checks also possible local loading status.
Depends on D54754
Differential Revision: https://phabricator.services.mozilla.com/D54836
--HG--
extra : moz-landing-system : lando
This also allows us to remove TabGroup::FindItemWithName, which is a
big step towards removing TabGroup entirely.
Differential Revision: https://phabricator.services.mozilla.com/D46285
--HG--
extra : moz-landing-system : lando
This also allows us to remove TabGroup::FindItemWithName, which is a
big step towards removing TabGroup entirely.
Differential Revision: https://phabricator.services.mozilla.com/D46285
--HG--
extra : moz-landing-system : lando
We can remove references held in the ContentChild and the ContentParent once the BrowsingContextGroup becomes empty.
This allows to break the cycles and the BrowsingContextGroup to be deleted.
Differential Revision: https://phabricator.services.mozilla.com/D38180
--HG--
extra : moz-landing-system : lando
In order to not have detach called on non-existent BrowsingContexts,
we need to hold browsing contexts alive until the lifetime of
ContentChild has ended.
Differential Revision: https://phabricator.services.mozilla.com/D29782
In order to not have detach called on non-existent BrowsingContexts,
we need to hold browsing contexts alive until the lifetime of
ContentChild has ended.
Differential Revision: https://phabricator.services.mozilla.com/D29782
Add the origin ContentParent to a CanonicalBrowsingContext's group
when a CanonicalBrowsingContext is created from IPC. With this it is
possible to keep track of all child processes associated with a
BrowsingContextGroup.
Differential Revision: https://phabricator.services.mozilla.com/D19004
--HG--
extra : moz-landing-system : lando
Add the origin ContentParent to a CanonicalBrowsingContext's group
when a CanonicalBrowsingContext is created from IPC. With this it is
possible to keep track of all child processes associated with a
BrowsingContextGroup.
Differential Revision: https://phabricator.services.mozilla.com/D19004
--HG--
extra : moz-landing-system : lando
Nika Layzell
Butkovits Atila
Simon Giesecke
James Willcox
Narcis Beleuzu
Andreea Pavel
Dorel Luca
Bogdan Tara
Andreas Farre
Aaron Klotz
Brindusan Cristian
Olli Pettay
Jean-Yves Avenard
Kyle Machulis
Razvan Maries