This also updates the addon-jar.mn script to remove the static chrome / resource registrations,
as this is taken care of in resource-mapping.js, and causes interesting test failures in CI
when included (specifically, if the manifest is refreshed after resource-mapping has run).
Differential Revision: https://phabricator.services.mozilla.com/D241463
This change creates the installation directory layout DLLs to be used in the versioned install
directory project outlined in https://bugzilla.mozilla.org/show_bug.cgi?id=1891600
These DLLs are both named InstallationDirLayout.dll, and their only
functionality is to return whether the current client installation uses
a single install directory (the current way), or versioned install
directories.
Eventually, the updater or installer will choose the appropriate version of this
directory to be installed on the client machine. Until we have that
functionality, the "single layout" version of the library will be
installed in the bin directory of the installation, and the "versioned
layout" version will be installed in a subdirectory.
More details are in the index.rst document included in this change.
Differential Revision: https://phabricator.services.mozilla.com/D236065
Copy commands from taskcluster/docker/firefox-flatpak/runme.sh into a
standalone repackage command that can be pointed at a firefox build and
spit out a flatpak repository.
The browser/installer/linux/app/flatpak directory contains templates and
extra files that get injected into the flatpak build process.
Differential Revision: https://phabricator.services.mozilla.com/D238800
This implements the crash helper service used to move child process crash
report generation out of the main process and into its own process. This is
implemented as a separate executable that is launched on startup by the main
process on the desktop platforms and as a service hosted by a separate process
on Android.
One limitation of the current code is that the crash helper process needs to
be running before we can start setting exception handlers in child processes.
This limitation is due to how Breakpad exception handlers register themselves
with the crash generator and prevents us from lazily starting the helper (or
restarting it on Android).
IPC with the crash helper is implemented using Unix sockets on Linux and macOS
with the former using sequential packets and the latter using stream sockets.
On Windows we use named pipes. In all cases the choice of IPC was dictated both
by the requirement to eventually talk directly to child processes from within
the sandbox, and to external processes in case of Windows as the Windows
Error Reporting exception handler must be able to reach out to the helper from
within a restricted context. These particular requirements are not used yet but
will be as we move more logic out of the main process logic.
Differential Revision: https://phabricator.services.mozilla.com/D231083
This implements the crash helper service used to move child process crash
report generation out of the main process and into its own process. This is
implemented as a separate executable that is launched on startup by the main
process on the desktop platforms and as a service hosted by a separate process
on Android.
One limitation of the current code is that the crash helper process needs to
be running before we can start setting exception handlers in child processes.
This limitation is due to how Breakpad exception handlers register themselves
with the crash generator and prevents us from lazily starting the helper (or
restarting it on Android).
IPC with the crash helper is implemented using Unix sockets on Linux and macOS
with the former using sequential packets and the latter using stream sockets.
On Windows we use named pipes. In all cases the choice of IPC was dictated both
by the requirement to eventually talk directly to child processes from within
the sandbox, and to external processes in case of Windows as the Windows
Error Reporting exception handler must be able to reach out to the helper from
within a restricted context. These particular requirements are not used yet but
will be as we move more logic out of the main process logic.
Differential Revision: https://phabricator.services.mozilla.com/D231083
This implements the crash helper service used to move child process crash
report generation out of the main process and into its own process. This is
implemented as a separate executable that is launched on startup by the main
process on the desktop platforms and as a service hosted by a separate process
on Android.
One limitation of the current code is that the crash helper process needs to
be running before we can start setting exception handlers in child processes.
This limitation is due to how Breakpad exception handlers register themselves
with the crash generator and prevents us from lazily starting the helper (or
restarting it on Android).
IPC with the crash helper is implemented using Unix sockets on Linux and macOS
with the former using sequential packets and the latter using stream sockets.
On Windows we use named pipes. In all cases the choice of IPC was dictated both
by the requirement to eventually talk directly to child processes from within
the sandbox, and to external processes in case of Windows as the Windows
Error Reporting exception handler must be able to reach out to the helper from
within a restricted context. These particular requirements are not used yet but
will be as we move more logic out of the main process logic.
Differential Revision: https://phabricator.services.mozilla.com/D231083
This implements the crash helper service used to move child process crash
report generation out of the main process and into its own process. This is
implemented as a separate executable that is launched on startup by the main
process on the desktop platforms and as a service hosted by a separate process
on Android.
One limitation of the current code is that the crash helper process needs to
be running before we can start setting exception handlers in child processes.
This limitation is due to how Breakpad exception handlers register themselves
with the crash generator and prevents us from lazily starting the helper (or
restarting it on Android).
IPC with the crash helper is implemented using Unix sockets on Linux and macOS
with the former using sequential packets and the latter using stream sockets.
On Windows we use named pipes. In all cases the choice of IPC was dictated both
by the requirement to eventually talk directly to child processes from within
the sandbox, and to external processes in case of Windows as the Windows
Error Reporting exception handler must be able to reach out to the helper from
within a restricted context. These particular requirements are not used yet but
will be as we move more logic out of the main process logic.
Differential Revision: https://phabricator.services.mozilla.com/D231083
This implements the crash helper service used to move child process crash
report generation out of the main process and into its own process. This is
implemented as a separate executable that is launched on startup by the main
process on the desktop platforms and as a service hosted by a separate process
on Android.
One limitation of the current code is that the crash helper process needs to
be running before we can start setting exception handlers in child processes.
This limitation is due to how Breakpad exception handlers register themselves
with the crash generator and prevents us from lazily starting the helper (or
restarting it on Android).
IPC with the crash helper is implemented using Unix sockets on Linux and macOS
with the former using sequential packets and the latter using stream sockets.
On Windows we use named pipes. In all cases the choice of IPC was dictated both
by the requirement to eventually talk directly to child processes from within
the sandbox, and to external processes in case of Windows as the Windows
Error Reporting exception handler must be able to reach out to the helper from
within a restricted context. These particular requirements are not used yet but
will be as we move more logic out of the main process logic.
Differential Revision: https://phabricator.services.mozilla.com/D231083
This implements the crash helper service used to move child process crash
report generation out of the main process and into its own process. This is
implemented as a separate executable that is launched on startup by the main
process on the desktop platforms and as a service hosted by a separate process
on Android.
One limitation of the current code is that the crash helper process needs to
be running before we can start setting exception handlers in child processes.
This limitation is due to how Breakpad exception handlers register themselves
with the crash generator and prevents us from lazily starting the helper (or
restarting it on Android).
IPC with the crash helper is implemented using Unix sockets on Linux and macOS
with the former using sequential packets and the latter using stream sockets.
On Windows we use named pipes. In all cases the choice of IPC was dictated both
by the requirement to eventually talk directly to child processes from within
the sandbox, and to external processes in case of Windows as the Windows
Error Reporting exception handler must be able to reach out to the helper from
within a restricted context. These particular requirements are not used yet but
will be as we move more logic out of the main process logic.
Differential Revision: https://phabricator.services.mozilla.com/D231083
This patch is the first step towards shipping dxcompiler.dll and
dxil.dll (also referred to as DXC) on Windows for WebGPU.
With this patch DXC is disabled by default at build time and can be enabled
on x86_64 by adding `ac_add_options --enable-dxcompiler` in the mozconfig
file.
Followup work will include in no particular order:
- Enabling DXC by default.
- Enabling DXC for Windows on x86 and arm architectures.
- Using our own DXC builds instead of pulling the dlls from the Windows
SDK.
Differential Revision: https://phabricator.services.mozilla.com/D216293
Installer telemetry misses some cases where installation would be aborted, specifically:
The OS is too old (Windows <10)
The hardware is missing support for a required feature (SSE2)
There is insufficient space on the drive
The target location is not writable
Also, the default error reported by telemetry indicates that the user cancelled the download, regardless of the actual error.
This change addresses these issues.
This change also modifies the URL that the user is directed to, when
we determine that they are running on Windows 7 or 8. The old URL was
the System Requirements page. The new URL is:
https://support.mozilla.org/kb/firefox-users-windows-7-8-and-81-moving-extended-support
Differential Revision: https://phabricator.services.mozilla.com/D230471
