There is a "unused" lint suppression in place with the comment
"Referenced from XML". I found no such usage.
It's documentation says that this Behavior will always position FindInPageBar
above BrowserToolbar but the current code ensures
BrowserToolbar.visibility == GONE when FindInPageBar.visibility == VISIBLE
so there's no need for such behavior.
We previously had a test exactly for checking that "start does nothing" but we
now need to ensure that start actually is propagated to the inner feature that
is to rebind itself to the app to allow for user interactions.
FindInPageFeature is used inside the app as a LifecycleAwareFeature and as such
it receives the onStart / onStop lifecycle calls.
The onStart() lifecycle call would not get passed to the feature but in
onStop() FindInPageFeature will detach it's Presenter and Interactor so when
the user comes back to the screen she could not interact anymore with the
feature.
To fix this we'll propagate LifecycleAwareFeature's onStart() to the inner
feature which is to rebind it's Presenter and Interactor in onStart().
This behavior is common to all the other features so all of them who implement
LifecycleAwareFeature will now get the onStart() call also.
* fixes#4193 - made close button for tabs more accessible.
set recommended minimum size for accessibility 48x48, while keeping image size the same
removed margin from button and text as it was not needed anymore
aligned close button in center of tab to be visual consistent with alignment of favicon and more visual accessible
* Fix margins
We currently do not use thumbnails anywhere in the app. Not using the feature means we are
not taking thumbnails on every page load which means we are saving memory and CPU cycles.
Navigation between app fragments uses ShareTab as arguments. The newly used
SendTabUseCases uses TabData which is not Parcelable.
For minimal changes we'll keep both data classes and ShareController will know
how to map between the two.
Removed the `sessionId` property of ShareTab as it isn't needed anymore.
Since we are now able to build against GeckoView Nightly and GeckoView Beta,
we should create the GeckoRuntime from a flavor-specific source set.
Creating the runtime is not covered by the AC abstraction and so API changes
in GeckoView Nightly can break the build and leaves us with no option to fix
it from a shared code base. Separating the creation of GeckoRuntime
allows us to adapt individually and also to configure the runtimes
differently.
`ShareController` defines a contract with all possible `ShareFragment`'s
behavior changes and comes with a default implementation -
`DefaultShareController`.
It is to be delegated by all `ShareFragment`s contained Views' Interactors
following any user interactions.
ShareFragment which acts as a container would contain all business logic needed
for populating it's Views.
Data initialization should be done only once since the app state has no reason
to change after the ShareFragment is created and is done as soon as possible,
in onAttach().
Because of the expected short lifespan of this fragment, given the fact that
the state has no reason to change and we handle orientation changes ourselves
to keep things simple I didn't use a ViewModel to persist the state.
In an effort to respect the initial MVI architecture I've broken the
complex `AppShareView` in 3 separate Views
- `ShareCloseView`
- `ShareToAccountDevicesView`
- `ShareToAppsView`
They are standalone Views (extending LayoutContainer) which know nothing about
each other or their parent and so offer their container the possibility to
order or display them in any form later.
According to the lib-state contract they are only responsible to
- inflate themselves in their injected containerView
- render a certain state (to be added in later commits)
- delegate all user interaction to an associated Interactor
As per #4341.
Also reformatted layouts to have a more consistent style.
Also refactored `AppShareRecyclerView` and `AccountDevicesShareRecyclerView` by
defining their LayoutManager in XML to reduce code complexity.
Removed drawableStart and added ImageView in layouts
Set ImageView logo programmatically: bitmap for SDK<24, vector for SDK>=24
Added onClickPendingIntent for ImageView in large and medium layouts
* Fixes#4067 besides snackbar
Makes layout hierarchy more shallow to increase performance.
* Fix#4067 Feedback
Make sure quick_action_overlay appears on top and use horizontal chain in tab_header.
* Remove "abi" product flavor and introduce "engine" product flavor.
This patch will allow us to build Fenix against GeckoView Nightly and GeckoView Beta by
introducing a new flavor dimension: engine = [geckoNightly, geckoBeta].
In addition to that it adds a "fenix" prefix to the nightly, beta and production flavors
to reduce the ambiguity between fenix beta/nightly and GeckoView beta/nightly.
For now the build types have the following engine variants enabled:
**debug**: geckoNightly, geckoBeta
Both variants enabled for local development and testing.
**forPerformanceTest**: geckoNightly, geckoBeta
Both variants enabled unless the perf team only cares about Nightly (tbd)
**fenixNightlyLegacy**: geckoBeta
Uses GeckoView Beta for now - the same version we ship production builds with (same behavior
as before). This release type will eventualyl be decommissioned once we switch to a separate
Nightly app on Google Play.
**fenixNightly**: geckoBeta
Uses GeckoView Beta for now - the same version we ship production builds with (same behavior
as before). Changing this build to use GeckoView Nightly is currently being discussed.
**fenixBeta**: geckoBeta
Fenix Beta uses GeckoView Beta.
**fenixProduction**
Fenix Production uses GeckoView Beta (69) currently.
* gradle.py/variant.py: Replace "abi" with "engine".
* Disable enableUnitTestBinaryResources until we can switch to Android Gradle plugin 3.5.
* Fenix nightly should use both geckoview nightly and beta
* Updates automation to use apk splitting and support different engine
The previous solution would result in a crash because the passed in
viewTreeObserver that would trigger onPreDraw would be invalid.
The proposed solution is simpler and ensures we'll always use the right
viewTreeObserver.
`FragmentPreDrawManager` is general enough that can be used by other Fragments
also, so I've added it to the `utils` package.
