PrefetchRegistryInfo is intended to be a temporary file in order to conduct
this experiment on startup times vs. retention.
Most of the implementation is similar to LauncherRegistryInfo.
If we startup and the registry is different than the preference,
we will want to use the preference for the purpose of this experiment.
Differential Revision: https://phabricator.services.mozilla.com/D76993
I originally had this as a few patches, but the work to fix test
failures and get the whole thing into a complete working state
quickly tangled them up. Apologies for that. To summarize what's
going on here, however:
- We introduce two prefs: shutdown.fastShutdownStage and
shutdown.lateWriteChecksStage. The latter pref is set to 1, which
will leave the existing late write checking behavior unchanged.
However, we introduce this pref to make it simpler in the future
to bump the late write checks window earlier in the shutdown cycle.
- We introduce an AppShutdown class, which will house static methods
and a small amount of state for unifying some shutdown logic. Most
importantly, it will now manage the state for app initiated restarts,
as well as the logic for performing a safe fast shutdown.
- We refactored the existing restart code to call into the new
AppShutdown file, so that if we are configured to actually perform
a fast shutdown, we will be able to run the necessary restart logic
immediately before doing so. Previously, the restart logic occurred
later in the shutdown cycle than our late write checking, meaning
if we were to simply exit the process at that point in time, we
would never run the restart coe.
- Lastly, we updated two locations which called TerminateProcess and/or
_exit(0) to call into the AppShutdown method (DoFastShutdown).
Differential Revision: https://phabricator.services.mozilla.com/D59196
--HG--
extra : moz-landing-system : lando
When comparing compatibility versions we first compare the version part. If that
shows us to be a downgrade then we stop checking at that point. But we must also
stop checking if it shows us to be an upgrade since we don't need to check the
build IDs at that point. This also applies to the check for the app build ID.
This means that a newer version with an older build id will appear to be a
downgrade.
This is problematic for safe mode because when safe mode runs it sets the
compatibility version to "Safe Mode" (bug 1556831) to ensure that caches are
invalidated on next startup. On the next run the Firefox version is considered
as newer than "Safe Mode" so we would move on to comparing the build IDs. But
the Firefox build ID gets version compared to "" (since there isn't a build ID
part in "Safe Mode"). Since build ID's are larger than 32-bit numbers we trigger
bug 1556829 and the actual comparison depends on the value of the build ID
truncated to 32-bits. This seems to often be negative and so lower than the
apparent previous build ID causing us to think this is a downgrade.
Cue nfroydnj saying I told you so because if I'd written this as a more
traditional compare function as he suggested I probably would have caught this.
Differential Revision: https://phabricator.services.mozilla.com/D33702
--HG--
extra : rebase_source : bb506c4ba4d75a68976bb114015d53cd41b4d4c3
We build compatibility versions as `<appversion>_<appbuildid>/<platformbuildid>`.
where the build ID's by default are a numeric representation of the date that
the build happened.
Previously we attempted to mangle this into a valid toolkit version by
converting to `<appversion>.<appbuildid>.<platformbuildid>` if the build IDs
were the expected length. We also split each build ID into two version parts
since the version comparator couldn't handle their full size.
This mangling fails when comparing a major version with a new patch version:
`<majorversion>.<appbuildid>.<platformbuildid>` gets compared to
`<majorversion>.1.<appbuildid>.<platformbuildid>`. Unless that patch version
(1 here) was greater than the build ID (currently in the tens of millions) the
patch release would appear to be older than the previous version.
This changes this so rather than attempting to mangle the entire string into a
single toolkit version we split out the string into their components.
First we compare the app versions using the version comparator which is
definitely the correct thing to do.
For the build IDs we check if they are entirely numeric (which is the case for
the date based default) and if so just compare them numerically.
We assume that if the IDs aren't numeric then they are something defined by a
custom build of Firefox, we can't know what form that takes so I've chosen to
fallback to just using the version comparator since it will handle things such
as `"build1" < "build10"` and it should be straightforward for anything more
complex to choose a form that works.
Differential Revision: https://phabricator.services.mozilla.com/D32552
--HG--
extra : rebase_source : 926d1f9f8cedad099b0d1813acf1342b50ed0217
Currently nsAppRunner is responsible for choosing or creating a profile to use
at startup. It then has to create a reset profile if necessary and lock the
selected profile directories. But these latter things are done in different
places of the selection code and done in different ways, sometimes we delay
while trying to get the lock, sometimes we don't.
This patch moves the profile selection part of the code to its own function so
that then we only have to have one place that does the profile reset and
locking logic.
It makes a lot of sense to have the selection code live in the profile service.
It can use information from the database load to help make the choices and it
also means that we can expose the profile selection code through xpcom allowing
it to be easily automatically tested. It will also be more important for future
patches for the dedicated profiles feature.
Differential Revision: https://phabricator.services.mozilla.com/D16116
--HG--
extra : moz-landing-system : lando
Since we know that corrupt startup caches can and do cause startup crashes, we
should ideally purge them any time we detect that the last startup resulted in
a crash. The alternative is waiting until the users restart enough times to
trigger safe mode, and hope that they start in safe mode and then immediately
restart in normal mode. This is not a great user experience.
Unfortunately, the normal startup crash detection mechanism relies on
the preference service, which starts up far too late for us to make this
decision effectively.
To work around that, this patch adds a new startup crash detection mechanism
that creates an incomplete startup canary file which we remove at the end of
the startup crash detection window, or on any sort of graceful exit.
MozReview-Commit-ID: ALaLsyF4meg
--HG--
extra : rebase_source : c97f8a2cac2c30f8cc22b05a62058aef2ad07870
For X11 only builds get display from DISPLAY env variable or from command line argument. For Wayland enabled buils use standard gdk_display_manager_open_display() path which respects GDK_BACKEND.
When command line argument --display is given pass it to child process by MOZ_GDK_DISPLAY env variable.
MozReview-Commit-ID: F9jEaJ9SU1p
--HG--
extra : rebase_source : 31cf96bcdfe5c525625aa3742aa74ec674265fe1
We should not be declaring forward declarations for nsString classes directly,
instead we should use nsStringFwd.h. This will make changing the underlying
types easier.
--HG--
extra : rebase_source : b2c7554e8632f078167ff2f609392e63a136c299
The next patch needs this value early in startup, before the service
manager is available.
MozReview-Commit-ID: LAfnzV2nfiR
--HG--
extra : rebase_source : 7230335461d06157d916b02fbe37f623fd233fae
Adds content sandbox metadata to parent and child crash reports:
Includes the value of pref security.sandbox.content.level,
whether or not the system is capable of sandboxing, if the
sandbox was successfully turned on, and (on Linux systems)
the sandbox capabilities flags.
New crash report keys:
"ContentSandboxLevel" in parent and content
"ContentSandboxCapable" in parent
"ContentSandboxEnabled" in content
"ContentSandboxCapabilities" in content on Linux
The behavior of ::BrowserTabsRemoteAutostart() shouldn't change, meaning that every result remains the same. The new getter can be accessed by JS through Services.appinfo.multiprocessBlockPolicy
MozReview-Commit-ID: 62PpbeJcMCI
The bulk of this commit was generated by running:
run-clang-tidy.py \
-checks='-*,llvm-namespace-comment' \
-header-filter=^/.../mozilla-central/.* \
-fix
Daosheng Mu
Gijs Kruitbosch
Emma Malysz
Doug Thayer
Dave Townsend
Martin Stransky
Masatoshi Kimura
Gurzau Raul
Kris Maglione
Csoregi Natalia
Ehsan Akhgari
Aaron Klotz
Coroiu Cristina
Sylvestre Ledru
Christian Holler
Adam Gashlin
Marco Bonardo
Blake Kaplan
Eric Rahm
Andrew McCreight
Benjamin Smedberg
Sebastian Hengst
Benoit Girard
Haik Aftandilian
Andrea Marchesini
Felipe Gomes
Arthur Edelstein
Nigel Babu
Robert Strong
Birunthan Mohanathas
Robert O'Callahan