At least in Win10, Firefox is not an option to configure as a mailto handler.
Differential Revision: https://phabricator.services.mozilla.com/D2247
--HG--
extra : moz-landing-system : lando
In an attempt to make the code that renames shortcuts during PostUpdate more
reliable, this patch switches to renaming the existing shortcut files instead
of deleting them and creating new ones, removes unused code dealing with icons,
and deduplicates the code by adding a new macro.
MozReview-Commit-ID: EnE2dGrunx2
--HG--
extra : source : 7173059b5ccfc60c86e1a1106b5c572e188d5fea
MozReview-Commit-ID: 64hU21BgELu
Some third-party software tampers with the registry settings for the
IAccessible COM interface which is provided by Windows. If these settings
become corrupted, our a11y implementation breaks. We attempt to detect this
by loading the path to the IAccessible typelib and checking to see if that file
still exists. If it is missing, we reset the typelib GUID and version to the
system default.
The GUIDs and version number included in this patch hold from Windows 7 through
to Windows 10 Anniversary Update. The Windows 10 Creators update does not use
a typelib anymore, so we do nothing in that case. This fix is intended to run
on 32-bit builds only.
--HG--
extra : rebase_source : 1e8948ec09c707e99182424f79f746419b490b24
This fixes a regression from bug 1324617. We were setting all our file and
protocol associations correctly, but failing to invoke SetAppAsDefaultAll,
meaning we act like the default browser (as in, links and files opened from
external applications go to us), but we don't detect ourselves as the default
browser, and the previous default browser still thinks it's the default.
This only applies to Windows 7 because later versions don't allow us to make
ourselves the default browser anyway.
MozReview-Commit-ID: 29iWvzicce9
--HG--
extra : rebase_source : 1ad06799f1d1447386ec6ce1a242552ccf748f1d
This is followup from bug 1324617, which added a new naming scheme for registry
keys related to the default browser settings, to allow more than one installation
to participate in those settings. That patch attempted to prevent creating the
new keys for an installation which already had the old ones, but didn't go far
enough with that attempt.
Also, clean up how we use the IconsVisible registry entry, specifically to
always set it on new installs even if we don't create shortcuts, because it no
longer seems to actually do anything except control the value of the Enable
Access checkbox in the Windows 7 version of Set Program Access and Defaults.
This was, I admit, mostly done to avoid having to fix a couple places where we
were updating the IconsVisible value.
MozReview-Commit-ID: 6VHU8FlBT0M
--HG--
extra : rebase_source : 4edbd508ae125b3b0f7c6d4b9ee6a6550f316cb7
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
