Also reduce the timeout for terminating the thread to 5 seconds, because 10
seconds is too long to be completely hanging the UI.
Differential Revision: https://phabricator.services.mozilla.com/D33844
--HG--
extra : moz-landing-system : lando
Make CityHash64, CityHash64WithSeed, and CityHash64WithSeeds usable from C code
Remove unnecessary includes from mar_read.c as well
Add DisableStlWrapping to mar tool's moz.build to fix linkage break when
building in Windows with MSVC
Differential Revision: https://phabricator.services.mozilla.com/D10774
We need to be able to send POST data that's encoded as UTF-8, but the older
version of nsJSON we currently have only support UTF-16.
--HG--
extra : source : 5d5494bb34e57e4ee1b51233bf9f6b86301f900c
Because of a silly logic error I made in bug 1494900, the optional command line
parameter support introduced there doesn't actually work at all; I reversed the
sense of the check for the NSIS stack being empty. This fixes that by just using
the check that the popstring function was already doing.
--HG--
extra : rebase_source : e63b70579810af5774e237c619b29fb71012ea8c
extra : source : 58a29f64dd06d4e66e6faf047e2356decc5904f4
Profile-per-install uses a hash of the install directory to identify different
installs of Firefox. This exposes the existing cityhash generated hash from
nsXREDirProvider and makes it available on all platforms.
Differential Revision: https://phabricator.services.mozilla.com/D3852
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : rebase_source : ec9a11268eed3c4f9e0783532b0e910289e809f9
This fixes a bug which the main bug 986081 patch exposes because it tries to
cancel a download in InetBgDl and then show a dialog box immediately afterward.
Without this patch, doing that very early on in the request (meaning before any
redirect is fully handled) would result in a 10 second UI hang.
MozReview-Commit-ID: 1zBxZrllFC
--HG--
extra : rebase_source : 523b2b37035a7fc6f435acd1f7437fbbbcf2adc6
Previously each new installation of any Firefox channel in any location would
just overwrite the Windows registry keys which register us as a candidate for
the default browser setting and for all of our potential file and protocol associations.
This meant that only the most recent installation (across all channels) was ever
selectable in those settings.
It also meant that creating a new installation when one was already present
tripped Windows 10's shenanigans alarm, because it saw the registration for an
existing application getting clobbered by a new one and couldn't tell that they
were really the same application.
The response to that alarm going off is to reset the default browser to Edge,
and maybe or maybe not generate a system notification about that. This is the
cause of bug 1324617. Obviously we would like to prevent that outcome.
So with this commit we generate new registration entries for each installation,
by adding a hash of the install path to the relevant identifiers.
MozReview-Commit-ID: Fz1xDtittMi
--HG--
extra : rebase_source : e0bc19e4abc1b32133f56458daf625527ce188b0
Previously each new installation of any Firefox channel in any location would
just overwrite the Windows registry keys which register us as a candidate for
the default browser setting and for all of our potential file and protocol associations.
This meant that only the most recent installation (across all channels) was ever
selectable in those settings.
It also meant that creating a new installation when one was already present
tripped Windows 10's shenanigans alarm, because it saw the registration for an
existing application getting clobbered by a new one and couldn't tell that they
were really the same application.
The response to that alarm going off is to reset the default browser to Edge,
and maybe or maybe not generate a system notification about that. This is the
cause of bug 1324617. Obviously we would like to prevent that outcome.
So with this commit we generate new registration entries for each installation,
by adding a hash of the install path to the relevant identifiers.
MozReview-Commit-ID: Fz1xDtittMi
--HG--
extra : rebase_source : 3b3523c108502aebd08fd4912c3ab50baf3c0359
