||Find out how large the command line buffer should be.
||This file represents the only external interface exposed from libxul. It
is used by the various stub binaries (nsBrowserApp, xpcshell,
plugin-container) to initialize XPCOM and start their main loop.
||Check for a commandline flag. If the flag takes a parameter, the
parameter is returned in aParam. Flags may be in the form -arg or
--arg (or /arg on win32).
@param aArgc The argc value.
@param aArgv The original argv.
@param aArg the parameter to check. Must be lowercase.
@param aParam if non-null, the -arg <data> will be stored in this pointer.
This is *not* allocated, but rather a pointer to the argv data.
@param aFlags Flags @see CheckArgFlag
||This is a temporary file in order to conduct an experiment on the impact of
startup time on retention (see Bug 1640087).
This was generally adapted from LauncherRegistryInfo.h
||Event loop instrumentation. This code attempts to measure the
latency of the UI-thread event loop by firing native events at it from
a background thread, and measuring how long it takes for them
to be serviced. The measurement interval (kMeasureInterval, below)
is also used as the upper bound of acceptable response time.
When an event takes longer than that interval to be serviced,
a sample will be written to the log.
Set MOZ_INSTRUMENT_EVENT_LOOP=1 in the environment to enable
this instrumentation. Currently only the UI process is instrumented.
Set MOZ_INSTRUMENT_EVENT_LOOP_OUTPUT in the environment to a
file path to contain the log output, the default is to log to stdout.
Set MOZ_INSTRUMENT_EVENT_LOOP_THRESHOLD in the environment to an
integer number of milliseconds to change the threshold for reporting.
The default is 20 milliseconds. Unresponsive periods shorter than this
threshold will not be reported.
Set MOZ_INSTRUMENT_EVENT_LOOP_INTERVAL in the environment to an
integer number of milliseconds to change the maximum sampling frequency.
This variable controls how often events will be sent to the main
thread's event loop to sample responsiveness. The sampler will not
send events twice within LOOP_INTERVAL milliseconds.
The default is 10 milliseconds.
All logged output lines start with MOZ_EVENT_TRACE. All timestamps
output are milliseconds since the epoch (PRTime / 1000).
On startup, a line of the form:
MOZ_EVENT_TRACE start <timestamp>
will be output.
On shutdown, a line of the form:
MOZ_EVENT_TRACE stop <timestamp>
will be output.
When an event servicing time exceeds the threshold, a line of the form:
MOZ_EVENT_TRACE sample <timestamp> <duration>
will be output, where <duration> is the number of milliseconds that
it took for the event to be serviced. Duration may contain a fractional
||GLX 1.3 and later
||We use std::wstring here because this code must be usable within both the
launcher process and Gecko itself.
||Passing an aPid parameter to LaunchChildMac will wait for the launched
process to terminate. When the process terminates, aPid will be set to the
pid of the terminated process to confirm that it executed successfully.
||Returns true if the app is running from the read-only filesystem of a
mounted .dmg. Returns false if not, or if we fail to determine whether it
||Opens a dialog to ask the user whether the app should be installed to their
Applications folder. Returns true if the dialog is successfully opened and
the user accept, otherwise returns false.
||nameToken should be a string very briefly naming the lock you are creating
creating, and it should be unique except for across multiple instances of the
same application. The vendor name is included in the generated path, so it
doesn't need to be present in your supplied name. Try to keep this name sort
of short, ideally under about 64 characters, because creating the lock will
fail if the final path string (the token + the path hash + the vendor name)
is longer than the platform's maximum path and/or path component length.
installPath should be the path to the directory containing the application,
which will be used to form a path specific to that installation.
Returns MULTI_INSTANCE_LOCK_HANDLE_ERROR upon failure, or a handle which can
later be passed to the other functions declared here upon success.
||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.
GDK implements X11 error traps to ignore X11 errors.
Unfortunatelly We don't know which X11 events can be ignored
so we have to utilize the Gdk error handler to avoid
false alarms in Gtk3.
||Some components need to be run at the startup of mozilla or embedding - to
start new services etc.
This interface provides a generic way to start up arbitrary components
without requiring them to hack into main1() (or into NS_InitEmbedding) as
it's currently being done for services such as wallet, command line handlers
We will have a category called "app-startup" which components register
themselves in using the CategoryManager.
Components can also (optionally) add the word "service," as a prefix
to the "value" they pass in during a call to AddCategoryEntry() as
Presence of the "service" keyword indicates the components desire to
be started as a service. When the "service" keyword is not present
we just do a do_CreateInstance.
When mozilla starts (and when NS_InitEmbedding()) is invoked
we create an instance of the AppStartupNotifier component (which
implements nsIObserver) and invoke its Observe() method.
Observe() will enumerate the components registered into the
APPSTARTUP_CATEGORY and notify them that startup has begun
and release them.
This "pseudo" (in the XPCOM sense) interface provides for
platform-specific general application support
Due to the nature of the beast, this interface is not a full-blown
XPCOM component. The primary reason is that objects that implement
this interface generally must be operational *before* XPCOM (or any
of the rest of Mozilla) are initialized. As a result, this
interface is instantiated by somewhat unconventional means.
To create the implementor of this interface, you call the function
NS_CreateNativeAppSupport. This is done in the startup code
The interface provides these functions:
start - You call this to inform the native app support that the
application is starting. In addition, it serves as a
query as to whether the application should continue to
If the returned boolean result is PR_FALSE, then the
application should exit without further processing. In
such cases, the returned nsresult indicates whether the
reason to exit is due to an error or not.
Win32 Note: In the case of starting a second instance
of this executable, this function will return
PR_FALSE and nsresult==NS_OK. This means that
the command line arguments have been
successfully passed to the instance of the
application acting as a remote server.
quit - Informs the native app support that the application is stopping. The
app support should disable any functionality enabled by start.
onLastWindowClosing - Called when the last window is closed. Used as a
"soft" shutdown, passwords are flushed.
||A scriptable interface used on Windows only to do some work from
a special process that gets created with elevated privileges.
@status UNSTABLE - This interface is not frozen and will probably change in
||Only intended to be used from xpcshell tests. Allows setting the local
and normal profile data directories. Calling this after something using
them has started up will cause problems.
||This code attaches the process to the appropriate console.
||This file has *public* stuff needed for the Win32 implementation of
the nsINativeAppSupport interface. It has to be broken out into a
separate file in order to ensure that the generated .h file can be
used in a Win32 .rc file. See /mozilla/xpfe/bootstrap/splash.rc.
This file, and the generated .h, are only needed on Win32 platforms.
||This module is supposed to abstract signal handling away from the other
platforms that do not support it.
||x87 FPU Control Word:
0 -> IM Invalid Operation
1 -> DM Denormalized Operand
2 -> ZM Zero Divide
3 -> OM Overflow
4 -> UM Underflow
5 -> PM Precision
||Get the path to the installation directory. For Mac OS X this will be the
@param appDir the application directory file object
@param installDirPath the path to the installation directory
||This function processes any available updates. As part of that process, it
may exit the current process and relaunch it at a later time.
Two directories are passed to this function: greDir (where the actual
binary resides) and appDir (which contains application.ini for XULRunner
apps). If this is not a XULRunner app then appDir is identical to greDir.
The argc and argv passed to this function should be what is needed to
relaunch the current process.
The appVersion param passed to this function is the current application's
version and is used to determine if an update's version is older than the
current application version.
If you want the update to be processed without restarting, set the restart
parameter to false.
This function does not modify appDir.
||Convert UTF8 to UTF16 without using the normal XPCOM goop, which we
can't link to updater.exe.
||MingW currently does not implement a wide version of the
startup routines. Workaround is to implement something like
it ourselves. See bug 411826
||InstallX11ErrorHandler is not suitable for processes running with GTK3 as
GDK3 will replace the handler. This is still used for the plugin process,
which runs with GTK2.
||make sure you clone it, if you need to do stuff to it
||Copy a root profile to a backup folder before deleting it. Then delete the
local profile dir.