Also includes:
* feat: improve support for bootstrapped extensions
Added support for custom preference pages.
* fix: incorrect loading order for bootstrap loader
* fix: BootstrapLoader
(cherry picked from commit eb40811e464688c7d2fc58a4330272dde1ec7937)
To minimize the amount of new test logic, this commit adds lightweight
test helpers to head_unified_extensions.js, and inserts the relevant
checks in existing test files that exercise the code paths that trigger
the relevant cases.
Differential Revision: https://phabricator.services.mozilla.com/D249920
This adds the "Pin extension to toolbar" checkbox to the post-install
doorhanger, and ensures that the checkbox has a state that reflects the
actual placement of the button, including externally triggered changes.
Differential Revision: https://phabricator.services.mozilla.com/D250324
This adds the "Pin extension to toolbar" checkbox to the post-install
doorhanger, and ensures that the checkbox has a state that reflects the
actual placement of the button, including externally triggered changes.
Differential Revision: https://phabricator.services.mozilla.com/D250324
Unlike all previous conditions, the unhidden button cannot easily be
hidden, because the attention dot can currently not easily be dismissed.
To support users who prefer to ignore attention requests in favor of the
extension button being hidden more often, this behavior can be disabled
by setting the extensions.unifiedExtensions.button.ignore_attention
preference to true.
Differential Revision: https://phabricator.services.mozilla.com/D248166
Some doorhangers are anchored to the Extensions Button via
PopupNotifications.show() + gUnifiedExtensions.getPopupAnchorID().
The default behavior of PopupNotifications is to fall back to a
different anchor if the specified anchor is invisible. But if the
Extensions Button is hidden, we want to show it as needed, instead of
triggering the fallback.
This patch reveals the Extensions Button when PopupNotifications is
about to show the panel. This button will automatically be hidden
when the doorhanger is closed, as verified by the tests.
Differential Revision: https://phabricator.services.mozilla.com/D248163
This reverts commit ec5fa1d4c0.
Revert "Bug 1606785 - Format Firefox CSS files with Prettier r=desktop-theme-reviewers,perftest-reviewers,places-reviewers,translations-reviewers,omc-reviewers,backup-reviewers,browser-installer-reviewers,sparky,dao,pdahiya,nrishel,kpatenio"
This reverts commit baa5d72bbd.
Revert "Bug 1606785 - Format browser/themes and toolkit/themes CSS files with Prettier r=desktop-theme-reviewers,pip-reviewers,tabbrowser-reviewers,places-reviewers,dao,mconley"
This reverts commit 9604b0a8ae.
Revert "Bug 1606785 - Format browser/themes/preferences CSS files with Prettier r=settings-reviewers,desktop-theme-reviewers,dao,mconley"
This reverts commit 686c1cf85f.
Revert "Bug 1606785 - Format urlbar CSS files with Prettier r=urlbar-reviewers,desktop-theme-reviewers,dao"
This reverts commit a7a4f31251.
Revert "Bug 1606785 - Format webcompat CSS files with Prettier r=webcompat-reviewers,denschub"
This reverts commit 41bc4d5237.
Revert "Bug 1606785 - Format search CSS files with Prettier r=search-reviewers,jteow"
This reverts commit 7bb7f82374.
Revert "Bug 1606785 - Format dom CSS files with Prettier r=emilio"
This reverts commit c22e910235.
Revert "Bug 1606785 - Format android CSS files with Prettier r=geckoview-reviewers,hiro"
This reverts commit c08e43fc3d.
Revert "Bug 1606785 - Format layout CSS files with Prettier r=layout-reviewers,dholbert"
This reverts commit 4f2a32d1a4.
Revert "Bug 1606785 - Format devtools CSS files with Prettier r=devtools-reviewers,nchevobbe,frontend-codestyle-reviewers"
This reverts commit c05f675ddf.
Revert "Bug 1606785 - Format recomp CSS files with Prettier r=reusable-components-reviewers,desktop-theme-reviewers,dao,mkennedy"
This reverts commit b10c7de8d0.
Revert "Bug 1606785 - Format sidebar CSS files with Prettier r=sidebar-reviewers,desktop-theme-reviewers,dao,nsharpley"
This reverts commit d32c555e37.
Revert "Bug 1606785 - Format shopping CSS files with Prettier r=shopping-reviewers,desktop-theme-reviewers,dao,rking"
This reverts commit 965887a708.
Revert "Bug 1606785 - Format profiles CSS files with Prettier r=profiles-reviewers,desktop-theme-reviewers,dao,mossop"
This reverts commit 8338860f74.
Revert "Bug 1606785 - Format genai and ml CSS files with Prettier r=firefox-ai-ml-reviewers,Mardak"
This reverts commit d66681f553.
Revert "Bug 1606785 - Format firefoxview CSS files with Prettier r=fxview-reviewers,desktop-theme-reviewers,dao,jsudiaman"
This reverts commit 530b815cad.
Revert "Bug 1606785 - Format aboutlogins, megalist, and form autofill CSS files with Prettier r=credential-management-reviewers,mtigley,desktop-theme-reviewers,dao"
This reverts commit 813c864381.
This change is made for the following reasons:
- Similarity between new "Extensions" menu item, which shows up instead
of "Extensions and Themes" when the Extensions Button is hidden.
- Consistency with about:preferences, which shows "Extensions & Themes"
(this was introduced in bug 1483335 and was not touched when the menu
labels were renamed in bug 1698931).
- Consistency with mobile (bug 1885561)
This effectively reverts the rename of bug 1698931.
Differential Revision: https://phabricator.services.mozilla.com/D248162
By default, this patch does not change any behavior.
Only when the Extensions Button is hidden, then this replaces the
current generic "Add-ons and Themes" option with the "Extensions"
menu, which opens the Extensions Panel.
Differential Revision: https://phabricator.services.mozilla.com/D248161
Allow the user to unhide the hidden button via a context menu item on
the button, in case they do not know about the Customize Toolbar option.
The context menu can be used on the "hidden button" because there are
some situations where the button is temporarily unhidden.
Differential Revision: https://phabricator.services.mozilla.com/D248159
Bug 1948258 added a way to hide the Extensions Button, but not a way to
show it. This patch makes the following changes:
- always show the Extensions button in Customization mode, even if the
user wants to hide the button unconditionally.
- add menu item to toggle the visibility of the Extensions Button.
- the new menu item is not shown anywhere except on the Extensions
Button in Customization mode.
Differential Revision: https://phabricator.services.mozilla.com/D248158
This is the basis for the follow-up patches to unhide the button as
needed. In this patch specifically, the hidden button is shown when a
browserAction panel is opened, and hidden again when the panel closes.
This also includes test coverage for ensuring that the browserAction
panel is shown along with the button when needed.
Differential Revision: https://phabricator.services.mozilla.com/D248157
This pref will be used as the mechanism to store the users preference
for the desired visibility of the Extensions Button. This initial patch
hides the button based on the pref only, and follow-up patches will
adjust the conditions (show the button independently of the pref) and
add UI to toggle this pref.
Differential Revision: https://phabricator.services.mozilla.com/D248155
To ensure that a group ends up at the position specified by `index`,
this patch adjusts the index when the tab group moves to the right.
Before this patch, the tab group appeared at a too low (left) index
because the original logic did not account for tabs shifting after a
repositioning to the right.
This also introduces stricter validation for moving tabs near pinned
tabs or other tab groups. Previously, the tabbrowser internals adjusted
the index as needed to fit adjacent to pinned tabs or groups. Now, the
extension API throws an error.
The new behavior matches developer expectations and Chrome's behavior:
https://bugzilla.mozilla.org/show_bug.cgi?id=1963825#c9
Differential Revision: https://phabricator.services.mozilla.com/D249493
The `replaceGroupWithWindow` method currently adopts a tab group in
multiple steps, asynchronously. This can result in externally observable
inconsistencies past initial adoption (see bug).
To fix this, this patch changes the adoption logic by passing the tab
group as the initial item to adopt, and adopts the whole group at once
as needed. Now the logic is similar to drag and drop adoption as
implemented in bug 1908441.
Since tabToAdopt is no longer just a tab, but also a tab group (or even
a tab group label since bug 1908441), the logic in ext-browser.js needs
to be adjusted to make sure that it does not mistake non-tab elements
for tabs. Test coverage is in browser_ext_tabGroups_move_onMoved.js,
as not changing that caused the test to fail with:
> FAIL Tab did indeed move to the new window - {"oldWindowId":3,"oldPosition":"undefined"} deepEqual {"oldWindowId":3,"oldPosition":1} -
Differential Revision: https://phabricator.services.mozilla.com/D248537
Also add a new removeInfo option to the onRemoved event, with the
isWindowClosing property. This is comparable to the removeInfo parameter
in the tabs.onRemoved event, in case extensions want to special-case the
behavior.
Differential Revision: https://phabricator.services.mozilla.com/D249112
To allow extensions to correctly mirror the positions of tabs that were
bulk-moved by moving a tab group, emit the TabMove event in the reverse
order if the tab group moves forwards. This ensures that the previously
recorded index of a tab before the bulk-move remains valid.
Differential Revision: https://phabricator.services.mozilla.com/D248995
This patch adds a network.sniff.use_extension pref.
When false, the file extension of a URL will only be used to sniff file://
Differential Revision: https://phabricator.services.mozilla.com/D246585
This patch adds a network.sniff.use_extension pref.
When false, the file extension of a URL will only be used to sniff file://
Differential Revision: https://phabricator.services.mozilla.com/D246585
These became unneeded either when:
* We shipped the non-native theme (for newtab etc).
* We made unthemed buttons not show this inner ring.
Differential Revision: https://phabricator.services.mozilla.com/D248698
The tabGroups.onRemoved / onCreated / onMoved event depends on the
isAdoptingGroup / removedByAdoption flags to identify tab groups that are
adopted by another window. Although this flag is set for the
`gBrowser.adoptTabGroup` method, it is not in the
`gBrowser.replaceGroupWithWindow` method, which results in incorrect
events.
This patch fixes the issue by setting the isAdoptingGroup flag in
`gBrowser.replaceGroupWithWindow`.
Differential Revision: https://phabricator.services.mozilla.com/D248327
