The goal is to make it easier for admins to have a generic way to
locate Firefox for uninstall, without needing to know the target
version to uninstall. The version in the `DisplayName` is extraneous:
it's in the `DisplayVersion` field, and users can see it when you
click on it in "Add/Remove Programs". Automated consumers may prefer
to read the `Comments` field of the Firefox uninstall data instead,
which remains identical to the `DisplayName` before this change.
Differential Revision: https://phabricator.services.mozilla.com/D116648
Apparently the icon we use for the category-extensions.svg and for extensionGeneric.svg is using a custom mapping
configured in mozapps.inc.mn
This was a bit confusing because I was initially changing the svg content but without having the result that
I was expecting.
With the mapping before this change, the sidebar icon for the extension category and the addon cards for
extension without an icon were both mapped to the same icon (which was the filled one before this patch,
and we would have changed both to the outline icon if we do change the icon content without changing the
mapping as well).
In this patch:
- category-discover.svg content is changed to match the new highlight-20.svg icon
- category-themes.svg content is changed to match the new themes-20.svg icon
- category-extensions.svg content is changed to mach the new extension-20.svg icon
- a new category-plugins.svg file is added and its content set to match the new plugin-20.svg icon
- extensionGeneric.svg and extensions.svg content stays the same as they are on mozilla-central before this change
but we do not map extensionGeneric.svg to category-extensions.svg anymore
It does seem also worth a mention that category-dictionaries.svg is still an svg icon with
viewBox and width/height set to 16, but it doesn't seem we do have yet a new 20x20 optimized icon
to replace this one.
Differential Revision: https://phabricator.services.mozilla.com/D114884
Replace the basic extension.svg icon with an hollow version.
Use this new hollow icon also for omnibox entries in the urlbar.
Use the filled version in extensionControlled, but note this is currently
unused due to some other generic icon overriding it.
Differential Revision: https://phabricator.services.mozilla.com/D113804
This is the first of two patches in this series that removes a large amount of now dead code from dom/plugins as part of removing all NPAPI plugin support. This patch removes re-entrancy guards we have for Windows OnPaint messages, as the guards were only needed for windowed plugins.
Differential Revision: https://phabricator.services.mozilla.com/D107144
Removes the mac plugin_interposer (and the related NSCursorInfo behavior), as part of removing all of NPAPI plugin support, since it has no other clients.
Differential Revision: https://phabricator.services.mozilla.com/D107142
This is the first of two patches in this series that removes a large amount of now dead code from dom/plugins as part of removing all NPAPI plugin support. This patch removes re-entrancy guards we have for Windows OnPaint messages, as the guards were only needed for windowed plugins.
Differential Revision: https://phabricator.services.mozilla.com/D107144
Removes the mac plugin_interposer (and the related NSCursorInfo behavior), as part of removing all of NPAPI plugin support, since it has no other clients.
Differential Revision: https://phabricator.services.mozilla.com/D107142
FILE_FLAG_DELETE_ON_CLOSE had the wrong semantics, rendering the lock
file unusable after it had been closed once.
Delete the lock file in the uninstaller as a simple alternative (given that
the lock file is not in a temporary location on Windows).
For a test I returned to the older form of
test_backgroundtask_update_sync_manager which initially exposed the issue:
It expects the background task to be able to detect the xpcshell instance
after running resetLock, which failed before this fix.
I also extended the original updateSyncManager test to run the second
copy twice, which also catches the issue.
Differential Revision: https://phabricator.services.mozilla.com/D109565
For all channels, this commit:
1. stops registering the ftp protocol handler at install time;
2. actively unregisters the ftp protocol handler at postupdate time;
3. stops unregistering the ftp protocol handler at uninstall time.
The rationale for 3) is that by the time a `helper.exe` with this
change is in place, the `postupdate` step has already run and
unregistered the ftp protocol handler.
Differential Revision: https://phabricator.services.mozilla.com/D104735
* Puts the docs in order, so that contributors aren't jumping to the
middle of the page to install system tools, then back to the top to
clone Firefox.
* Removes docs on MacPorts since it's being removed in bug 1688263.
* Removes step to manually install brew packages since that happens
automatically in bootstrap now.
* Simplifies mercurial installation docs
* Removes unnecessary mozconfig-tweaking instructions
* Removes almost-always-unnecessary DEFINE and troubleshooting
information.
Differential Revision: https://phabricator.services.mozilla.com/D102974
There are some complications here to handle unpackaged and packaged
builds. In addition, there could be a difference between App prefs
and GRE prefs. Since the underlying backgroundtasks code is built as
part of Gecko (i.e., `toolkit/...` rather than `browser/...`) I have
favoured GRE prefs. I think, however, that what is written will work
for App-specific prefs, but I'm not concerned with that detail at this
time.
This also add tests for backgroundtask-specific prefs, which are
structured as both xpcshell and mochitest-chrome tests because
locally, the former tests unpackaged builds and the latter can
accommodate testing packaged builds. We could use mochitest-chrome
for both, but this has been pleasant to work with locally.
Differential Revision: https://phabricator.services.mozilla.com/D97510
There are some complications here to handle unpackaged and packaged
builds. In addition, there could be a difference between App prefs
and GRE prefs. Since the underlying backgroundtasks code is built as
part of Gecko (i.e., `toolkit/...` rather than `browser/...`) I have
favoured GRE prefs. I think, however, that what is written will work
for App-specific prefs, but I'm not concerned with that detail at this
time.
This also add tests for backgroundtask-specific prefs, which are
structured as both xpcshell and mochitest-chrome tests because
locally, the former tests unpackaged builds and the latter can
accommodate testing packaged builds. We could use mochitest-chrome
for both, but this has been pleasant to work with locally.
Differential Revision: https://phabricator.services.mozilla.com/D97510
There are some complications here to handle unpackaged and packaged
builds. In addition, there could be a difference between App prefs
and GRE prefs. Since the underlying backgroundtasks code is built as
part of Gecko (i.e., `toolkit/...` rather than `browser/...`) I have
favoured GRE prefs. I think, however, that what is written will work
for App-specific prefs, but I'm not concerned with that detail at this
time.
This also add tests for backgroundtask-specific prefs, which are
structured as both xpcshell and mochitest-chrome tests because
locally, the former tests unpackaged builds and the latter can
accommodate testing packaged builds. We could use mochitest-chrome
for both, but this has been pleasant to work with locally.
Differential Revision: https://phabricator.services.mozilla.com/D97510
I'm keeping the --enable-update-agent config option and the corresponding
MOZ_UPDATE_AGENT config flag and define, as these should still be useful.
As we never shipped this there is no need to keep anything around to
clean up the scheduled tasks.
Differential Revision: https://phabricator.services.mozilla.com/D99574
allowed-dupes.mn contains a list of remote settings dumps that are allowed to
be empty. url-classifier-skip-urls.json was missing from that list and its
latest version is empty, causing bustage.
Differential Revision: https://phabricator.services.mozilla.com/D98577
It's not 100% clear that this has any effect -- it might be that the
string is case insensitive -- but in any case let's keep our source
code uniform.
Differential Revision: https://phabricator.services.mozilla.com/D94774
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
The `clobber` targets are superseded by `mach clobber`, so we don't need them for any reason. The `clean` target is meant to get you to a post-`configure` state, but it doesn't really work, and if it's necessary for you to be in that state for some reason you can just clobber and re-`configure`, so it doesn't seem worth it to get it working again. Instead, delete all of them. Also delete `everything` which is not useful when `clobber` doesn't exist.
Differential Revision: https://phabricator.services.mozilla.com/D93514
The PostUpdate task must always be called as the unelevated user, even if we didn't use the service, in order to ensure that we register the WDBA. Additionally, the PostUpdate task should always be run synchronously so that the elevated and unelevated PostUpdate tasks are guaranteed to run in order. This is important since the elevated PostUpdate unregisters the task and the unelevated PostUpdate re-registers it.
Differential Revision: https://phabricator.services.mozilla.com/D87509
Since bug 1510494, when the maintenance service is used, we create update log
and status files inside the service directory and then move them into the
regular update directory when finished. However, the directory those temp
files are stored in did not get added to the uninstallers, so it doesn't
get removed as it should.
This patch has two parts. First, the Firefox uninstaller now removes any log
files created for the installation it's uninstalling (there is only one
directory and the files for different installation are differentiated by name).
Second, the maintenace service uninstaller, when it gets run by the uninstaller
for the last copy of Firefox on the system, removes the UpdateLogs directory
itself, provided it is empty, which is should be at that point since all
installations have been removed and have cleaned up their own files.
Differential Revision: https://phabricator.services.mozilla.com/D85074
Aside from making registration somewhat more efficient, this allows us to make
the services available on the new C++-implemented JS Services object, which
requires services to use the new static component registration system.
Differential Revision: https://phabricator.services.mozilla.com/D81418
Aside from making registration somewhat more efficient, this allows us to make
the services available on the new C++-implemented JS Services object, which
requires services to use the new static component registration system.
Differential Revision: https://phabricator.services.mozilla.com/D81418