Fixes a regression from bug 1376597, which caused the stub installer to hang
forever and not respond to the close button if the browser was already running
during the installation.
MozReview-Commit-ID: A1XWGvnlgrS
There are a lot of hacks throughout the build system that just
enable us to make export in branding. Just so that we can then
copy the files from dist/branding into l10ngen.
Copy from the srcdir instead, so that we can remove those hacks
eventually.
MozReview-Commit-ID: DMoOrqZlhcn
Working on the main patch for this bug (part 1), it took me longer than seemed
reasonable to understand how the stub installer progress bar worked and to fit
the new stage into it. So I thought I would take the opportunity to attempt a
refactor and simplify the whole thing.
MozReview-Commit-ID: 9INP1Hgfiuq
There are a lot of hacks throughout the build system that just
enable us to make export in branding. Just so that we can then
copy the files from dist/branding into l10ngen.
Copy from the srcdir instead, so that we can remove those hacks
eventually.
MozReview-Commit-ID: DMoOrqZlhcn
To not merge the en-US language pack, the merge-% steps are in
a conditional function that disables that for en-US. Using a function
here as that's easier than a shell if in the merge rule, and
Makefile conditionals don't get evaluated late enough.
To liberate the l10n builds from settings in the automation,
we move the patch logic from LOCALE_MERGEDIR to REAL_LOCALE_MERGEDIR.
To determine strongly when we're in a repack or building a langpack,
the trick here is to
export IS_LANGUAGE_REPACK
in l10n.mk, and only set that to true in the entry-point rules.
Now, we can use that value in config.mk to define the l10n-specific
rules.
I did the same thing for langpack-%, which allows us to disable
the crashreporter files for language packs, for example.
With that,
make installers-de
just works, if you have localizations checked out.
For a while, we might run l10n-merge twice in automation, but it's really not
optional, so let's just make sure we run it.
MozReview-Commit-ID: 3nr33CKxkBQ
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
