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
Also make sure the download phase time is initialized, so it will always be
correct in affected pings.
MozReview-Commit-ID: 3aLHbMiRUZl
--HG--
extra : rebase_source : 17c7f475a9fdfcc72b4d8c4d6b5d35a134aa584d
BrandFullName is now defined in the branding files
MozReview-Commit-ID: 5wmInT9xbrT
--HG--
extra : rebase_source : 97f85c75026a354cbd7f55a4ed9860abad56820b
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
--HG--
extra : rebase_source : 31d21a3e7c72af874acbebaa30f0f77fc61d555f
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
--HG--
extra : rebase_source : f8dfad1514956a2b8fbd32a10a7bc46445e4a3c8
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
--HG--
extra : rebase_source : 578d0b69482e3ac75eb02d34f5f44a5ba657b08f
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
--HG--
extra : rebase_source : 97ec7bd049e2d7079908cfb8442417854224b404
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
--HG--
extra : rebase_source : 0605a4adba018fa4b85d563cdafba80b0533bc91
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
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.
--HG--
extra : rebase_source : 8cb28a22a3cac16fb743a8fe81db5e120c1fdf6d
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
