This lets the idle scheduler know that we've initiated a GC that we didn't
ask its permission for. Eg the JS engine hit a threshold. It now uses this
info when scheduling GCs for other processes.
Differential Revision: https://phabricator.services.mozilla.com/D120831
This patch launches content processes with the `MOZ_HEADLESS` env var set
if they're using GTK with an X11 display (and there's no other reason
they'd need GTK).
The goal is to avoid exhausting Xorg's default limit of 256 clients if
there are many content processes due to Fission. If these conditions
are met, the content process doesn't need to eagerly connect to the X
server. This does not affect the sandbox policy, and content processes
can still use X if needed for, e.g., WebGL.
The boolean pref `dom.ipc.avoid-gtk`, set by default, controls this
feature. In the future it could also be extended to minimize GTK use
with Wayland displays.
Note that disabling `widget.non-native-theme.enabled`, which is also
enabled by default, will restore the use of X11 in all content processes
even if this pref is set; the alternative is that widgets wouldn't render
in that case.
This change will also save some memory for now-unnecessary instances of
GTK's global state, and improve content process startup time.
Remove also the temp pref dom.ipc.remote-mozIcon because it cannot work
anymore with the content process being headless.
Differential Revision: https://phabricator.services.mozilla.com/D112197
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