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.
MozReview-Commit-ID: Kp8x5o66nrY
I want AccessibleHandler.dll to use different UUIDs based on release channel.
The way I was doing it before wasn't working correctly because I also wanted
local builds to have their own set of UUIDs vs our regular Nightly/Beta/Release
builds.
I also want the beta channel to have its own set of UUIDs that are distinct
from release.
I'm using MOZ_UPDATE_CHANNEL to distinguish between the channels when
NIGHTLY_BUILD and BETA_OR_RELEASE are insufficient.
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
Bug 1324617 changed the name of the registry path that was being used to find
the new installation to launch, but forgot to update that function. This patch
switches to a more direct method of getting the right path to launch.
MozReview-Commit-ID: Hexhj9y4ixc
There are two parts to this patch:
1) The maintenance service installer now writes its uninstall registry keys to
the same registry view (either 32-bit or 64-bit) that it uses for all its other
registry keys. Previously it would always use the 32-bit view. Additionally,
if the 64-bit view is used, any existing entries in the 32-bit view are removed.
2) The Firefox uninstaller now looks in both views to find the path to the
maintenance service uninstaller. Previously it looked only in the native view.
This change was made in addition to #1 so that we have a fix for the bug that
will get delivered in an update, as opposed to requiring a reinstall.
MozReview-Commit-ID: Hu5AhopzO2x
The bug only mentions the shortcuts checkbox, but the ping checkbox label looks
precariously close to also being too long, so I handled it as well.
This patch only supports up to two lines of text, and only the shortcuts and
ping checkboxes can have multiple lines. Both of those limitations could be
lifted without too much trouble, but it doesn't seem necessary for now.
MozReview-Commit-ID: 9cm1scfrOY5
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
A new control allows the user to select 32 or 64-bit when the system supports both,
and it defaults to 64-bit when available. This means the stub installer is now
the same regardless of its build architecture; it was always a 32-bit executable
anyway, but now its actual behavior depends only on the running system, not the
target architecture of the application it was built alongside.
The options screen has been rearranged according to a design by Michael Verdi
so that the new control doesn't leave the UI so badly cluttered.
Also removed TmpVal, which wasn't used in the stub and so was generating warnings.
MozReview-Commit-ID: 5baJCkAa7bJ
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
