This widget will be used for the profiler button. The profiler button is a
two-part widget with both a command and a view. The command starts/stops the
profiler, but the starting/stopping can also be performed from inside the view.
The dropmarker button shows the view.
When this widget is located in the panel, the start/stop action is only
accessible via the view and there is no "quick-action" command.
The structure of the widget is as follows:
toolbaritem.toolbaritem-combined-buttons
- toolbarbutton.toolbarbutton-1
- toolbarbutton.toolbarbutton-1.toolbarbutton-combined-buttons-dropmarker
The dropmarker icon is the toolbarbutton icon of the second toolbarbutton.
The dropmarker button is only shown in the toolbar or in the customize palette.
It is hidden when the widget is located in the panel.
In the toolbar, the hover effect of the dropmarker needs to have the same height
as the hover effect of the regular button. However, due to the different image
size (12x12 instead of 16x16) it requires more vertical padding.
Differential Revision: https://phabricator.services.mozilla.com/D98216
This adds the ability to force the bookmarks toolbar to appear on all pages. The checkbox in the toolbar context menu will reflect if the toolbar will appear outside of the newtab page. The toolbar will always appear on the newtab page. Profiles that already had the toolbar showing will have a migration to keep their experience unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D89222
This adds the ability to force the bookmarks toolbar to appear on all pages. The checkbox in the toolbar context menu will reflect if the toolbar will appear outside of the newtab page. The toolbar will always appear on the newtab page. Profiles that already had the toolbar showing will have a migration to keep their experience unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D89222
This adds the ability to force the bookmarks toolbar to appear on all pages. The checkbox in the toolbar context menu will reflect if the toolbar will appear outside of the newtab page. The toolbar will always appear on the newtab page. Profiles that already had the toolbar showing will have a migration to keep their experience unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D89222
This patch was generated with a script. It doesn't include all files:
- Files that use the preprocessor or fail to parse are skipped
- Files that are loaded as JSMs but don't use the .jsm extension are skipped (those will be renamed in Bug 1609269)
It was generated with the following command using d855222aa2/no-this-property-read.js:
```
hg revert --all &&
cp .gitignore .rgignore &&
rg --files-without-match -g '*.jsm' '^#endif|^#include|^#filter' | jscodeshift --stdin --transform ~/Code/jsm-rewrites/no-this-property-read.js --ignore-pattern ./mobile/android/modules/Sanitizer.jsm --ignore-pattern ./js/xpconnect/tests/unit/syntax_error.jsm &&
./mach eslint `hg st | rg '^M ' | sed 's/^M //'`
```
Differential Revision: https://phabricator.services.mozilla.com/D60187
The CustomizableUI does not delete the _addedEventListeners property from
the view node when the widget is destroyed. This stops the widget from
correctly having events dispatched to it after recreating it, as the
initialization code assumes that it has already been set up.
Differential Revision: https://phabricator.services.mozilla.com/D31677
All of the consumers of this observer really want it to behave like a promise.
And, for the cases where the DB may or may not already be loaded when those
callers run, getting the logic correct is difficult.
This patch replaces the observer with a promise, and also delays the
resolution of that promise until any built-in add-ons registered during
XPIProvider startup have finished installing. This latter feature is currently
unused, but will be necessary after subsequent patches for code that relies
querying the default theme immediately after provider startup.
This changes the policy to use the pref and permissions rather than a boolean flag. Using permissions gets us proper settings on startup without introducing any new overhead. Going this way flips our tests around so rather than testing an override to turn off private browsing support, we test overrides to enable private browsing support.
Differential Revision: https://phabricator.services.mozilla.com/D14482
