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.
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
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
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
