Adds `showAddonsInMenu` in WebExtensionBrowserMenuBuilder to allow the option of removing `Add-ons`
item even if another extensions are displayed
Add unit tests to test if 'Add-ons' item visibility is updated properly
A BrowserMenuCompoundButton setup with compound drawables and used in our
BrowserMenu configured with a DynamicWidthRecyclerVIew will return a width
smaller with the size + padding of the compound drawables.
By replacing the default `inherit` layout direction for the initial onMeasure
we ensure the menu will also count the bounds of the compound drawables.
ExpandableLayout uses adapter based indexes to identify children.
In dynamic menus with list items being hidden this could lead to invalid
calculations and even to exceptions for indexes bigger that the then current
children count in the list.
To reconcile this we'll calculate a valid lastVisibleItemIndexWhenCollapsed and
stickyItemIndex to be used before the operations in calculateCollapsedHeight().
Because the code is now clearly tightly coupled to RecyclerView this patch also
refactors a previous general ViewGroup type to RecyclerView and because of this
part of the previous tests needed some adjustments.
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
ExpandableLayout needs to iterate through all items until the one set as the
limit of the collapsible menu and accumulate the distance.
It adds the items height and margins but also erroneously the padding.
Stop counting the padding if height is counted. Height contains any vertical
padding set.
If the menu starts as collapsed and it has a sticky footer set the bottom item
until which the menu should be collapsed must be shown on top of the sticky
item's view.
As an edgecase, if the same item is the limit of the collapsed menu and also
the sticky footer that will be the last item shown in the collapsed menu but
will be shown with full height.
The most important new responsibilities are to update the view of the sticky
item.
BrowserMenu's background is only set on the parent's layout so the Adapter will
have to set that same background to the sticky item's view such that other
items scrolling underneath it will be totally obscured.
Because the menu's background can be set in multiple ways (by setting a value
for mozac_browser_menu_background / by passing a MenuStyle or like in Fenix
having a default theme for all "above" views) BrowserMenu will offer a new
backgroundColor property that as the single source of truth for this which can
then be used by the Adapter.
Most of the menu items should support this new property and allow AC clients to
configure the menus such that a specific menu item will not be scrolled
off-screen but rather anchored to the top/bottom of the menu following where
the menu is anchored.
Vertical LinearLayoutManager configured with StickyItemPlacement such that:
- if StickyItemPlacement.TOP the sticky item will not be scrolled upwards
off-screen
- if StickyItemPlacement.TOP the sticky item will not be scrolled downwards
off-screen
Refactored the code so that touches/scrolls are still swallowed while the
menu is expanding after which ExpandableLayout should let all MotionEvents
pass through to be handled by menu items children.
The `stackFromEnd` property is not initially set even though
`endOfMenuAlwaysVisible` might be true since when having a bottom expandable
menu, that should always be scrolled to the top.
And we know if we're in that situation only later, after menu is configured and
based on it it can be inferred if it should be collapsed or not.
Setting `stackFromEnd` only after this steps, even if the menu is not yet on
the screen seems to have no effect.
The only solution is to replace menu's layout manager with one that has this
`stackFromEnd` from the beginning.
Previously the width could've change while the menu was scrolled or the width
may have been too small / big for the entire list when a larger / narrower
would be initially off screen, waiting for a scroll to be laid out.
Most of the menu items should support this new property and allow AC clients to
configure the menus to show any one of them as the last one showing in a
collapsed menu.
To support using the new functionality browser menu should:
- intercept the menu layout before being used to create a new PopupWindow and
possibly wrap it in the ExpandableLayout.
- identify when the menu wants to be shown as collapsed/expanded. This will be
inferred based on the new `isCollapsingMenuLimit` API of BrowserMenuItem.
- offer a straightforward, reliable way to know as soon as possible if the
menu should be anchored to the top or to the bottom of the screen.
Most of the refactoring from this patch was needed for the last part.
Previously the PopupWindow was created with a menu and then we used different
methods to infer where to place the menu.
Now we needed to know this before creating the PopupWindow since as per the
UX specs the menu should be expandable only when it is anchored to the bottom.
This new layout is specifically designed for one particular purpose:
wrapping a bottom placed menu to allow it to:
- first being displayed as collapsed until a specific menu item index
- inform about touches in the empty space left by the collapsed view
- automatically expand when users swipes up it will expand.
Once expanded it will remain so.
This was the only viable solution for allowing bottom anchored PopupWindows
to be expanded and collapsed.
