This is pretty much impossible to review as-is, so it may be more useful to review the script that made them. The repo is at https://github.com/htwyford/create-theme-script. parse-themes-script.js is the main script. It reads input.json. input.json is pulled from https://github.com/FirefoxUX/themes/blob/main/tokens/color/base.json, with some light edits to fix inconsistencies. The file in the FirefoxUX repo is an export of the colors in the Figma file: https://www.figma.com/file/xaRff6432QsirRftX8NZgb/MR2-Themes?node-id=86%3A17747.
The themes aren't perfect yet. For example, the text color in the Urlbar chiclet is sometimes wrong. They also don't consider the UX spec on badge colors, since UX is still actively updating that part of the spec. Since these themes are behind a pref, I think we should land it and fix the issues in followups. It will make it more clear what is changing when they're not being added en masse like this. Getting them in the tree ASAP also lets UX and QA get a head start on testing them.
Differential Revision: https://phabricator.services.mozilla.com/D125755
This is pretty much impossible to review as-is, so it may be more useful to review the script that made them. The repo is at https://github.com/htwyford/create-theme-script. parse-themes-script.js is the main script. It reads input.json. input.json is pulled from https://github.com/FirefoxUX/themes/blob/main/tokens/color/base.json, with some light edits to fix inconsistencies. The file in the FirefoxUX repo is an export of the colors in the Figma file: https://www.figma.com/file/xaRff6432QsirRftX8NZgb/MR2-Themes?node-id=86%3A17747.
The themes aren't perfect yet. For example, the text color in the Urlbar chiclet is sometimes wrong. They also don't consider the UX spec on badge colors, since UX is still actively updating that part of the spec. Since these themes are behind a pref, I think we should land it and fix the issues in followups. It will make it more clear what is changing when they're not being added en masse like this. Getting them in the tree ASAP also lets UX and QA get a head start on testing them.
Differential Revision: https://phabricator.services.mozilla.com/D125755
Some addons may not include an icon (e.g. static themes addons) and so the abuse report panel should
fallback to the extensionGeneric.svg.
Falling back to the extensionGeneric.svg is also needed to prevent a diagnostic crash triggered by
loading non existing resources while running the abuse report mochitests.
Differential Revision: https://phabricator.services.mozilla.com/D122207
This patch removes the `extensions.webextPermissionPrompts` pref as well as
`permissionPromptsEnabled` prop on `mozAddonManager`.
While working on this patch, we noticed that some of the `browser_webapi.js`
weren't testing anything for a while now. That has been fixed. In addition,
the `test_blocklistchange.js` file has been updated to handle the permissions
prompt.
Differential Revision: https://phabricator.services.mozilla.com/D121114
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
This patch does change the color of the "Available Updates" category button badged count and the badge dot
added to the addon card options button when the addon has a pending update in the list of addons to
`var(--in-content-accent-color)` to make sure it does match the accent color used elsewhere in the same page.
It is particularly easy to notice the colors mismatch when the active theme is dark and there are pending
updates, e.g. see the screenshot attached in the bug comments here:
- https://bugzilla.mozilla.org/show_bug.cgi?id=1709655#c2
Depends on D114780
Differential Revision: https://phabricator.services.mozilla.com/D114781
This patch does prevent about:addons "Manage Extension Shortcuts" view to miss to catch
shortcut conflicts due to the special meaning of "Ctrl" on macOS systems, and its
implicit conversion into "Command":
- As the [documentation on MDN explicitly mention](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/commands#key_combinations):
> On Macs, "Ctrl" is interpreted as "Command", so if you actually need "Ctrl", specify "MacCtrl".
- and so ExtensionShortcuts.buildKeyFromShortcut calls ShortcutUtils.getModifiersAttribute ([1])
which convert both Ctrl and Command are into the same accel modifier, which is what ends into the key element
appended into the chrome window document.
- but we still have the original "Ctrl" as part of the shortcut string that
ExtensionShortcuts keeps into its map of the defined shortcuts loaded from
the extension manifests and from the one stored on disk (through ExtensionSettingsStore)
- when the about:addons "Manage Extension Shortcuts" view receive a new shortcut
from the user, it does convert the accelKey property from the dom event received
into "Command", and then it does check if the shortcut string exists in the
map of the existing shortcuts.
- when the extension using the same shortcut does use "Ctrl+..." in its commands
suggested shortcuts, shortcuts.js (the "Manage Extension Shortcuts" view implementation
script) wouldn't find the "Command+..." shortcut in the map of the existing shortcuts
and it would assume that it is not used and let the user to set a duplicate shortcut
without any of the warnings or errors expected.
The approach in this patch does abstract out the shortcutKeyMap used in
the about:addons shortcuts.js script into a specialized DefaultMap subclass,
which does internally does a "platform specific" normalization of the given
shortcutString to make sure that we don't miss duplicated shortcuts on macOS
due to the implicit convertion of the Ctrl modifier key.
[1]: https://searchfox.org/mozilla-central/rev/3aef835f6cb12e607154d56d68726767172571e4/toolkit/modules/ShortcutUtils.jsm#185-212
Differential Revision: https://phabricator.services.mozilla.com/D113698
This property does nothing since bug 315209 got implemented.
Every single user that I checked was doing the same math by hand, so
hooray for good defaults :-)
Differential Revision: https://phabricator.services.mozilla.com/D112253
- Added a new `taar_enabled` extra var to the `addonsManager.view` telemetry events
(determine if the taar based recommendation were enabled when the view was being loaded)
- Added a new `taar_based` extra var to the `addonsManager.install_stats` and to the
`addonsManager.action` "installFromRecommended" telemetry events
(determine if the addon installed was manually curated or recommended by the taar
system)
- Added a new test (browser_disco_taar_telemetry.js) to cover the values expected
for the new extra vars under the related scenarios
(taar recommendations enabled/disabled, installed taar recommended and manually
curated addons).
Differential Revision: https://phabricator.services.mozilla.com/D108840
* Actions menu icons can be too large (on Windows for instance)
* panel list font on Windows is inconsistent in add-ons manager and about:logins
* Fix RTL background-position for about:addons menu icons
Differential Revision: https://phabricator.services.mozilla.com/D111054
As part of removing all NPAPI plugin support, CTP is no longer relevant (it does not apply to GMP plugins) so we remove the option from about:addons.
Differential Revision: https://phabricator.services.mozilla.com/D107154
Removes the PluginProvider and NPAPI plugin blocklist handling as part of removing all NPAPI support. This allows us to remove nsIPluginHost.
Differential Revision: https://phabricator.services.mozilla.com/D107148
As part of removing all NPAPI plugin support, CTP is no longer relevant (it does not apply to GMP plugins) so we remove the option from about:addons.
Differential Revision: https://phabricator.services.mozilla.com/D107154
Removes the PluginProvider and NPAPI plugin blocklist handling as part of removing all NPAPI support. This allows us to remove nsIPluginHost.
Differential Revision: https://phabricator.services.mozilla.com/D107148
* Update green color used for success
* Fix actions menulist alignment
* Make various elements use new accent colors
* Fix lack of border on HTML checkboxes
* Update various colors to proton colors
* Update input border-radius to 4px
* Update border colors
Differential Revision: https://phabricator.services.mozilla.com/D110033
* Update green color used for success
* Fix actions menulist alignment
* Make various elements use new accent colors
* Fix lack of border on HTML checkboxes
* Update various colors to proton colors
* Update input border-radius to 2px
* Update border colors
Differential Revision: https://phabricator.services.mozilla.com/D110033