gecko-dev/toolkit/xre/nsAppRunner.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

157 lines
4.3 KiB
C
Raw Normal View History

/* -*- Mode: C++; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
2012-05-21 11:12:37 +00:00
/* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
#ifndef nsAppRunner_h__
#define nsAppRunner_h__
#ifdef XP_WIN
# include <windows.h>
# include "mozilla/WindowsConsole.h"
#else
# include <limits.h>
#endif
#ifndef MAXPATHLEN
# ifdef PATH_MAX
# define MAXPATHLEN PATH_MAX
# elif defined(_MAX_PATH)
# define MAXPATHLEN _MAX_PATH
# elif defined(CCHMAXPATH)
# define MAXPATHLEN CCHMAXPATH
# else
# define MAXPATHLEN 1024
# endif
#endif
#include "nsStringFwd.h"
#include "nsXULAppAPI.h"
class nsINativeAppSupport;
class nsXREDirProvider;
class nsIToolkitProfileService;
class nsIFile;
class nsIProfileLock;
class nsIProfileUnlocker;
class nsIFactory;
extern nsXREDirProvider* gDirServiceProvider;
// NOTE: gAppData will be null in embedded contexts.
extern const mozilla::XREAppData* gAppData;
extern bool gSafeMode;
extern int gArgc;
extern char** gArgv;
Bug 307181 - Stage Firefox updates in the background after they're downloaded, and replace the application directory on restart; r=rstrong,bbondy When Firefox downloads an update, it previously kept the update around to apply it on the next restart. This patch changes this so that the updater program is launched in the background as soon as the update has finished downloading in order to stage the updated version of the application by copying the existing installation directory to a temporary location and applying the update on top of it, and replace the existing installation directory with the staged directory on the next restart. Because the replacing step is typically very fast, this patch eliminates the wait for the update to be applied on restart, making it unnecessary to show a progress dialog when restarting. --HG-- rename : toolkit/mozapps/update/test/chrome/test_0092_finishedBackground.xul => toolkit/mozapps/update/test/chrome/test_0093_stagedBackground.xul rename : toolkit/mozapps/update/test/unit/test_0110_general.js => toolkit/mozapps/update/test/unit/test_0113_general.js rename : toolkit/mozapps/update/test/unit/test_0111_general.js => toolkit/mozapps/update/test/unit/test_0114_general.js rename : toolkit/mozapps/update/test/unit/test_0112_general.js => toolkit/mozapps/update/test/unit/test_0115_general.js rename : toolkit/mozapps/update/test/unit/test_0170_fileLocked_xp_win_complete.js => toolkit/mozapps/update/test/unit/test_0172_fileLocked_xp_win_complete.js rename : toolkit/mozapps/update/test/unit/test_0171_fileLocked_xp_win_partial.js => toolkit/mozapps/update/test/unit/test_0173_fileLocked_xp_win_partial.js rename : toolkit/mozapps/update/test/unit/test_0110_general.js => toolkit/mozapps/update/test_svc/unit/test_0113_general_svc.js rename : toolkit/mozapps/update/test/unit/test_0111_general.js => toolkit/mozapps/update/test_svc/unit/test_0114_general_svc.js rename : toolkit/mozapps/update/test/unit/test_0112_general.js => toolkit/mozapps/update/test_svc/unit/test_0115_general_svc.js rename : toolkit/mozapps/update/test/unit/test_0170_fileLocked_xp_win_complete.js => toolkit/mozapps/update/test_svc/unit/test_0172_fileLocked_xp_win_complete_svc.js rename : toolkit/mozapps/update/test/unit/test_0171_fileLocked_xp_win_partial.js => toolkit/mozapps/update/test_svc/unit/test_0173_fileLocked_xp_win_partial_svc.js
2012-05-22 14:50:04 +00:00
extern int gRestartArgc;
extern char** gRestartArgv;
extern bool gRestartedByOS;
extern bool gLogConsoleErrors;
extern nsString gAbsoluteArgv0Path;
extern bool gIsGtest;
namespace mozilla {
nsresult AppInfoConstructor(nsISupports* aOuter, const nsID& aIID,
void** aResult);
} // namespace mozilla
Bug 1554029: Downgrade detection fails for changes from non-minor to minor versions. r=froydnj 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
2019-05-24 21:16:55 +00:00
// Exported for gtests.
void BuildCompatVersion(const char* aAppVersion, const char* aAppBuildID,
const char* aToolkitBuildID, nsACString& aBuf);
Bug 1556832: Comparing compatibility versions goes on to check the build IDs when the version is newer. r=froydnj 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
2019-06-04 17:44:16 +00:00
/**
* Compares the provided compatibility versions. Returns 0 if they match,
* < 0 if the new version is considered an upgrade from the old version and
* > 0 if the new version is considered a downgrade from the old version.
*/
int32_t CompareCompatVersions(const nsACString& aOldCompatVersion,
const nsACString& aNewCompatVersion);
Bug 1554029: Downgrade detection fails for changes from non-minor to minor versions. r=froydnj 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
2019-05-24 21:16:55 +00:00
/**
* Create the nativeappsupport implementation.
*
* @note XPCOMInit has not happened yet.
*/
nsresult NS_CreateNativeAppSupport(nsINativeAppSupport** aResult);
already_AddRefed<nsINativeAppSupport> NS_GetNativeAppSupport();
nsresult NS_NewToolkitProfileService(nsIToolkitProfileService** aResult);
nsresult NS_NewToolkitProfileFactory(nsIFactory** aResult);
/**
* Try to acquire exclusive access to the specified profile directory.
*
* @param aPath
* The profile directory to lock.
* @param aTempPath
* The corresponding profile temporary directory.
* @param aUnlocker
* A callback interface used to attempt to unlock a profile that
* appears to be locked.
* @param aResult
* The resulting profile lock object (or null if the profile could
* not be locked).
*
* @return NS_ERROR_FILE_ACCESS_DENIED to indicate that the profile
* directory cannot be unlocked.
*/
nsresult NS_LockProfilePath(nsIFile* aPath, nsIFile* aTempPath,
nsIProfileUnlocker** aUnlocker,
nsIProfileLock** aResult);
void WriteConsoleLog();
void OverrideDefaultLocaleIfNeeded();
/**
* Allow exit() calls to complete. This should be done from a proper Gecko
* shutdown path. Otherwise we aim to catch improper shutdowns.
*/
void MozExpectedExit();
#ifdef XP_WIN
BOOL WinLaunchChild(const wchar_t* exePath, int argc, char** argv,
HANDLE userToken = nullptr, HANDLE* hProcess = nullptr);
# define PREF_WIN_REGISTER_APPLICATION_RESTART \
"toolkit.winRegisterApplicationRestart"
# if defined(MOZ_LAUNCHER_PROCESS)
# define PREF_WIN_LAUNCHER_PROCESS_ENABLED "browser.launcherProcess.enabled"
# endif // defined(MOZ_LAUNCHER_PROCESS)
#endif
namespace mozilla {
namespace startup {
Result<nsCOMPtr<nsIFile>, nsresult> GetIncompleteStartupFile(nsIFile* aProfLD);
extern GeckoProcessType sChildProcessType;
} // namespace startup
const char* PlatformBuildID();
} // namespace mozilla
/**
* Set up platform specific error handling such as suppressing DLL load dialog
* and the JIT debugger on Windows, and install unix signal handlers.
*/
void SetupErrorHandling(const char* progname);
#ifdef MOZ_ASAN_REPORTER
extern "C" {
void MOZ_EXPORT __sanitizer_set_report_path(const char* path);
}
void setASanReporterPath(nsIFile* aDir);
#endif
#ifdef MOZ_WAYLAND
bool IsWaylandDisabled();
#endif
#endif // nsAppRunner_h__