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
