I don't think the intermittent failures here are an indication of a true
problem here, more of a problem with how it's possible to test this code.
Differential Revision: https://phabricator.services.mozilla.com/D115330
With Fission, there can be multiple BrowserParents in a single tab, so
this patch moves the tracking of active tabs onto the top BrowsingContext
in a tab. If the priority of a top BC is changed, then the activity
of all of the BPs of the BCs in the tree are all adjusted. The flag
that tracks this state gets carried forward to the new BC in the case
of a cross-group navigation by the changes in ReplacedBy().
The other change here covers the case where we do a process-switching
navigation on an iframe. If we create a new BrowserParent with an active
top BC, then the BP gets marked as active in the priority manager. Doing
this tracking on the BP instead of the BC (both here in and in the part
that landed previously in BrowserParent::Deactivated()) means that we
don't need to track down every place that a BC switches processes.
I left the tracking of activity in ParticularProcessPriorityManager
centered around BrowserParents, instead of changing it to BCs, to
minimize the changes required. There are some tricky interactions there
with wakelocks that I didn't want to have to figure out.
browser_ProcessPriorityManager.js was set up to track a mapping of
browsers to priorities, but for the purposes of testing Fission support
I changed it to track a mapping of child IDs to priorities.
In the test, I also removed an assignment (this.window = null) that
didn't seem to be doing anything.
Differential Revision: https://phabricator.services.mozilla.com/D112213
With Fission, there can be multiple BrowserParents in a single tab, so
this patch moves the tracking of active tabs onto the top BrowsingContext
in a tab. If the priority of a top BC is changed, then the activity
of all of the BPs of the BCs in the tree are all adjusted. The flag
that tracks this state gets carried forward to the new BC in the case
of a cross-group navigation by the changes in ReplacedBy().
The other change here covers the case where we do a process-switching
navigation on an iframe. If we create a new BrowserParent with an active
top BC, then the BP gets marked as active in the priority manager. Doing
this tracking on the BP instead of the BC (both here in and in the part
that landed previously in BrowserParent::Deactivated()) means that we
don't need to track down every place that a BC switches processes.
I left the tracking of activity in ParticularProcessPriorityManager
centered around BrowserParents, instead of changing it to BCs, to
minimize the changes required. There are some tricky interactions there
with wakelocks that I didn't want to have to figure out.
browser_ProcessPriorityManager.js was set up to track a mapping of
browsers to priorities, but for the purposes of testing Fission support
I changed it to track a mapping of child IDs to priorities.
In the test, I also removed an assignment (this.window = null) that
didn't seem to be doing anything.
Differential Revision: https://phabricator.services.mozilla.com/D112213
The telemetry is triggered either when the user is shown the tab crashed page, or when the subframe notification is displayed and the crash occurs in an active tab, or when the user switches to a tab that has a subframe crash notification displayed. The telemetry only applies the first time the tab is switched to. The unsubmitted crashes notification bar appears after 10 minutes or so and is shown in the top-most browser window, if one exists, and telemetry applies once when this occurs.
Differential Revision: https://phabricator.services.mozilla.com/D100349
Currently, when JS callers try to access certain JSWindowActors before an
actor is initialized, or after it's destroyed, we throw a generic
`NS_ERROR_INVALID_STATE_ERROR` exception without any useful information about
the failure.
This patch changes that to use `ThrowInvalidStateError`, with a message
including the property name, the actor name, and details about whether the
error occurred because the actor has not been initialized or because it has
already been destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D96628
To force navigation to block on the long running script it needs to be
loading a page on the same domain as the blocking script, otherwise
fission and Session history in the parent will happily change
remoteness to another process and load immediately.
Depends on D90825
Differential Revision: https://phabricator.services.mozilla.com/D90826
There must be no pending exceptions on the JSContext when returning from a
native promise handler. We were not successfully clearing exceptions in all
cases in JSActor logic, meaning that query replies with unserializable data
would cause debug-mode crashes.
This patch handles JSActor's code, but doesn't improve the situation for other
native promise handlers which could throw exceptions.
Differential Revision: https://phabricator.services.mozilla.com/D87110
It's possible to end up in a situation where the window global has been set on
the BrowsingContext, but hasn't yet been initialized. Proceeding at this point
results in the document having a stale URI (about:blank in this case). Waiting
for a "window-global-created" instead should ensure that everything has been
initialized before we proceed.
Differential Revision: https://phabricator.services.mozilla.com/D86764
Steve Fink
Paul Bone
Nika Layzell
Andrew McCreight
Noemi Erli
Olli Pettay
Joel Maher
Christoph Kerschbaumer
Kris Maglione
Mark Striemer
Andreea Pavel
Neil Deakin
Jens Stutte
Cosmin Sabou
Kagami Sascha Rosylight
Csoregi Natalia
Alexis Beingessner
Kartik Gautam
Emilio Cobos Álvarez
alwu
Andreas Farre
Kashav Madan