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
This patch wants to solve several quirks around the shutdown terminator.
- Use the same shutdown phase definitions in AppShutdown and nsTerminator. This touches quite a few files.
- Ensure that the terminator phase shift is handled before any shutdown observer notifications are sent and reduce its heartbeat duration.
- Add missing phases to the shutdown telemetry.
Please note that this changes the unit of "tick" to 100ms rather than 1s.
As a side effect, we also remove the obsolete "shutdown-persist" context.
While the existing test coverage continues to prove the most important functions, we acknowledge the wish for better test coverage with [[ https://bugzilla.mozilla.org/show_bug.cgi?id=1693966 | bug 1693966 ]].
Differential Revision: https://phabricator.services.mozilla.com/D103626
This patch wants to solve several quirks around the shutdown terminator.
- Use the same shutdown phase definitions in AppShutdown and nsTerminator. This touches quite a few files.
- Ensure that the terminator phase shift is handled before any shutdown observer notifications are sent and reduce its heartbeat duration.
- Add missing phases to the shutdown telemetry.
Please note that this changes the unit of "tick" to 100ms rather than 1s.
As a side effect, we also remove the obsolete "shutdown-persist" context.
While the existing test coverage continues to prove the most important functions, we acknowledge the wish for better test coverage with [[ https://bugzilla.mozilla.org/show_bug.cgi?id=1693966 | bug 1693966 ]].
Differential Revision: https://phabricator.services.mozilla.com/D103626
So this is an ugly solution, but it was the best I could come up with. We do
not want to show the skeleton UI if we're going to show the profile manager,
and we *will* show the profile manager if StartWithLastProfile=0 is under
[General] in profiles.ini. Accordingly the only ways to do the correct thing
here are to try to mirror edits that firefox makes to the profiles.ini file
to the registry, or to simply read the profiles.ini file ourselves. There are
many ways that profiles.ini could get out of sync with the registry if we
tried to mirror its state there, so going straight to the source of truth
seemed the best option.
There is one case which is still not covered here: if there is no profile for
our install marked as Default=1, then we will show the profile manager. This
should only be possible if the user manually edits their profiles.ini file,
however, and then it should resolve itself after one run, so I don't consider
it a significant enough problem to jump through all the hoops we would need
to jump through to solve it.
Depends on D98525
Differential Revision: https://phabricator.services.mozilla.com/D98936
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045