This patch changes how BrowsingContextGroups track CrossOriginIsolated
status such that it should be more consistently tracked and easier to
assert in the places which depend on it. In the new state of the world,
a flag is stored within the BCG's ID which tracks whether it was
created for cross-origin isolated documents, and that is also checked
when making decisions about how to isolate initial about:blank
documents, and whether to allow certain changes to
CrossOriginOpenerPolicy.
This flag is stashed within the ID, as it needs to be preserved if the
BCG is destroyed and then re-created from the ID (which may be e.g.
round-tripped through JS code). I also considered making the ID be a
string instead, to make it easier to include extra information like
this, and more clear where the information is stored, however :kmag
generally preferred using a bit within the integer ID.
These new assertions should now be less likely to spuriously fail due to
a DocShell disappearing or similar as well, which should help fix the
original issue.
Differential Revision: https://phabricator.services.mozilla.com/D152695
This should help avoid crashes caused when the content process has
already destroyed a BCG when the parent process hasn't yet. The BCG will
still be destroyed when the content process shuts down using normal
cycle-collection.
Differential Revision: https://phabricator.services.mozilla.com/D113828
This should help avoid crashes caused when the content process has
already destroyed a BCG when the parent process hasn't yet. The BCG will
still be destroyed when the content process shuts down using normal
cycle-collection.
Differential Revision: https://phabricator.services.mozilla.com/D113828
Running AssertDocGroupMatchesKey() on an unlinked document can cause
a crash in debug builds, so pass in the group directly, because all
of the callers are Documents so they already have it.
Differential Revision: https://phabricator.services.mozilla.com/D115272
This should help avoid crashes caused when the content process has
already destroyed a BCG when the parent process hasn't yet. The BCG will
still be destroyed when the content process shuts down using normal
cycle-collection.
Differential Revision: https://phabricator.services.mozilla.com/D113828
The issues with BrowsingContextGroup identity may be related to using a
destroyed BrowsingContextGroup in some situations when we shouldn't be. By
upgrading the intensity of these assertions, we should be able to catch the
issues more readily.
Differential Revision: https://phabricator.services.mozilla.com/D108117
There are two issues in our current setup
1) Input events which are occurring in the same tab are going to be lost
because sync XHR. We have event handling suppression for synx XHR, so input
events are going to be discarded.
2) Input events that are happening in another tab (same process as the
synx XHR tab) are not going to be delayed. This is not correct since
sync XHR should block the Javascript execution.
This patches fixes the above cases for when both TaskController and e10s are
enabled by suspending the InputTaskManager during sync XHR, which
delays the input event handling and keeps the events around.
Differential Revision: https://phabricator.services.mozilla.com/D90780
There are two issues in our current setup
1) Input events which are occurring in the same tab are going to be lost
because sync XHR. We have event handling suppression for synx XHR, so input
events are going to be discarded.
2) Input events that are happening in another tab (same process as the
synx XHR tab) are not going to be delayed. This is not correct since
sync XHR should block the Javascript execution.
This patches fixes the above cases for when both TaskController and e10s are
enabled by suspending the InputTaskManager during sync XHR, which
delays the input event handling and keeps the events around.
Differential Revision: https://phabricator.services.mozilla.com/D90780
When a tab is owning a main controller, which means that the tab is either playing media, or still waiting for media keys in order to control its media again.
In those situations, we should not suspend the tab so that its script can continue to run for playing media or handling the future task for media keys.
Differential Revision: https://phabricator.services.mozilla.com/D93445
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
Emilio Cobos Álvarez
Olli Pettay
Nika Layzell
Anny Gakhokidze
Dorel Luca
Andrew McCreight
Narcis Beleuzu
Simon Giesecke
Csoregi Natalia
Sean Feng
Razvan Maries
alwu
Butkovits Atila
James Willcox
Andreea Pavel
Bogdan Tara
Andreas Farre
Aaron Klotz
Brindusan Cristian