This is not exhaustive technical documentation for every aspect of the installer
code, but it's better than what we had, and it does contain the ping
documentation that this bug was originally asking for.
MozReview-Commit-ID: 5h7UwnAk4Iq
--HG--
extra : rebase_source : a3a8a8bdee9e76ee039c342a07a121170872708c
BrandFullName is now defined in the branding files
MozReview-Commit-ID: 5wmInT9xbrT
--HG--
extra : histedit_source : 28df1fc3cafda4f9146af7d4f207263abac6f6ec
BrandFullName is now defined in the branding files
MozReview-Commit-ID: 5wmInT9xbrT
--HG--
extra : rebase_source : f22be9058c8ba4e9a7988e5df0130ac89f0116b3
extra : histedit_source : 292da497cb326e2cae83c0c3a618dc676e320c2e
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
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
--HG--
extra : rebase_source : 8937bb4c2182f609388e8f972d002fed35b9443a
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
--HG--
extra : rebase_source : 7bf784cc50f7a0235930f44a78335f73e295db48
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
--HG--
extra : rebase_source : b16cc6bd86cf15b74c7b71f3ab31043165deebd7
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
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
--HG--
extra : source : acfe81155ac21c2047cf64279960014c15e3c5c0
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
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
