This is causing LSan leaks which don't have an easy fix, and we're
already not running it in debug builds, so it can't hurt too much.
MozReview-Commit-ID: I8nDnWIz9qr
Shipping smaller installers is a win, and we already do this on
Fennec. (The only files that get modified currently are .properties
files, which have their comment lines stripped.) We don't minify JS
files at the moment due to needing to have a larger conversation around
debuggability of JS, and because the setup for minifying needs more love
for non-Android platforms.
Just doing this, however, wins about 400k of on-disk space and ~100k
installer size, so it seems like a reasonable first step.
We occasionally get reports of UI unresponsiveness immediately following the
download phase of the stub installer. The longest operation that runs on the
main thread during this phase is validating the code signature of the full
installer. This patch moves that work (which is done in a native NSIS plugin)
to a separate thread. Hopefully this helps resolve the hangs.
I've also converted the build files for the plugin from Visual C++ 6 to 2017,
just to avoid the inconvenience of needing to pull up VC6 to build it.
MozReview-Commit-ID: CKje2a8M62i
I'm also adding a "StartMenuShortcut" option as an alias for "StartMenuShortcuts",
because I could not stop leaving off the 's' while testing this patch, so I
figure I'm not the only one making that mistake and getting frustrated.
MozReview-Commit-ID: Fdsc6CTBJr4
Aside from making things easier for JS callers, this also makes it harder to
accidentally trigger an early load of the service, which can be expensive
during startup.
This also makes a slight change to nsPluginHost to initially preserve the
previous blocklist state when a plugin is updated, to avoid the risk of the
possible additioanl asynchrony unblocking a plugin that should stay blocked.
MozReview-Commit-ID: 4EvIGJ1Ke0Z
"async" methods defined in scripts loaded via a <script> tag seem
to indirectly use the document's Promise, which is not usable after
the DOM of the document has been destroyed.
This is an issue if we invoke this code during the destroy of the
toolbox.
MozReview-Commit-ID: C8juQqJlVDN
Marionette is only built when ENABLE_MARIONETTE is defined, but
we unconditionally include its resources in Firefox' packaging
instructions. These resources ought to be guarded with the same
rule to actually make it possible to disable Marionette without
breaking the packaging.
We already do this on Fennec, see
mobile/android/installer/package-manifest.in:373.
MozReview-Commit-ID: 3s8e9sk6KGx
The uninstaller was being built as a side-effect of building `setup.exe`. In
Bug 1385227, that was moved from "somewhere" to part of the windows installer
packaging, which happens after the zip and mar are generated. Since the
installer we ship is actually repackaged from the zip[1], we stopped shipping
translated uninstallers.
This changes things around so that the uninstaller gets translated:
- Explicitly build the uninstaller as part of the L10n repack step.
- Use the same logic to build the installer locally as we do to create the ones
we ship.
[1] Except on Thunderbird
Differential Revision: https://phabricator.services.mozilla.com/D672
The uninstaller was being built as a side-effect of building `setup.exe`. In
Bug 1385227, that was moved from "somewhere" to part of the windows installer
packaging, which happens after the zip and mar are generated. Since the
installer we ship is actually repackaged from the zip[1], we stopped shipping
translated uninstallers.
This changes things around so that the uninstaller gets translated:
- Explicitly build the uninstaller as part of the L10n repack step.
- Use the same logic to build the installer locally as we do to create the ones
we ship.
[1] Except on Thunderbird
Differential Revision: https://phabricator.services.mozilla.com/D672
We will be moving existing generic preferences for devtools from libpref/init/all.js
to a new preferences file that will be devtools/preferences/devtools.js and that
will always be shipped. We rename the current devtools.js to devtools-client.js to
avoid conflicts when packaging the preference file to @RESPATH@/browser/@PREF_DIR@/devtools.js
MozReview-Commit-ID: INnqWGBoIAF
We will be moving existing generic preferences for devtools from libpref/init/all.js
to a new preferences file that will be devtools/preferences/devtools.js and that
will always be shipped. We rename the current devtools.js to devtools-client.js to
avoid conflicts when packaging the preference file to @RESPATH@/browser/@PREF_DIR@/devtools.js
MozReview-Commit-ID: INnqWGBoIAF
Now that XPT files are not loaded from files at runtime, code for
packaging XPT files can be removed.
This means that a couple of test XPIDL interfaces will get shipped in
builds to users that weren't before, but I don't think that matters
much.
This also puts XPT files into the local objdir for the XPIDL makefile,
instead of dist/bin, because they are no longer part of the
distribution.
MozReview-Commit-ID: 7gWj8KWUun3
Now that XPT files are not loaded from files at runtime, code for
packaging XPT files can be removed.
This means that a couple of test XPIDL interfaces will get shipped in
builds to users that weren't before, but I don't think that matters
much.
This also puts XPT files into the local objdir for the XPIDL makefile,
instead of dist/bin, because they are no longer part of the
distribution.
MozReview-Commit-ID: 7gWj8KWUun3
Currently, clicking the close button or otherwise trying to exit the Windows
stub installer always ends up canceling the installation. This patch prompts
the user to either continue or cancel the installation.
MozReview-Commit-ID: 4KMgCcyjTnv
