When we allow the homescreen to handle undo for the last tab, we no
longer need to handle this ourselves with our own binding.
In the future, we should re-think this logic to be more robust and less
spread out across multiple screens.
The test failed with the rewrite of the code because it violates
one of our assumptions that only one Activity will be started. However,
since it doesn't rely on observed behavior and we made up the events,
it's value is questionable so it seems okay to remove, especially for
the gain of conciseness in the code.
* Remove signed in as string from sync menu item
* Nav to sync account settings on click
For https://github.com/mozilla-mobile/fenix/issues/18806: navigate to settings account page or sign in on clicking menu item.
* Confirm account exists and retrieve item title
* Remove string
Previously, to fix a memory leak, we were removing the adapter reference
entirely in order to have the `onDetachedFromRecyclerView` callback
invoked. This causes a side-effect where we can no longer reference the
adapter any more when we re-attach.
The simpler solution is to just invoke the needed callback directly
instead.
* For https://github.com/mozilla-mobile/fenix/issues/16900: implement async navgraph inflation
For https://github.com/mozilla-mobile/fenix/issues/16900: removed nav graph from xml
For https://github.com/mozilla-mobile/fenix/issues/16900: inflate navGraph programatically
For https://github.com/mozilla-mobile/fenix/issues/16900: Made NavGraph inflation asynchronous
For https://github.com/mozilla-mobile/fenix/issues/16900: Changed to block with runBlocking
For https://github.com/mozilla-mobile/fenix/issues/16900: Refactored blocking call into a function
For 16900: NavGraph inflation is now async
We now attach the nav graph (or check if its attached) on every nav call ( an extension function for NavController).
This is done by checking the value of the job stored in PerfNavController.map which keeps track of the job with the NavController as a Key.
If the job hasn't been completed, it will block the main thread until the job is done. The job itself is responsible for attaching the navgraph
to the navcontroller (and the inflation of the latter too)
For 16900: rebased upstream master
For 16900: Rebase on master
For https://github.com/mozilla-mobile/fenix/issues/16900: Fixed Async Navgraph navigation per review comments.
1)The Asynchronous method is now found in NavGraphProvider.kt. It creates a job on the IO dispatcher
2)The Job is tracked through a WeakHashMap from Controller --> NavGraph
3)The Coroutine scope doesn't use MainScope() anymore
4)The Coroutine is cancelled if the Activity is destroyed
5)The tests mockk the blockForNavGraphInflation method through the FenixReoboelectricTestApplication instead of calling the mock every setup()
For https://github.com/mozilla-mobile/fenix/issues/16900: inflateNavGraphAsync now takes navController
For https://github.com/mozilla-mobile/fenix/issues/16900: Pass lifecycleScope to NavGraphProvider
For https://github.com/mozilla-mobile/fenix/issues/16900: removed unused mock
For https://github.com/mozilla-mobile/fenix/issues/16900: Added linter rules for navigate calls
We need linting rules to make sure no one calls the NavController.navigate() methods
For https://github.com/mozilla-mobile/fenix/issues/16900: Added TestRule to help abstract the mocks in the code
For 16900: Fix linting problems
For https://github.com/mozilla-mobile/fenix/issues/16900: Cleaned duplicated code in tests
For https://github.com/mozilla-mobile/fenix/issues/16900: cleaned up NavGraphTestRule for finished test
For https://github.com/mozilla-mobile/fenix/issues/16900: had to revert an accidentally edited file
For https://github.com/mozilla-mobile/fenix/issues/16900: rebased master
* For https://github.com/mozilla-mobile/fenix/issues/16900: Review nits for async navgraph
This is composed of squash commits, the original messages can be found below:
-> DisableNavGraphProviderAssertionRule + kdoc.
Use test rule in RobolectricApplication.
Fix failing CrashReporterControllerTest
Fix blame by -> navigate in tests.
This commit was generated by the following commands only:
```
find app/src/test -type f -exec sed -i '' "/import org.mozilla.fenix.ext.navigateBlockingForAsyncNavGraph/d" {} \;
find app/src/test -type f -exec sed -i "" "s/navigateBlockingForAsyncNavGraph/navigate/g" {} \;
git checkout app/src/test/resources/mockito-extensions/org.mockito.plugins.MockMaker
```
Fix various blame
This is expected to be squashed into the first commit so, if so, it'd
fix the blame.
Move test rule to helpers pkg.
add missing license header
Add import change I missed
fix unused imports
Replace robolectricTestrunner with test rule.
Improve navGraphProvider docs
Remove unnecessary rule as defined by robolectric.
add clarifying comment to robolectric
remove unnecessary space
* For https://github.com/mozilla-mobile/fenix/issues/16900: nit fixes for MozillaNavigateCheck and lint fixes
3 squash commits:
*Changed violation message and fixed the lint rule for MozillaNavigateCheck
*Added suppression to NavController.kt
*Fixed detekt violations
* For 16900: Fixed failing tests
Co-authored-by: Michael Comella <michael.l.comella@gmail.com>
The StartupActivityStateProvider uses an imperative implementation,
driven by callbacks, to set the state of the application. This is hard
to follow as you need to understand which callbacks will be called in
which order. For example, to make sense of an implementation like this,
COLD, WARM, AND HOT would likely need to be implemented in separate
ActivityLifecycleCallbacks.
I feel the StartupStateProvider is an improvement because it leverages
the StartupActivityLog to query a linear state for a more understandable
implementation. Furthermore, it seems accessible to write COLD, WARM,
and HOT in the same class because they can all be approached the same
way.
We moved the collection dialog code out from the old fragment, because it
had nothing to do with tabs tray, and into the collections package to be
re-usable in other parts of the app.
In addition, we also make use of it in the new tabs tray's
NavigationInteractor.
With a dynamic bottom toolbar the browser extends all the way to the bottom of
the screen and so when the find in page bar is shown it will be so above the
bottom part of the browser which may contain exactly the searched for items.
To fix the browser must effectively be placed at the top of the newly shown
find in page bar.
FindInPageIntegration which already updated the toolbar to make room for the
find in page bar now receives more data based on which it will be able to
better update the layout of BrowserFragment to to support showing the find in
page bar.
Copied the TabsTouchHelper from the `tabtray` package here so we don't
need to re-write our own because there's nothing more to add.
We can hook this up with our tabs tray here by putting it in the
`BaseBrowserTrayList` for our normal and private tabs list.
Jonathan Almeida
mcarare
Mozilla L10n Automation Bot
Roger Yang
Michael Comella
codrut.topliceanu
Julien Cristau
Mugurell
Kate Glazko
Elise Richards
Christian Sadilek
Gabriel Luong
Codrut Topliceanu
Arturo Mejia
Oana Horvath
MarcLeclair
Sören Hentzschel
Sebastian Kaspari