gecko-dev/xpcom/build/nsXULAppAPI.h

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

502 строки
16 KiB
C
Исходник Обычный вид История

/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
2012-05-21 15:12:37 +04: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 _nsXULAppAPI_h__
#define _nsXULAppAPI_h__
#include "js/TypeDecls.h"
#include "mozilla/ArrayUtils.h"
#include "mozilla/TimeStamp.h"
#include "nscore.h"
#include "xrecore.h"
Bug 1343075 - Use GeckoEditableSupport from PuppetWidget; r=masayuki r=rbarker r=snorp r=esawin Bug 1343075 - 1a. Add TextEventDispatcherListener::GetIMEUpdatePreference; r=masayuki Add a GetIMEUpdatePreference method to TextEventDispatcherListener to optionally control which IME notifications are received by NotifyIME. This patch also makes nsBaseWidget forward its GetIMEUpdatePreference call to the widget's native TextEventDispatcherListener. Bug 1343075 - 1b. Implement GetIMEUpdatePreference for all TextEventDispatcherListener; r=masayuki This patch implements GetIMEUpdatePreference for all TextEventDispatcherListener implementations, by moving previous implementations of nsIWidget::GetIMEUpdatePreference. Bug 1343075 - 2. Allow setting a PuppetWidget's native TextEventDispatcherListener; r=masayuki In PuppetWidget, add getter and setter for the widget's native TextEventDispatcherListener. This allows overriding of PuppetWidget's default IME handling. For example, on Android, the PuppetWidget's native TextEventDispatcherListener will communicate directly with Java IME code in the main process. Bug 1343075 - 3. Add AIDL interface for main process; r=rbarker Add AIDL definition and implementation for an interface for the main process that child processes can access. Bug 1343075 - 4. Set Gecko thread JNIEnv for child process; r=snorp Add a JNIEnv* parameter to XRE_SetAndroidChildFds, which is used to set the Gecko thread JNIEnv for child processes. XRE_SetAndroidChildFds is the only Android-specific entry point for child processes, so I think it's the most logical place to initialize JNI. Bug 1343075 - 5. Support multiple remote GeckoEditableChild; r=esawin Support remote GeckoEditableChild instances that are created in the content processes and connect to the parent process GeckoEditableParent through binders. Support having multiple GeckoEditableChild instances in GeckoEditable by keeping track of which child is currently focused, and only allow calls to/from the focused child by using access tokens. Bug 1343075 - 6. Add method to get GeckoEditableParent instance; r=esawin Add IProcessManager.getEditableParent, which a content process can call to get the GeckoEditableParent instance that corresponds to a given content process tab, from the main process. Bug 1343075 - 7. Support GeckoEditableSupport in content processes; r=esawin Support creating and running GeckoEditableSupport attached to a PuppetWidget in content processes. Because we don't know PuppetWidget's lifetime as well as nsWindow's, when attached to PuppetWidget, we need to attach/detach our native object on focus/blur, respectively. Bug 1343075 - 8. Connect GeckoEditableSupport on PuppetWidget creation; r=esawin Listen to the "tab-child-created" notification and attach our content process GeckoEditableSupport to the new PuppetWidget. Bug 1343075 - 9. Update auto-generated bindings; r=me
2017-03-08 06:34:39 +03:00
#if defined(MOZ_WIDGET_ANDROID)
# include <jni.h>
#endif
class JSString;
class MessageLoop;
class nsIDirectoryServiceProvider;
class nsIFile;
class nsISupports;
struct JSContext;
struct XREChildData;
struct XREShellData;
namespace mozilla {
class XREAppData;
struct BootstrapConfig;
struct Module;
} // namespace mozilla
/**
* A directory service key which provides the platform-correct "application
* data" directory as follows, where $name and $vendor are as defined above and
* $vendor is optional:
*
* Windows:
* HOME = Documents and Settings\$USER\Application Data
* UAppData = $HOME[\$vendor]\$name
*
* Unix:
* HOME = ~
* UAppData = $HOME/.[$vendor/]$name
*
* Mac:
* HOME = ~
* UAppData = $HOME/Library/Application Support/$name
*
* Note that the "profile" member above will change the value of UAppData as
* follows:
*
* Windows:
* UAppData = $HOME\$profile
*
* Unix:
* UAppData = $HOME/.$profile
*
* Mac:
* UAppData = $HOME/Library/Application Support/$profile
*/
#define XRE_USER_APP_DATA_DIR "UAppData"
/**
* A directory service key which provides the executable file used to
* launch the current process. This is the same value returned by the
* XRE_GetBinaryPath function defined below.
*/
#define XRE_EXECUTABLE_FILE "XREExeF"
/**
* A directory service key which specifies the profile
* directory. Unlike the NS_APP_USER_PROFILE_50_DIR key, this key may
* be available when the profile hasn't been "started", or after is
* has been shut down. If the application is running without a
* profile, such as when showing the profile manager UI, this key will
* not be available. This key is provided by the XUL apprunner or by
* the aAppDirProvider object passed to XRE_InitEmbedding.
*/
#define NS_APP_PROFILE_DIR_STARTUP "ProfDS"
/**
* A directory service key which specifies the profile
* directory. Unlike the NS_APP_USER_PROFILE_LOCAL_50_DIR key, this key may
* be available when the profile hasn't been "started", or after is
* has been shut down. If the application is running without a
* profile, such as when showing the profile manager UI, this key will
* not be available. This key is provided by the XUL apprunner or by
* the aAppDirProvider object passed to XRE_InitEmbedding.
*/
#define NS_APP_PROFILE_LOCAL_DIR_STARTUP "ProfLDS"
/**
* A directory service key which specifies the system extension
* parent directory containing platform-specific extensions.
* This key may not be available on all platforms.
*/
#define XRE_SYS_LOCAL_EXTENSION_PARENT_DIR "XRESysLExtPD"
/**
* A directory service key which specifies the system extension
* parent directory containing platform-independent extensions.
* This key may not be available on all platforms.
* Additionally, the directory may be equal to that returned by
* XRE_SYS_LOCAL_EXTENSION_PARENT_DIR on some platforms.
*/
#define XRE_SYS_SHARE_EXTENSION_PARENT_DIR "XRESysSExtPD"
#if defined(XP_UNIX) || defined(XP_MACOSX)
/**
* Directory service keys for the system-wide and user-specific
* directories where native manifests used by the WebExtensions
* native messaging and managed storage features are found.
*/
# define XRE_SYS_NATIVE_MANIFESTS "XRESysNativeManifests"
# define XRE_USER_NATIVE_MANIFESTS "XREUserNativeManifests"
#endif
/**
* A directory service key which specifies the user system extension
* parent directory.
*/
#define XRE_USER_SYS_EXTENSION_DIR "XREUSysExt"
/**
* A directory service key which specifies a directory where temporary
* system extensions can be loaded from during development.
*/
#define XRE_USER_SYS_EXTENSION_DEV_DIR "XRESysExtDev"
/**
* A directory service key which specifies the distribution specific files for
* the application.
*/
#define XRE_APP_DISTRIBUTION_DIR "XREAppDist"
/**
* A directory service key which specifies the location for system add-ons.
*/
#define XRE_APP_FEATURES_DIR "XREAppFeat"
/**
* A directory service key which specifies the location for app dir add-ons.
* Should be a synonym for XCurProcD everywhere except in tests.
*/
#define XRE_ADDON_APP_DIR "XREAddonAppDir"
/**
* A directory service key which specifies the distribution specific files for
* the application unique for each user.
* It's located at /run/user/$UID/<product name>/
*/
#define XRE_USER_RUNTIME_DIR "XREUserRunTimeDir"
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 18:50:04 +04:00
/**
* A directory service key which provides the update directory. Callers should
* fall back to appDir.
* Windows: If vendor name exists:
Bug 1458314 - Move the update directory to an installation specific location r=rstrong This change applies to Windows only. Firefox will need to migrate the directory from the old location to the new location. This will be done only once by setting the pref `app.update.migrated.updateDir2.<install path hash>` to `true` once migration has completed. Note: The pref name app.update.migrated.updateDir has already been used, thus the '2' suffix. It can be found in ESR24. This also removes the old handling fallback for generating the update directory path. Since xulrunner is no longer supported, this should no longer be needed. If neither the vendor nor app name are defined, it falls back to the literal string "Mozilla". The code to generate the update directory path and the installation hash have been moved to the updatecommon library. This will allow those functions to be used in Firefox, the Mozilla Maintenance Service, the Mozilla Maintenance Service Installer, and TestAUSHelper. Additionally, the function that generates the update directory path now has extra functionality. It creates the update directory, sets the permissions on it and, optionally, recursively sets the permissions on everything within. This patch adds functionality that allows Firefox to set permissions on the new update directory on write failure. It attempts to set the permissions itself and, if that fails and the maintenance service is enabled, it calls into the maintenance service to try from there. If a write fails and the permissions cannot be fixed, the user is prompted to reinstall. Differential Revision: https://phabricator.services.mozilla.com/D4249 --HG-- rename : toolkit/mozapps/update/updater/win_dirent.cpp => toolkit/mozapps/update/common/win_dirent.cpp rename : toolkit/mozapps/update/tests/unit_aus_update/cleanupSuccessLogMove.js => toolkit/mozapps/update/tests/unit_aus_update/updateDirectoryMigrate.js extra : moz-landing-system : lando
2018-10-24 00:41:04 +03:00
* ProgramData\<vendor name>\updates\
* <hash of the path to XRE_EXECUTABLE_FILE's parent directory>
*
* If vendor name doesn't exist, but product name exists:
Bug 1458314 - Move the update directory to an installation specific location r=rstrong This change applies to Windows only. Firefox will need to migrate the directory from the old location to the new location. This will be done only once by setting the pref `app.update.migrated.updateDir2.<install path hash>` to `true` once migration has completed. Note: The pref name app.update.migrated.updateDir has already been used, thus the '2' suffix. It can be found in ESR24. This also removes the old handling fallback for generating the update directory path. Since xulrunner is no longer supported, this should no longer be needed. If neither the vendor nor app name are defined, it falls back to the literal string "Mozilla". The code to generate the update directory path and the installation hash have been moved to the updatecommon library. This will allow those functions to be used in Firefox, the Mozilla Maintenance Service, the Mozilla Maintenance Service Installer, and TestAUSHelper. Additionally, the function that generates the update directory path now has extra functionality. It creates the update directory, sets the permissions on it and, optionally, recursively sets the permissions on everything within. This patch adds functionality that allows Firefox to set permissions on the new update directory on write failure. It attempts to set the permissions itself and, if that fails and the maintenance service is enabled, it calls into the maintenance service to try from there. If a write fails and the permissions cannot be fixed, the user is prompted to reinstall. Differential Revision: https://phabricator.services.mozilla.com/D4249 --HG-- rename : toolkit/mozapps/update/updater/win_dirent.cpp => toolkit/mozapps/update/common/win_dirent.cpp rename : toolkit/mozapps/update/tests/unit_aus_update/cleanupSuccessLogMove.js => toolkit/mozapps/update/tests/unit_aus_update/updateDirectoryMigrate.js extra : moz-landing-system : lando
2018-10-24 00:41:04 +03:00
* ProgramData\<product name>\updates\
* <hash of the path to XRE_EXECUTABLE_FILE's parent directory>
*
* If neither vendor nor product name exists:
Bug 1458314 - Move the update directory to an installation specific location r=rstrong This change applies to Windows only. Firefox will need to migrate the directory from the old location to the new location. This will be done only once by setting the pref `app.update.migrated.updateDir2.<install path hash>` to `true` once migration has completed. Note: The pref name app.update.migrated.updateDir has already been used, thus the '2' suffix. It can be found in ESR24. This also removes the old handling fallback for generating the update directory path. Since xulrunner is no longer supported, this should no longer be needed. If neither the vendor nor app name are defined, it falls back to the literal string "Mozilla". The code to generate the update directory path and the installation hash have been moved to the updatecommon library. This will allow those functions to be used in Firefox, the Mozilla Maintenance Service, the Mozilla Maintenance Service Installer, and TestAUSHelper. Additionally, the function that generates the update directory path now has extra functionality. It creates the update directory, sets the permissions on it and, optionally, recursively sets the permissions on everything within. This patch adds functionality that allows Firefox to set permissions on the new update directory on write failure. It attempts to set the permissions itself and, if that fails and the maintenance service is enabled, it calls into the maintenance service to try from there. If a write fails and the permissions cannot be fixed, the user is prompted to reinstall. Differential Revision: https://phabricator.services.mozilla.com/D4249 --HG-- rename : toolkit/mozapps/update/updater/win_dirent.cpp => toolkit/mozapps/update/common/win_dirent.cpp rename : toolkit/mozapps/update/tests/unit_aus_update/cleanupSuccessLogMove.js => toolkit/mozapps/update/tests/unit_aus_update/updateDirectoryMigrate.js extra : moz-landing-system : lando
2018-10-24 00:41:04 +03:00
* ProgramData\Mozilla\updates
*
* Mac: ~/Library/Caches/Mozilla/updates/<absolute path to app dir>
*
* All others: Parent directory of XRE_EXECUTABLE_FILE.
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 18:50:04 +04:00
*/
#define XRE_UPDATE_ROOT_DIR "UpdRootD"
Bug 1458314 - Move the update directory to an installation specific location r=rstrong This change applies to Windows only. Firefox will need to migrate the directory from the old location to the new location. This will be done only once by setting the pref `app.update.migrated.updateDir2.<install path hash>` to `true` once migration has completed. Note: The pref name app.update.migrated.updateDir has already been used, thus the '2' suffix. It can be found in ESR24. This also removes the old handling fallback for generating the update directory path. Since xulrunner is no longer supported, this should no longer be needed. If neither the vendor nor app name are defined, it falls back to the literal string "Mozilla". The code to generate the update directory path and the installation hash have been moved to the updatecommon library. This will allow those functions to be used in Firefox, the Mozilla Maintenance Service, the Mozilla Maintenance Service Installer, and TestAUSHelper. Additionally, the function that generates the update directory path now has extra functionality. It creates the update directory, sets the permissions on it and, optionally, recursively sets the permissions on everything within. This patch adds functionality that allows Firefox to set permissions on the new update directory on write failure. It attempts to set the permissions itself and, if that fails and the maintenance service is enabled, it calls into the maintenance service to try from there. If a write fails and the permissions cannot be fixed, the user is prompted to reinstall. Differential Revision: https://phabricator.services.mozilla.com/D4249 --HG-- rename : toolkit/mozapps/update/updater/win_dirent.cpp => toolkit/mozapps/update/common/win_dirent.cpp rename : toolkit/mozapps/update/tests/unit_aus_update/cleanupSuccessLogMove.js => toolkit/mozapps/update/tests/unit_aus_update/updateDirectoryMigrate.js extra : moz-landing-system : lando
2018-10-24 00:41:04 +03:00
/**
* A directory service key which provides the *old* update directory. This
* path should only be used when data needs to be migrated from the old update
* directory.
* Windows: If vendor name exists:
* Documents and Settings\<User>\Local Settings\Application Data\
* <vendor name>\updates\
* <hash of the path to XRE_EXECUTABLE_FILE's parent directory>
*
* If vendor name doesn't exist, but product name exists:
* Documents and Settings\<User>\Local Settings\Application Data\
* <product name>\updates\
* <hash of the path to XRE_EXECUTABLE_FILE's parent directory>
*
* If neither vendor nor product name exists:
* Documents and Settings\<User>\Local Settings\Application Data\
* Mozilla\updates
*
* This path does not exist on other operating systems
*/
#define XRE_OLD_UPDATE_ROOT_DIR "OldUpdRootD"
/**
* Begin an XUL application. Does not return until the user exits the
* application.
*
* @param argc/argv Command-line parameters to pass to the application. On
* Windows, these should be in UTF8. On unix-like platforms
* these are in the "native" character set.
*
* @param aConfig Information about the application to be run.
*
* @return A native result code suitable for returning from main().
*
* @note If the binary is linked against the standalone XPCOM glue,
* XPCOMGlueStartup() should be called before this method.
*/
XRE_API(int, XRE_main,
(int argc, char* argv[], const mozilla::BootstrapConfig& aConfig))
/**
* Given a path relative to the current working directory (or an absolute
* path), return an appropriate nsIFile object.
*
* @note Pass UTF8 strings on Windows... native charset on other platforms.
*/
XRE_API(nsresult, XRE_GetFileFromPath, (const char* aPath, nsIFile** aResult))
/**
* Get the path of the running application binary and store it in aResult.
*/
XRE_API(nsresult, XRE_GetBinaryPath, (nsIFile * *aResult))
/**
* Get the static module built in to libxul.
*/
XRE_API(const mozilla::Module*, XRE_GetStaticModule, ())
/**
* Lock a profile directory using platform-specific semantics.
*
* @param aDirectory The profile directory to lock.
* @param aLockObject An opaque lock object. The directory will remain locked
* as long as the XPCOM reference is held.
*/
XRE_API(nsresult, XRE_LockProfileDirectory,
(nsIFile * aDirectory, nsISupports** aLockObject))
/**
* Initialize libXUL for embedding purposes.
*
* @param aLibXULDirectory The directory in which the libXUL shared library
* was found.
* @param aAppDirectory The directory in which the application components
* and resources can be found. This will map to
* the NS_OS_CURRENT_PROCESS_DIR directory service
* key.
* @param aAppDirProvider A directory provider for the application. This
* provider will be aggregated by a libxul provider
* which will provide the base required GRE keys.
*
* @note This function must be called from the "main" thread.
*
* @note At the present time, this function may only be called once in
* a given process. Use XRE_TermEmbedding to clean up and free
* resources allocated by XRE_InitEmbedding.
*/
XRE_API(nsresult, XRE_InitEmbedding2,
(nsIFile * aLibXULDirectory, nsIFile* aAppDirectory,
nsIDirectoryServiceProvider* aAppDirProvider))
/**
* Register static XPCOM component information.
* This method may be called at any time before or after XRE_main or
* XRE_InitEmbedding.
*/
XRE_API(nsresult, XRE_AddStaticComponent, (const mozilla::Module* aComponent))
/**
* Register XPCOM components found in an array of files/directories.
* This method may be called at any time before or after XRE_main or
* XRE_InitEmbedding.
*
* @param aFiles An array of files or directories.
* @param aFileCount the number of items in the aFiles array.
* @note appdir/components is registered automatically.
*
* NS_APP_LOCATION specifies a location to search for binary XPCOM
* components as well as component/chrome manifest files.
*
* NS_EXTENSION_LOCATION excludes binary XPCOM components but allows other
* manifest instructions.
*
* NS_SKIN_LOCATION specifies a location to search for chrome manifest files
* which are only allowed to register skin packages.
*/
enum NSLocationType {
NS_APP_LOCATION,
NS_EXTENSION_LOCATION,
NS_SKIN_LOCATION,
NS_BOOTSTRAPPED_LOCATION
};
XRE_API(nsresult, XRE_AddManifestLocation,
(NSLocationType aType, nsIFile* aLocation))
/**
* Register XPCOM components found in a JAR.
* This is similar to XRE_AddManifestLocation except the file specified
* must be a zip archive with a manifest named chrome.manifest
* This method may be called at any time before or after XRE_main or
* XRE_InitEmbedding.
*
* @param aFiles An array of files or directories.
* @param aFileCount the number of items in the aFiles array.
* @note appdir/components is registered automatically.
*
* NS_COMPONENT_LOCATION specifies a location to search for binary XPCOM
* components as well as component/chrome manifest files.
*
* NS_SKIN_LOCATION specifies a location to search for chrome manifest files
* which are only allowed to register skin packages.
*/
XRE_API(nsresult, XRE_AddJarManifestLocation,
(NSLocationType aType, nsIFile* aLocation))
/**
* Fire notifications to inform the toolkit about a new profile. This
* method should be called after XRE_InitEmbedding if the embedder
* wishes to run with a profile. Normally the embedder should call
* XRE_LockProfileDirectory to lock the directory before calling this
* method.
*
* @note There are two possibilities for selecting a profile:
*
* 1) Select the profile before calling XRE_InitEmbedding. The aAppDirProvider
* object passed to XRE_InitEmbedding should provide the
* NS_APP_USER_PROFILE_50_DIR key, and may also provide the following keys:
* - NS_APP_USER_PROFILE_LOCAL_50_DIR
* - NS_APP_PROFILE_DIR_STARTUP
* - NS_APP_PROFILE_LOCAL_DIR_STARTUP
* In this scenario XRE_NotifyProfile should be called immediately after
* XRE_InitEmbedding. Component registration information will be stored in
* the profile and JS components may be stored in the fastload cache.
*
* 2) Select a profile some time after calling XRE_InitEmbedding. In this case
* the embedder must install a directory service provider which provides
* NS_APP_USER_PROFILE_50_DIR and optionally
* NS_APP_USER_PROFILE_LOCAL_50_DIR. Component registration information
* will be stored in the application directory and JS components will not
* fastload.
*/
XRE_API(void, XRE_NotifyProfile, ())
/**
* Terminate embedding started with XRE_InitEmbedding or XRE_InitEmbedding2
*/
XRE_API(void, XRE_TermEmbedding, ())
/**
* Parse an INI file (application.ini or override.ini) into an existing
* nsXREAppData structure.
*
* @param aINIFile The INI file to parse
* @param aAppData The nsXREAppData structure to fill.
*/
XRE_API(nsresult, XRE_ParseAppData,
(nsIFile * aINIFile, mozilla::XREAppData& aAppData))
enum GeckoProcessType {
#define GECKO_PROCESS_TYPE(enum_name, string_name, xre_name, bin_type) \
GeckoProcessType_##enum_name,
#include "mozilla/GeckoProcessTypes.h"
#undef GECKO_PROCESS_TYPE
GeckoProcessType_End,
GeckoProcessType_Invalid = GeckoProcessType_End
};
static const char* const kGeckoProcessTypeString[] = {
#define GECKO_PROCESS_TYPE(enum_name, string_name, xre_name, bin_type) \
string_name,
#include "mozilla/GeckoProcessTypes.h"
#undef GECKO_PROCESS_TYPE
};
static_assert(MOZ_ARRAY_LENGTH(kGeckoProcessTypeString) == GeckoProcessType_End,
Bug 895322 - Part 1: Replace the usages of MOZ_STATIC_ASSERT with C++11 static_assert; r=Waldo This patch was mostly generated by running the following scripts on the codebase, with some manual changes made afterwards: # static_assert.sh #!/bin/bash # Command to convert an NSPR integer type to the equivalent standard integer type function convert() { echo "Converting $1 to $2..." find . ! -wholename "*nsprpub*" \ ! -wholename "*security/nss*" \ ! -wholename "*/.hg*" \ ! -wholename "obj-ff-dbg*" \ ! -name nsXPCOMCID.h \ ! -name prtypes.h \ -type f \ \( -iname "*.cpp" \ -o -iname "*.h" \ -o -iname "*.cc" \ -o -iname "*.mm" \) | \ xargs -n 1 `dirname $0`/assert_replacer.py #sed -i -e "s/\b$1\b/$2/g" } convert MOZ_STATIC_ASSERT static_assert hg rev --no-backup mfbt/Assertions.h \ media/webrtc/signaling/src/sipcc/core/includes/ccapi.h \ modules/libmar/src/mar_private.h \ modules/libmar/src/mar.h # assert_replacer.py #!/usr/bin/python import sys import re pattern = re.compile(r"\bMOZ_STATIC_ASSERT\b") def replaceInPlace(fname): print fname f = open(fname, "rw+") lines = f.readlines() for i in range(0, len(lines)): while True: index = re.search(pattern, lines[i]) if index != None: index = index.start() lines[i] = lines[i][0:index] + "static_assert" + lines[i][index+len("MOZ_STATIC_ASSERT"):] for j in range(i + 1, len(lines)): if lines[j].find(" ", index) == index: lines[j] = lines[j][0:index] + lines[j][index+4:] else: break else: break f.seek(0, 0) f.truncate() f.write("".join(lines)) f.close() argc = len(sys.argv) for i in range(1, argc): replaceInPlace(sys.argv[i]) --HG-- extra : rebase_source : 4b4a4047d82f2c205b9fad8d56dfc3f1afc0b045
2013-07-18 21:59:53 +04:00
"Array length mismatch");
XRE_API(const char*, XRE_GeckoProcessTypeToString,
(GeckoProcessType aProcessType))
XRE_API(const char*, XRE_ChildProcessTypeToAnnotation,
(GeckoProcessType aProcessType))
#if defined(MOZ_WIDGET_ANDROID)
struct XRE_AndroidChildFds {
int mPrefsFd;
int mPrefMapFd;
int mIpcFd;
int mCrashFd;
int mCrashAnnotationFd;
};
XRE_API(void, XRE_SetAndroidChildFds,
(JNIEnv * env, const XRE_AndroidChildFds& fds))
#endif // defined(MOZ_WIDGET_ANDROID)
XRE_API(void, XRE_SetProcessType, (const char* aProcessTypeString))
2009-06-30 23:21:25 +04:00
XRE_API(nsresult, XRE_InitChildProcess,
(int aArgc, char* aArgv[], const XREChildData* aChildData))
/**
* Return the GeckoProcessType of the current process.
*/
XRE_API(GeckoProcessType, XRE_GetProcessType, ())
2009-06-30 23:21:25 +04:00
/**
* Return the string representation of the GeckoProcessType of the current
* process.
*/
XRE_API(const char*, XRE_GetProcessTypeString, ())
/**
* Returns true when called in the e10s parent process. Does *NOT* return true
* when called in the main process if e10s is disabled.
*/
XRE_API(bool, XRE_IsE10sParentProcess, ())
/**
* Defines XRE_IsParentProcess, XRE_IsContentProcess, etc.
*
* XRE_IsParentProcess is unique in that it returns true when called in
* the e10s parent process or called in the main process when e10s is
* disabled.
*/
#define GECKO_PROCESS_TYPE(enum_name, string_name, xre_name, bin_type) \
XRE_API(bool, XRE_Is##xre_name##Process, ())
#include "mozilla/GeckoProcessTypes.h"
#undef GECKO_PROCESS_TYPE
XRE_API(bool, XRE_IsSocketProcess, ())
/**
* Returns true if the appshell should run its own native event loop. Returns
* false if we should rely solely on the Gecko event loop.
*/
XRE_API(bool, XRE_UseNativeEventProcessing, ())
2009-06-30 23:21:25 +04:00
typedef void (*MainFunction)(void* aData);
XRE_API(nsresult, XRE_InitParentProcess,
(int aArgc, char* aArgv[], MainFunction aMainFunction,
void* aMainFunctionExtraData))
XRE_API(int, XRE_RunIPDLTest, (int aArgc, char* aArgv[]))
XRE_API(nsresult, XRE_RunAppShell, ())
XRE_API(nsresult, XRE_InitCommandLine, (int aArgc, char* aArgv[]))
XRE_API(nsresult, XRE_DeinitCommandLine, ())
XRE_API(void, XRE_ShutdownChildProcess, ())
2009-08-29 03:16:19 +04:00
XRE_API(MessageLoop*, XRE_GetIOMessageLoop, ())
2009-08-29 03:16:19 +04:00
XRE_API(bool, XRE_SendTestShellCommand,
(JSContext * aCx, JSString* aCommand, JS::Value* aCallback))
XRE_API(bool, XRE_ShutdownTestShell, ())
2009-08-26 03:39:30 +04:00
XRE_API(void, XRE_InstallX11ErrorHandler, ())
XRE_API(void, XRE_TelemetryAccumulate, (int aID, uint32_t aSample))
XRE_API(void, XRE_StartupTimelineRecord, (int aEvent, mozilla::TimeStamp aWhen))
XRE_API(void, XRE_InitOmnijar, (nsIFile * aGreOmni, nsIFile* aAppOmni))
XRE_API(void, XRE_StopLateWriteChecks, (void))
XRE_API(void, XRE_EnableSameExecutableForContentProc, ())
namespace mozilla {
enum class BinPathType { Self, PluginContainer };
}
XRE_API(mozilla::BinPathType, XRE_GetChildProcBinPathType,
(GeckoProcessType aProcessType));
XRE_API(int, XRE_XPCShellMain,
(int argc, char** argv, char** envp, const XREShellData* aShellData))
#ifdef LIBFUZZER
Bug 1431090 - Prepare tools/fuzzing/ to be used with JS_STANDALONE. r=froydnj This patch adjusts tools/fuzzing/ in such a way that the relevant parts can be reused in the JS engine. Changes in detail include: * Various JS_STANDALONE checks to exclude parts that cannot be included in those builds. * Turn LibFuzzerRegistry and LibFuzzerRunner into generic FuzzerRegistry and FuzzerRunner classes and use them for AFL as well. Previously, AFL was piggy-backing on gtests which was kind of an ugly solution anyway (besides that it can't work in JS). Now more code like registry and harness is shared between the two and they follow almost the same call paths and entry points. AFL macros in FuzzingInterface have been rewritten accordingly. This also required name changes in various places. Furthermore, this unifies the way, the fuzzing target is selected, using the FUZZER environment variable rather than LIBFUZZER (using LIBFUZZER in browser builds will give you a deprecation warning because I know some people are using this already and need time to switch). Previously, AFL target had to be selected using GTEST_FILTER, so this is also much better now. * I had to split up FuzzingInterface* such that the STREAM parts are in a separate set of files FuzzingInterfaceStream* because they use nsStringStream which is not allowed to be included into the JS engine even in a full browser build (error: "Using XPCOM strings is limited to code linked into libxul."). I also had to pull FuzzingInterface.cpp (the RAW part only) into the header and make it static because otherwise, would have to make not only separate files but also separate libraries to statically link to the JS engine, which seemed overkill for a single small function. The streaming equivalent of the function is still in a cpp file. * LibFuzzerRegister functions are now unique by appending the module name to avoid redefinition errors. MozReview-Commit-ID: 44zWCdglnHr --HG-- extra : rebase_source : fe07c557032fd33257eb701190becfaf85ab79d0
2018-01-17 17:20:35 +03:00
# include "FuzzerRegistry.h"
XRE_API(void, XRE_LibFuzzerSetDriver, (LibFuzzerDriver))
#endif // LIBFUZZER
#ifdef MOZ_ENABLE_FORKSERVER
XRE_API(int, XRE_ForkServer, (int* aArgc, char*** aArgv))
#endif // MOZ_ENABLE_FORKSERVER
#endif // _nsXULAppAPI_h__