* For #14637 - Compatibility patch for AC - 8554
* Update Android Components version to 65.0.20201029143039
Co-authored-by: Arturo Mejia <arturomejiamarmol@gmail.com>
This is not the super fancy version yet - since we still need to restore into SessionManager and
haven't fully switched to BrowserStore yet. However AC having knowledge about "undo" and whether
it was performed or not, will help us with features like "recently closed tabs". And once we
can improve "undo", Fenix will get all the nice things automatically.
Requires:
https://github.com/mozilla-mobile/android-components/pull/8449
* Remove search fragment
* Use new folder to search dialog
* Rebase and lint
* Update tests with search dialog nav directions
* Rename interactor to match naming convention. Remove old controller and point everything to the dialog controller.
engineView.setDynamicToolbarMaxHeight(0) vs
engineView.setDynamicToolbarMaxHeight(toolbarHeight)
ensures webpage's bottom elements are aligned to the bottom of the browser.
We also need to make sure that when the toolbar is static it does not cover the
bottom of the page - something desired when the toolbar was dynamic.
For this the engineView will have a toolbarHeight bottom margin.
Three new settings and one for which this patch just pre-lands the strings.
The behavior for the "Swipe toolbar up to open tabs" is to be added as part of
a later ticket.
We looked into taking a screenshot right before leaving the
BrowserFragment, however this call will always fail since it's
non-blocking (we never want it to be blocking too), and we will never
receive a screenshot when a session is detached from an EngineView
before the callback is complete.
In Fenix, we can nicely evade this by taking a screenshot when click
the tabs tray icon, which is where you would want to see the most
up-to-date thumbnail of the tab and also does not leave the
BrowserFragment as well.
* Add PWA events to metrics.
Track events for add to homescreen and install.
Map PWA facts to events
* Map component facts to local metrics
Add events pings to fragments
Supress long method for events
Move install event to AC and collect facts
Retrieve fg and bg events from Facts. Do not track intent fg/bg events, only views
* Allow onPause in base fragment to send telemetry for PWA in the external app fragment. Track foreground and bg locally in fenix, and route install and home screen taps from AC facts
* Rebase
Changing the root view of BaseBrowserFragment from a CoordinatorLayout
to a SwipeGestureLayout has caused some regressions, particularly in
snackbar behavior. Lets prevent those regressions from occuring in
builds where the feature flag for gestures is off by only adding the
SwipeGestureLayout when the feature flag is on.
We need to pass a CoordinatorLayout instead of a SwipeGestureLayout to
FenixSnackbar.make() in BaseBrowserFragment to prevent UI tests from
breaking. We also need to remove a few view IDs from the tab preview.
* For #11056 - Removes unused argument when navigating to the collection creation fragment
* For #11056 - Moved the collection creation navigation logic to the TabTrayDialogFragment
* For #11056 - Moves navigating to the share screen from home/browser to the TabTrayDialogFragment
* For #11056 - We moved tab selection logic from home/browser to the tab tray dialog
* For #11056 - Moved new tab tapped logic to the tab tray dialog fragment
* For #11056 - Removes all interactor logic for the TabTrayDialogFragment
* For #11056 - Migrates the presentation / navigation around the TabTrayDialog to the androidx navigation library
- Renamed DownloadNotification and removed DownloadState.dismissed dependency
- Improved DynamicDownloadDialog behaviour when scrolling
- DynamicDownloadDialog remains attached to tab until dismissed
- Fixed onTryAgain not working for resumed DownloadDialogs
* For #9751 - Cleans up homeFragment directions
* For #9751 - Uses global actions for fragments not owned by homeFragment
* For #9751 - Cleans up SearchFragment directions
* For #9751 - Removes settings action from DeleteBrowsingDataFragment
* For #9751 - Removes browser action from SettingsFragment
* For #9751 - Adds ManagePhoneFeature global action
* For #9751 - Clean up unused deletebrowsingfragment actions
* For #9751 - Cleans Up HistoryFragment actions
* For #9751 - Removes Home -> Search action
* For #9751 - Removes the Bookmark -> Browser action
* For #9751 - Cleans up bookmark fragment actions
* For #9751 - Cleans up actions from ShareController
* For #9751 - Removes defaultBrowserFragment to browserFragment action
* For #9751 - Removes about -> browser action
* For #9751 - Adds global action to TrackingProtectionFragment
* For #9751 - Removes exception -> browser action
* For #9751 - Removes login -> browser action
* For #9751 - Fixes LoginFragment directions
* For #9751 - Removes ExternalAppBrowser directions
* for #9751 - Cleans up actions
* For #9751 - Fixes unit tests
* For #9751 - Addresses nits in PR
Make sure that we actually lazily initialize our storage layers.
With this patch applied, storage layers (history, logins, bookmarks) will be initialized when first
accessed. We will no longer block GeckoEngine init, for example, on waiting for the logins storage
to initialize (which needs to access the costly securePrefStorage).
Similarly, BackgroundServices init will no longer require initialized instances of the storage
components - references to their "lazy wrappers" will suffice.
In practice, this change changes when our storage layers are initialized in the following ways.
Currently, we will initialize everything on startup. This includes loading our megazord, as well.
With this change, init path depends on if the user is signed-into FxA or not.
If user is not an FxA user:
- on startup, none of the storage layers are initialized
- history storage will be initialized once, whenever:
- first non-customTab page is loaded (access to the HistoryDelegate)
- first interaction with the awesomebar
- history UI is accessed
- bookmarks storage will be initialized once, whenever:
- something is bookmarked, or we need to figure out if something's bookmarked
- bookmarks UI is accessed
- logins storage will be initialized once, whenever:
- first page is loaded with a login/password fields that can be autofilled
- (or some other interaction by GV with the autofill/loginStorage delegates)
- logins UI is accessed
- all of these storages will be initialized if the user logs into FxA and starts syncing data
- except, if a storage is not chosen to be synced, it will not be initialized
If user is an FxA user:
- on startup, none of the storage layers are initialized
- sometime shortly after startup is complete, when a sync worker runs in the background, all storage
layers that are enabled to sync will be initialized.
This change also means that we delay loading the megazord until first access (as described above).
The a-c side of this work is in https://github.com/mozilla-mobile/android-components/pull/6128
This switches Fenix to use `SyncableLoginsStorage`, which caches a connection internally
on first access, and doesn't expose any lock/unlock APIs at the public boundary.
- The "Add to Firefox Home" browser menu item adds a top site to the top site storage.
- Refactors the FenixSnackbar from BaseBrowserFragment into BrowserToolbarController
since there are multiple menu items that need to show a FenixSnackbar.
- Adds metrics for the new browser menu item.
ekager
Codrut Topliceanu
mcarare
Christian Sadilek
Andrew Gaul
Sebastian Kaspari
Elise Richards
Mugurell
ekager
Gabriel Luong
Tiger Oakes
Arturo Mejia
Jonathan Almeida
Kainalu Hagiwara
Roger Yang
Kate Glazko
Sawyer Blatz
codrut.topliceanu
Hakkı Kaan Çalışkan
Jeff Boek
David Walsh
Simon Chae
Mihai Eduard Badea
Michael
mcarare
Severin Rudie
Grisha Kruglov
Kate Glazko