This is a little tricky since some behaviour must be in the profile
service while some is more naturally in the background tasks mechanism.
Essentially, some background tasks will have a consistent profile
location determined by their "profile prefix", which includes vendor,
installation hash, and background task name. Right now, those tasks are
determined by their task name, but in the future we could make this more
flexible.
A few technical notes:
1. I elected to not assume (or provide) a directory service provider
in the relevant helper, mostly to ease future commits that might
pull this functionality forward in the startup process.
2. These background task profiles are placed in "Background Tasks
Profiles" on relevant platforms (non-Unix and macOS), sibling to
"Profiles".
3. To avoid any possible vulnerability with predictable profile
directories, these non-ephemeral background task profiles are
salted. An entry is placed in the `BackgroundTasksProfiles` section
of `profiles.ini` mapping the profile prefix to the relative salted
path.
Differential Revision: https://phabricator.services.mozilla.com/D149919
This allows the profile service to handle `XRE_PROFILE_PATH`,
`--profile`, etc as normal before choosing a "default" background task
profile directory.
Differential Revision: https://phabricator.services.mozilla.com/D149918
This patch won't actually build, because a few bits of code are used
for both nsIFactory::createInstance and static components, and static
components are not fixed until the next patch.
The first place is nsLoadGroupConstructor, which uses an nsIFactory
macro to create a static component constructor. (This could be worked
around by expanding the macro to the state before this patch.)
The other issue is that nsAppShellConstructor is used in an nsIFactory
on OSX, but as a static component on all other platforms. This could
be worked around by wrapping nsAppShellConstructor in an adaptor that
passes in the extra null argument to nsAppShellConstructor.
Differential Revision: https://phabricator.services.mozilla.com/D146456
nsIFactory is binary compatible with Windows COM's IClassFactory,
but nothing seems to depend on it. This patch removes the test
for compatibility, TestCOM, and removes the lockFactory
method that isn't otherwise needed.
Differential Revision: https://phabricator.services.mozilla.com/D146386
I'm going to assert that we no longer need to worry about someone running
something prior to mozilla 1.3 and so the easiest way to remove this compiler
warning is to just remove this check for the old-style locking entirely.
Differential Revision: https://phabricator.services.mozilla.com/D145321
The product experience migrating a profile when a non-MSIX Firefox is
running is not ideal, so we're going to always start with a fresh
profile for simplicity.
This is a straight backout of the "meat" of Bug 1709969 - Migrate from
an existing profile when running from an app package for the first
time, namely `hg backout -r 5136d2f684012dc3d586dcb10374f8c6eda8b6d7`.
The changes from follow-up Bug 1723298 (correcting test failures on
devedition), namely revision a4bca433c8f7003a90fda61248f38d9b389c394e,
were manually reverted and the test files deleted.
Differential Revision: https://phabricator.services.mozilla.com/D129066
We want to make our best effort to delete all files we can before we unlock the profile. This includes a retry loop hoping that whoever else locked those files did so intermittently.
And once the profile is unlocked, we want to reduce as much as possible the possibility to interfere with a starting instance on the same profile directory.
Until bug 1716291 lands, we need to get back here to finish the work, but this patch is already supposed to mitigate some of the problems we might see in the wild.
Differential Revision: https://phabricator.services.mozilla.com/D116834
Before this patch, when the profile is locked on Android, we would call "ps",
parse the human-readable output and kill any other Gecko process that we could
find.
But this is completely unnecessary, as we know exactly that the PID of the
process holding the lock is.
In this patch we just kill the process holding the lock since this is
equivalent to the previous behavior.
Differential Revision: https://phabricator.services.mozilla.com/D106186
Geoff Lankow
Nick Alexander
Tooru Fujisawa
Dave Townsend
Kris Maglione
Noemi Erli
criss
Marian-Vasile Laza
Barret Rennie
Andrew McCreight
Jan Rio Krause
Emilio Cobos Álvarez
Mike Kaply
Itiel
Stephen A Pohl
Katherine Patenio
Olivier Tilloy
Jonathan Watt
Sandor Molnar
Molly Howell
Jens Stutte
Brindusan Cristian
Butkovits Atila
Andreea Pavel
Dorel Luca
Tim Nguyen
Agi Sferro