- Adds a urlbar button to toggle shopping sidebars and show sidebar state
- ShoppingSidebarParent.toggleAllSidebars() method to open and close sidebars
- Adds `browser.shopping.experience2023.active` pref to store the state of all sidebars
- Sidebars open and close based on state of the active pref
Differential Revision: https://phabricator.services.mozilla.com/D183394
This creates 3 icon states:
1. The translations offering with a single icon.
2. The loading icon with the spinner.
3. The live translation document, with the "translate to" locale listed.
Note that the locale text in the icon can grow to three letters in
theory, but in practice this does not happen with our currently
supported languages. I made sure the button can grow correctly if this
ever happens.
The tests are in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D178226
This code is untested since it's stubbing out functionality, which will
eventually use PageActions to open up a popup. The final code with the
popup will get tested, but for now rely on the existing test behavior,
without asserting new behavior.
Differential Revision: https://phabricator.services.mozilla.com/D173196
This code is untested since it's stubbing out functionality, which will
eventually use PageActions to open up a popup. The final code with the
popup will get tested, but for now rely on the existing test behavior,
without asserting new behavior.
Differential Revision: https://phabricator.services.mozilla.com/D173196
Done mostly automatically via find/replace following the conversions
specified here:
https://groups.google.com/a/mozilla.org/g/firefox-dev/c/9sGpF1TNbLk/m/QpU3oTUuAgAJ
For the most part I think the "flex: N N" usage could be simplified to
just "flex: N", but I wanted to preserve behavior (-moz-box-flex sets
both flex-grow and flex-shrink).
I changed legacy layout to also look at the order property rather than
-moz-box-ordinal-group because it made splitters and treecols easier (we
don't need to deal with both orders).
Differential Revision: https://phabricator.services.mozilla.com/D171715
Done mostly automatically via find/replace following the conversions
specified here:
https://groups.google.com/a/mozilla.org/g/firefox-dev/c/9sGpF1TNbLk/m/QpU3oTUuAgAJ
For the most part I think the "flex: N N" usage could be simplified to
just "flex: N", but I wanted to preserve behavior (-moz-box-flex sets
both flex-grow and flex-shrink).
I changed legacy layout to also look at the order property rather than
-moz-box-ordinal-group because it made splitters and treecols easier (we
don't need to deal with both orders).
Differential Revision: https://phabricator.services.mozilla.com/D171715
This adds probes and a limited set of tests for the following types of measurements:
1. A count for each time the All Tabs panel is opened, keyed on the entrypoint.
2. A count for each usage of the Tab Context Menu, keyed on the trigger node
as the entrypoint.
3. A count for each dragstart within the All Tabs panel.
Differential Revision: https://phabricator.services.mozilla.com/D168305
Make Places views constructors arguments more coherent, passing the root
and view elements up to the super class explicitly.
Remove the options argument, that was not strictly necessary, the same info can
be obtained directly.
Rename the "builder" attribute to "afterplacescontent" to clarify what it is
and make panel use it, instead of passing an insertionPoint option.
Additional cleanups:
Make chevron and BMB menus use coherent popupshowing observers.
Remove useless .viewElt accessor, .associatedElement can be used instead.
Avoid an access to the private _rootElt property from the controller.
Differential Revision: https://phabricator.services.mozilla.com/D164827
Only the bookmarks menu button is doing this peculiar re-using of
options.
I tried various fixes: keeping the inheritance but replacing only the
rootElt/viewElt (and using Object.assign to clone the options so modifications
don't 'transmit' to the ancestor menus) but it was messy and net code increase
for a pretty crufty UI surface. I also wasn't sure if that would end up
negatively influencing (now or in the future) e.g. menus shown from the main
bookmarks toolbar view (which would show up as a 'parent' view for the menus
we open from there), and thought that reusing the options was likely to cause
further confusion in future as well, should we add more, uh, options, to them.
So in the end I stuck with Keeping It Simple - I just repeat the one-off
repeating entry class. I'm not even sure how needed this is - in particular,
I wonder why we don't need it for other submenus for 'real' bookmark folders!
But I didn't investigate this too much. If you're sure that we can get rid of
some more of it, happy to do that in a followup.
Note that the addition of _init() was not ultimmately needed to fix this bug
(I think), but it brought the initialization sequence and when we set
`_placesView` more in line with what we did before and what I already did for
`PlacesToolbar`, so that seemed like a good thing to avoid further/other issues.
Differential Revision: https://phabricator.services.mozilla.com/D164756
Only the bookmarks menu button is doing this peculiar re-using of
options.
I tried various fixes: keeping the inheritance but replacing only the
rootElt/viewElt (and using Object.assign to clone the options so modifications
don't 'transmit' to the ancestor menus) but it was messy and net code increase
for a pretty crufty UI surface. I also wasn't sure if that would end up
negatively influencing (now or in the future) e.g. menus shown from the main
bookmarks toolbar view (which would show up as a 'parent' view for the menus
we open from there), and thought that reusing the options was likely to cause
further confusion in future as well, should we add more, uh, options, to them.
So in the end I stuck with Keeping It Simple - I just repeat the one-off
repeating entry class. I'm not even sure how needed this is - in particular,
I wonder why we don't need it for other submenus for 'real' bookmark folders!
But I didn't investigate this too much. If you're sure that we can get rid of
some more of it, happy to do that in a followup.
Note that the addition of _init() was not ultimmately needed to fix this bug
(I think), but it brought the initialization sequence and when we set
`_placesView` more in line with what we did before and what I already did for
`PlacesToolbar`, so that seemed like a good thing to avoid further/other issues.
Differential Revision: https://phabricator.services.mozilla.com/D164756
