Due to changes in how processes are selected when doing BFCached
navigations, the process will be re-used for the navigation meaning we
no longer need to add logic explicitly keeping it alive.
This also tweaks the code which checks this to explicitly stop checking
any keepProcessesAlive prefs for these origin-specific remote types.
Differential Revision: https://phabricator.services.mozilla.com/D220191
1. Modify nsToolkitProfileService to support roaming profiles passed in
via the "-profile /path/to/profile/" command line option but not
present in profiles.ini.
With this patch, when a profile is supplied via the "-profile
/path/to/profile/" command line option, if the root dir path is not found
in profiles.ini, and if its path is a relative path, then we either use or
create a corresponding local dir.
Previously for unmanaged profiles, we would not look for a local dir,
instead just using the root dir to hold the various local ephemeral
caches. This change is necessary to prevent degraded filesystem
performance for roaming / enterprise users who adopt selectable
profiles.
This patch also adds roaming profile support for profiles passed in
via XRE_PROFILE_PATH, finding/creating a local dir if the root dir is
relative, event if XRE_PROFILE_LOCAL_PATH is null or does not exist.
These environment variables are typically set as part of an app-managed
restart, for example, after choosing a profile in the Profile Manager.
2. Add a new method to the SelectableProfileService to launch a new
Firefox instance, using --profile to pass an unmanaged profile path.
This is necessary because selectable profiles will not be listed in
profiles.ini, but users will need to launch them by selecting them in
UI entries (like menu items).
3. Refactor some duplicated code into `EnsureDirExists` and
`GetLocalDirFromRootDir` helpers in nsToolkitProfileService.
See also bug 1913383 for further planned cleanup work.
4. Add a groupProfile property to nsToolkitProfileService.
This ensures SelectableProfileService.#groupToolkitProfile will always
be set, so that we can set or unset rootDir and StoreID as users upgrade
to multiple profiles, launch Firefox from a selectable profile, or
downgrade back to a single profile.
Differential Revision: https://phabricator.services.mozilla.com/D218149
gNotificationBox doesn't go there anymore (it goes inside the toolbox),
so we have really no use for that.
Simplify how the devtools theme is set on the browser, so that it is set
on the root.
Differential Revision: https://phabricator.services.mozilla.com/D220769
Hopefully this comment and marker will make it so that we don't have to
chase any ghosts in rr in the future to understand what dirtyFrame is
doing!
Differential Revision: https://phabricator.services.mozilla.com/D215794
This is a fairly significant patch, however it would be difficult to break it
down into smaller patches:
1) The various mechanisms used to manage ContentParent lifecycles have been
merged together into a common "KeepAlive" system. A process will
begin shutdown when its keepalive count reaches 0. (though it will
still wait for all BrowserParents to also be dead before sending the
actual shutdown message as before).
This replaces a number of bespoke systems for tracking BrowserParent
instances in different lifecycle states, remote workers, ongoing
process switches, and preallocated processes.
2) KeepAlives are now managed automatically by a UniquePtr variant
(Unique[Threadsafe]ContentParentKeepAlive). This makes the hand-off
over KeepAlive lifecycles explicit, even for workers.
3) All KeepAlives are now keyed by a BrowserId, which will be 0 for keepalives
not associated with a specific tab. This allows the new process
selection logic to count all tabs other than the one being navigated
when deciding which process to use.
4) The process switching logic now tracks it's KeepAlive with a BrowserId,
meaning that ongoing process switches are considered when performing
process selection, even if the BrowserParent hasn't been created yet.
Differential Revision: https://phabricator.services.mozilla.com/D213338
This is a fairly significant patch, however it would be difficult to break it
down into smaller patches:
1) The various mechanisms used to manage ContentParent lifecycles have been
merged together into a common "KeepAlive" system. A process will
begin shutdown when its keepalive count reaches 0. (though it will
still wait for all BrowserParents to also be dead before sending the
actual shutdown message as before).
This replaces a number of bespoke systems for tracking BrowserParent
instances in different lifecycle states, remote workers, ongoing
process switches, and preallocated processes.
2) KeepAlives are now managed automatically by a UniquePtr variant
(Unique[Threadsafe]ContentParentKeepAlive). This makes the hand-off
over KeepAlive lifecycles explicit, even for workers.
3) All KeepAlives are now keyed by a BrowserId, which will be 0 for keepalives
not associated with a specific tab. This allows the new process
selection logic to count all tabs other than the one being navigated
when deciding which process to use.
4) The process switching logic now tracks it's KeepAlive with a BrowserId,
meaning that ongoing process switches are considered when performing
process selection, even if the BrowserParent hasn't been created yet.
Differential Revision: https://phabricator.services.mozilla.com/D213338
This is a fairly significant patch, however it would be difficult to break it
down into smaller patches:
1) The various mechanisms used to manage ContentParent lifecycles have been
merged together into a common "KeepAlive" system. A process will
begin shutdown when its keepalive count reaches 0. (though it will
still wait for all BrowserParents to also be dead before sending the
actual shutdown message as before).
This replaces a number of bespoke systems for tracking BrowserParent
instances in different lifecycle states, remote workers, ongoing
process switches, and preallocated processes.
2) KeepAlives are now managed automatically by a UniquePtr variant
(Unique[Threadsafe]ContentParentKeepAlive). This makes the hand-off
over KeepAlive lifecycles explicit, even for workers.
3) All KeepAlives are now keyed by a BrowserId, which will be 0 for keepalives
not associated with a specific tab. This allows the new process
selection logic to count all tabs other than the one being navigated
when deciding which process to use.
4) The process switching logic now tracks it's KeepAlive with a BrowserId,
meaning that ongoing process switches are considered when performing
process selection, even if the BrowserParent hasn't been created yet.
Differential Revision: https://phabricator.services.mozilla.com/D213338
If there is at least one record for expected I/O, but all of them have
`ignoreIfUnused: true`, and no I/O is reported, then the tests should
succeed (they are all unused and thus ignored). There's a check which
expects to see I/O markers in that case, so this patch conditionally
skips it. (Also: fix some pre-existing typos pointed out in review.)
Differential Revision: https://phabricator.services.mozilla.com/D212632
In bug 1804140, we shipped SHIP everywhere on desktop. Unfortunately, we
never removed the now-dead code from SessionStore.
This patch removes the easy to identify SessionStore code for non-SHIP,
now that it is a fully unsupported configuration.
Differential Revision: https://phabricator.services.mozilla.com/D205479
In bug 1804140, we shipped SHIP everywhere on desktop. Unfortunately, we
never removed the now-dead code from SessionStore.
This patch removes the easy to identify SessionStore code for non-SHIP,
now that it is a fully unsupported configuration.
Differential Revision: https://phabricator.services.mozilla.com/D205479
When I rewrote nsMenuPopupFrame, I made sure percentage sizes worked so
that we could do stuff like this.
This removes some complex code, and improves the behavior on platforms
where screen sizes might not be 100% reliable.
Differential Revision: https://phabricator.services.mozilla.com/D204754
* Flip the component pref to true by default for nightly builds only
* Move the pref check and initialization to a startup idle task
* And be a bit smarter about when we get and disable the addon
* Fix a bug where we try to communicate with the overlay after the window actor is destroyed when
the component pref gets flipped off during use
Differential Revision: https://phabricator.services.mozilla.com/D196888
* Flip the component pref to true by default for nightly builds only
* Move the pref check and initialization to a startup idle task
* And be a bit smarter about when we get and disable the addon
* Fix a bug where we try to communicate with the overlay after the window actor is destroyed when
the component pref gets flipped off during use
Differential Revision: https://phabricator.services.mozilla.com/D196888
* Flip the component pref to true by default for nightly builds only
* Move the pref check and initialization to a startup idle task
* And be a bit smarter about when we get and disable the addon
* Fix a bug where we try to communicate with the overlay after the window actor is destroyed when
the component pref gets flipped off during use
Differential Revision: https://phabricator.services.mozilla.com/D196888
* Flip the component pref to true by default for nightly builds only
* Move the pref check and initialization to a startup idle task
* And be a bit smarter about when we get and disable the addon
* Fix a bug where we try to communicate with the overlay after the window actor is destroyed when
the component pref gets flipped off during use
Differential Revision: https://phabricator.services.mozilla.com/D196888
This moves handling of the preferences and log value setting into ConsoleInstance, which is where the preferences
are received. It also makes ConsoleInstance add a listener on the preferences service so that updates are triggered.
The functionality is already covered by dom/console/tests/test_jsm.xhtml
Differential Revision: https://phabricator.services.mozilla.com/D199657
