This replaces the default implementation from Android-Components to add the
functionality to first navigate to the browser fragment before responding to
service workers' requests of opening new tabs.
This will register itself when the main activity is created and unregister
itself when that activity is destroyed to support requests even when the
activity is in background but prevent any leaks.
Default will be disabled with users having the possibility to enable this from
a new setting in the `Privacy and security` section.
If enabled then by default this force https for all tabs with the option for
users to switch to forcing https only on private tabs.
* For https://github.com/mozilla-mobile/fenix/issues/23503: Respect studies pref and telemetry enabled pref when manually opting in to studies
* Add button to snackbar in nimbus secret settings that allows user to go directly to their data collection prefs
* Remove refactoring
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
It seems like this is the MIME type we're getting from the clipboard in
certain scenarios, e.g. after copying a link from Chrome or Gmail on
some devices.
Rename in a separate patch for git to not merge this to previous changes and in
such think that the the old file was deleted and a new one was created.
Whenever the ".crashed" property of the currently displayed
TabSessionState -> EngineState is true we will show an in-app crash reporter
with the usual close tab / restore tab options and also the option to report
all current non-fatal crashes to Mozilla if the setting for sending the crash
reports is enabled in app settings.
This closely mimics the previous crash reporter UI but there might be some
subtle differences stemming from migrating to using a ComposeView.
Whenever the ".crashed" property of the currently displayed
TabSessionState -> EngineState is false we will set the in-app crash reporter
to have a View.GONE visibility effectively removing it from the layout.
The functionality for receiving the non-fatal crashes from the AC CrashReporter
through an Intent is still kept and these crashes will be persisted in memory
until the user closes / restores a tab and so also makes a decision about
sending or not these crashes.
Currently more tabs can crash following just one since more share the same
process and as such there is no way to differentiate between them or link a
certain Crash to a certain tab.
They will all be acted upon at once from any tab the user chooses to close or
restore.
To lighten-up our memory usage and startup performance, all of the RecentlyClosed
machinery was converted to use a light-weight TabState - specifically, it's missing
EngineSessionState, which is expensive to obtain during startup, and potentially
very costly to keep in-memory.
When we actually need EngineSessionState (at the point of restoration of a tab), we
read and rehydrate it using provided storage implementation.
This would shorten the time needed to layout all Pocket recommended stories
content in one go, though it may lead to shorten hiccups over a bigger period
of time.
This adds a new `recently_closed_tabs` category with then events for all user
interactions on the screen.
The already existent `events.recently_closed_tabs_opened` is still kept for a
bit more time to still have this data available while the new telemetry ride
the trains but can later be removed in favor of this newly added events.
* Consume Nimbus FML plugin
* Convert Homescreen to use FML
* Convert nimbusValidation to use FML
* Convert legacy experiments to use the feature API and FML
Remove dead helper code and documentation
* Fixup failing test
Co-authored-by: Grisha Kruglov <gkruglov@mozilla.com>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
* For https://github.com/mozilla-mobile/fenix/issues/22576 - Indicate mutability flag for PendingIntent
* Fix lint issues
* Make Analytics Pending Intent flag mutable
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Due to the async nature (??) of the trimming code, this is causing severe performance issues
during search.
Looking back through commits, doesn't seem like there's a particularly good reason we were trimming here. All I could find is https://github.com/mozilla-mobile/fenix/pull/9986 (comment) which is lacking explanation of why this is actually useful.
And currently, we're dealing with an origin (not a full url when this was initially written, I think), i.e. https://accounts.firefox.com vs https://accounts.firefox.com/signin. So, the suffix stripping isn't even doing much beyond removing com in vast majority of cases.
So, seems like all of this trimming stuff can be cleaned up.
This introduces a separate HistoryDB type at the PagedHistoryProvider
layer, that doesn't need to deal with positions. Positioning logic in
HistoryDataSource becomes a type conversion between the new type and an
existing History type that UI and ItemKeyedDataSource API is written against.
With this refactor, we entirely eliminate nullability from these types.
We were converting Long timestamps into Ints (and getting negative
numbers back), and treating that as, basically, a position for the
paging API; the paging API would pass us back the obscure negative
number back as an offset, and we'll mishandle it resulting in an
infinite loop.
This patch removes all of the Long -> Int conversions, and introduces an
explicit 'position' that is calculated once we have a full page of
results completed.
* For https://github.com/mozilla-mobile/fenix/issues/22534 - Update homescreen section name to "Recently visited"
* For https://github.com/mozilla-mobile/fenix/issues/22534 - Show both history highlights and groups in Recently visited
For now the metadata groups don't support scoring so as an interim solution we
will show up to 9 items, evenly distributes, first favoring groups sorted by
date then history highlights pre-sorted by default.
Tapping a history highlight will switch to it's already open tab if available
or create a new one in which to load it if needed.
A "Remove" option will also be available for history highlights to remove it
from the screen and also from history.
Currently removing a group / highlight will not query new ones to again show up
to 9 items, this will be implemented separately.
* For https://github.com/mozilla-mobile/fenix/issues/22534 - Rename and refactor historymetadata to recentvisits
The updated feature supports more than history metadata so updating the overall
naming scheme seems needed.
To signal that this is a homescreen feature the entire package is moved to home
* For https://github.com/mozilla-mobile/fenix/issues/22534 - Update UI tests to account for the new items space on the screen
Saw failures about not finding the collection section on screen.
This is probably happening because w are now adding the recent visits to
homescreen above the collections section pushing it off screen.
Since the collections might be obstructed by the toolbar shown on top as a
quick solution we'll scroll to the next homescreen section so that the
collections will be shown above in their entirety.
* Update app/src/main/java/org/mozilla/fenix/home/recentvisits/RecentVisitsFeature.kt
Co-authored-by: Christian Sadilek <christian.sadilek@gmail.com>
* Update app/src/main/java/org/mozilla/fenix/home/recentvisits/RecentVisitsFeature.kt
Co-authored-by: Christian Sadilek <christian.sadilek@gmail.com>
Co-authored-by: Gabriel Luong <gabriel.luong@gmail.com>
Co-authored-by: Christian Sadilek <christian.sadilek@gmail.com>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
This patch fixes two problems:
1) We were treating "direct tab load" as an event which applies
uniformally to all tabs, even though it's actually an event which
happens for a specific tab. This lead to background tabs (pages opened as new tab)
setting the direct load flag, and then a simultaneously loading
parent tab would incorrectly interpret that flag for itself.
The patch switches this tracking from a simple boolean (are we direct
loading?) to a set of tab IDs that are currently direct loading.
2) In a case when a background tab was loading with a parent who's
search terms were cleared by a direct load, we were not trying to
lookup search terms on the background tab's historyMetadata key,
which exists to capture search terms for this exact scenario.
The patch adds an additional fallback lookup for that path.
Setting this value in FenixApplication.onCreate was buggy because of a race
with restoring BrowserState.
Setting it here would ensure a better granularity of the events and so to more
accurate reporting.
This allows querying from all throughout the app which of the current tabs are
inactive while taking into consideration whether the feature is enabled or not
such that when the feature is disabled it will always return an empty result.
Our boundary conditions for matching search groups to visits was wrong.
This change switches the boundary buffer to only be applied to history
items, not the metadata items.
In other words, when checking if any of the metadata items match the
current "page" of history, we'll be looking to see if the item falls
within this time window:
buffer - oldest history item <= metadata item <= newest history item +
buffer
There's a separate problem with buffer though: it's reset to 0 when requested
offset is >0, but that requires a larger refactor of this code, for a
separate PR.
A quantity probe in the metrics ping means we'll loose the granularity events
provided but it will be easier to extract the values.
For reporting whether the inactive tabs feature is enabled or not we already
have the "preferences.inactive_tabs_enabled" probe so I didn't duplicate this.
When deciding if we should include a history group within the "page of
history" results on the History View UI, we used to look at the most
recent timestamp of the metadata items within the group, and see if that
falls within the range of the timestamps of the history page, +/- some
buffer.
This assumes that each metadata entry will have a corresponding history
item. However, that's not true - when restarting the app, the selected
tab will be restored, and when opening History View right after we'll
record some metadata for it. However, we won't record a history visit
during the app restore for the selected tab.
That's all correct, but the assumption around group matching to history is now incorrect.
This patch changes the logic to instead look at every item within the
group, and see if any of them match the time window of the current
history page. This has a side-effect of also displaying search groups
multiple times on diffenent pages of history, if it makes sense to do so chronologically.
I think that's fine, it reflects reality at least (e.g. items within the
group may have been visited at very different points in time).
Co-authored-by: Christian Sadilek <christian.sadilek@gmail.com>
Fetching a set of logins from the store is quite expensive. This commit
avoids doing that while navigating back and forth between the list and
detail views:
- retain processes logins state when navigating into detail view
- use the `get` storage api to obtain specific login, instead of
`list().filter {...}`
- avoid re-sorting retained logins when navigating back into the list
view
Switched to always using `Login` instead of the `SavedPassword` alias.
Made `MasterPasswordTipProvider.saveLogins()` call
`importLoginsAsync()`. This is needed because it's the only method that
inputs a `Login` rather than a `LoginEntry`.
Moved the `SavedLoginsStorageController.kt.syncAndUpdateList` call
to inside `add()` and `update()`. This simplifies the error handling a
bit.
Refactored dupe-checking code to use findLoginToUpdate()
Refactored `AddLoginFragment` / `EditLoginFragment` to put the username
error handling code all in 1 method. I think it's easier to follow the
logic of showing/hiding the error labels when it's all in one place.
This fixes issues https://github.com/mozilla-mobile/fenix/pull/24103 and https://github.com/mozilla-mobile/fenix/pull/24104. I would love to address https://github.com/mozilla-mobile/fenix/issues/24102,
but I'm not sure what the correct behavior is there so I just kept that
the same.
Before this patch, this was the behavior - 'remove' button is clicked, we'd ask
the storage to remove metadata (on its IO thread), then navigate to Home
Screen.
This resulted in a race we could end-up on the Home Screen before delete
finishes, so the search groups do not appear to be removed (but,
refreshing the Home Screen again shows that they are removed).
This also resulted in an unnecessary navigation which felt very janky
(screen will "scroll" to the top) and was way more work than necessary.
After this patch, we:
- dispatch two actions (on browserstore, on homefragmentstore) which
remove the search groups from any relevant in-memory state; any UI bound to
this state will be automatically "refreshed"
- no longer navigate as part of the remove action, so the UI doesn't
move and removal happens "in-place"
This regressed in our previous fix that made sure child tabs don't
mistakenly get moved out of the group if their parent is navigated
away, or in case the child tabs are redirected.
However, when a subsequent load occurs in any tab in the group the
search terms need to be cleared and the tab removed from the group
to prevent false positives.
* For https://github.com/mozilla-mobile/fenix/issues/21360 - Added toggle for search term tab groups
* For https://github.com/mozilla-mobile/fenix/issues/21360 - Lint cleanup
* PR: Added missing licenses and possibly fixed UI test
* PR: Added a "scrollTo" to potentially fix a UI test
* PR: Added potential fix for alwaysStartOnHomeTest
* PR: Added temporary ignore to alwaysStartOnHomeTest
* PR: added missing ignore comment
* For https://github.com/mozilla-mobile/fenix/issues/21360 - Added missing feature flag driven visibility logic
Co-authored-by: Sebastian Kaspari <s.kaspari@gmail.com>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Home screen isn't actually visible in case we're displaying awesomebar
search results. The navigation is thus unnecessary and actually causes visual
jankiness as we display home for a moment before covering it up with
search results.
We currently have a 15s buffer to match metadata to its corresponding
visit. However, a existing metadata record can be updated more than
15s after it was created e.g. when closing the tab and updating
the view time.
We discovered that in a tab restore scenario we were recording view time
observations that were wrong - we'd record time deltas as-if user was
looking at the page while the browser wasn't running.
This happens because when we record a viewTime observation, we compare
current time with lastAccess time of the tab. In a restore scenario,
that lastAccess time happens to be from when the browser was last
running - which could be days ago.
The simplest solution was to not record a viewTime observation if the
url for a tab didn't change during a load event. To achieve this, we
needed to change which action we were using as a proxy for "navigation
events" - UpdateUrlAction contains the new url, allowing us to compare
against the current tab url.
Alternative solutions would be to keep using loading actions, but
dispatch a lastAccess event before performing a metadata update. This
would have worked, but would result in two lastAccess events being
dispatched for each navigation event instead of just one.
This is a speculative fix for the intermittent issue. Typically, these
intermittents are caused by mocked lambdas but there is no mocked lambda
here. If this doesn't work, one `any()` argument fills in for a lambda:
it's possible that's causing the failure.
Unfortunately, I can't verify this fix easily because the "run test until
failure" option was removed from Android Studio.
See d396c9eb41298cc07fbf136f1de971010bc45d97 for a prior attempt to
address the intermittents in this class.
This is a bug we noticed after landing search term grouping.
An adapter can submit an empty list of items to the `ConcatAdapter`
early. This has the side-effect of triggering our `observeFirstInsert`
too soon and therefore updating the visibility to show the empty tray
placeholder and never switches back.
Our solution is to keep a constant observer on the adapter so we can
perform the visibility check on every insert/remove.
Co-authored-by: Roger Yang <royang@mozilla.com>
The test as it exists relies on the robolectric lifecycle, which is hard
to predict, so it doesn't seem worth fixing the test. Writing the test
any other way would require excessive mocking, which also seems
impractical.
* [WIP] New Layout for adding login and 'add login' button in 'SavedLoginsListView' to launch it.
Fixed bindings.
* [WIP] Removed "reveal password" button
* [WIP] Added interactor for the add login screen
* [WIP] Trying to check for duplicates
* [WIP] Renaming "addNew..." with "add..."
* [WIP] Check for duplicates
* [WIP] Fixes after merge
* Cleaning up the layout and making edit text for hostname selectable
* Error handling on add login screen. Tests for interactors and controllers
Co-authored-by: Vitaly V. Pinchuk <vetal.978@gmail.com>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
* Issue mozilla-mobilehttps://github.com/mozilla-mobile/fenix/issues/21140 - Updated recent tab logic to show media tab and second-to-last tab, if the media tab was the last active tab.
* Fixed RecentTabsListFeatureTest unit test
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
* Update Android Components version to 93.0.20210901143120.
* For https://github.com/mozilla-mobile/fenix/issues/21043 - Integrate AC changes
* Fix breaking API changes of RestoreAction
Co-authored-by: Mugurell <Mugurell@users.noreply.github.com>
Co-authored-by: Christian Sadilek <christian.sadilek@gmail.com>
* Add telemetry probes for recent bookmarks on home screen. Tests for controller.
* Make the events into counters in the metrics ping
Update tests to reflect new metrics
Add data review link for new metrics
Mock new settings for startup metrics tests
Update metrics
Add test for recent bookmark glean events
* Recent bookmarks controller tests
Two new events are added:
- "inactive_tabs_expanded" for when the inactive tabs section is expanded
- "inactive_tabs_collapsed" for when the inactive tabs section is collapsed
For tracking when an inactive tab is opened / closed I've repurposed the
existing tabs tray telemetry (since the functionality uses the same code)
- tabs_tray.opened_existing_tab
- tabs_tray.closed_existing_tab
to support an extra "source" key indicating the feature from which a tab was
opened or closed. The current values for this new key are:
- "Tabs tray" for when a tab was opened/closed from tabs tray
- "Inactive tabs" for when a tab was openes/closed from the Inactive tabs
section of the tabs tray.
This test seems to be hacking at the binding between Fenix and the
BrowserToolbar to simulate toolbar events passing to the Fenix
interactor.
This is rather clumsy test that relies on the magic working of mockk
instead of following a general unit testing strategy that would commonly
require the class to be re-written to allow for better testing instead.
It is far safer to remove this test since we are not guaranteeing
anything in it and instead we see intermittent failures that make us
lose more time.
So therefore.. 🔥
The expectation is that replacing `return` with `answers` will compute
the return value for the extension function again in order to avoid the
error, "no answer found for: Settings".
Theoretically, this should marginally decrease the duration of our unit
test suite. In my testing, for 1 iteration each (i.e. noise is very
possible), the duration changed from 9m 32s to 8m 21s – a 71s
improvement.
---
To identify tests that were running with robolectric that didn't need to
be, I removed the @RunWith(FenixRobo... from all relevant files:
sed -i '' "/@RunWith(FenixRobolectric/d" app/src/test/**/*.kt
I ran the tests and discovered which ones failed from the Classes tab of
the index.html test result file. Something like:
tests = document.querySelectorAll('table')[3].querySelectorAll('tr');
failureElements = tests.querySelectorAll('.failures');
// TODO: extract the test names
Then I copied these results to a text file and compared them to all the
files that had robolectric test runners to figure out which ones still
pass:
comm -1 -2 failures.txt changed_files.txt > robolectric_not_needed.txt
And undid the changes to the failing files:
for i in $(cat robolectric_not_needed.txt); do git checkout $i; done
Then I removed the import statements on those files:
for i in $(cut changed_files.txt); do sed -i '' "/import.*RunWith/d" $i; done
for i in $(cat changed_files.txt); do sed -i '' "/import.*RobolectricTestRunner/d" $i; done
* Navigate to home on toolbar click. Handle back press from search dialog
Update tests to show home behind search dialog. Remove unused test.
Jump back in show all button is clickable behind search dialog
Recently saved bookmarks show all button is clickable behind search dialog
* Add feature flag
* Past explorations show all button is clickable behind search dialog
Handle keyboard in controllers instead of viewholders. Update tests.
Allow collections to be visible behind search dialog
Dismiss keyboard and search dialog with navigateUp instead of just dismissing the keyboard
Verify navigateUp in tests
Adding ignore for flaky UI test
Only resize home behind search dialog
Add ignore for collection intermittent test
Cleanup
We use make the inactive tabs section of the tabstray collapsible in
this change, with a technical quirk: we want to make the "isExpanded"
state of the tabs stay for the lifetime of the app and not the tabs
tray, but this functionality does not exist.
In this patch, we're storing the UI state in a singleton class that
exists for the lifetime of the app, but a more concrete solution is to
use an AppStore that holds content like this, which we can land in a
future patch.
The errors that caused this to be @Ignored were addressed by a recent PR
landing on master (i.e. the one that renewed the probes this test is
testing).
* Remove references to preferences.open_links_in_private and preferences.private_search_suggestions in tests. These metrics have been expired and may be removed.
* Add ignores for performance metrics that have expired.
* Remove tabs_tray.cfr.dismiss and tabs_tray.cfr.go_to_settings telemetry probes.
* Remove metrics controller from signature and remove in tests
To remove the flash on refresh of the topsites list we have to use submitList, however using this too high up in the hierarchy of our listAdapters within listAdapters will cause children to refresh at once. The solution to this is to use submitList lower. Using it in TopSitesPagerAdapter.kt to update the TopSitesAdapter is the way to go. I've also had to use a dummy item for the "removed" Topsite ( with id = -1) so I can manually diff that before using submitList.
The reducer in this middleware assumes the SessionState is always a
TabSessionState which holds the lastMediaAccess. This is true for the
lastAccess long which is a persistent state.
The list of MediaSessionActions however can also come from Custom Tabs
which relies on a CustomTabSessionState.
For now, the temporary fix is to disable this feature by removing the
middleware and no longer adding the last accessed media to the
recent tabs list ("Jump back in") to avoid crashing users while we think
of a real fix.
* Title and button for home screen recently saved bookmarks section
Create bookmark item view with favicon and title
* View holders and interactors for recently saved bookmarks
Recent bookmark item view holder binding
Create adapter for recent bookmarks. Implement controller methods. Implement view holder bindings for items
Top level adapter for recent bookmarks section
Retrieve list of recent bookmarks on home
View holders and interactors for recently saved bookmarks
Recent bookmark item view holder binding
Create adapter for recent bookmarks. Implement controller methods. Implement view holder bindings for items
Top level adapter for recent bookmarks section
Retrieve list of recent bookmarks on home
Update list on app start and when bookmarks are added
View holders and interactors for recently saved bookmarks
Recent bookmark item view holder binding
Create adapter for recent bookmarks. Implement controller methods. Implement view holder bindings for items
Top level adapter for recent bookmarks section
Retrieve list of recent bookmarks on home
Update list on app start and when bookmarks are added
Make a use case for retrieving and updating the list of recently saved bookmarks
Add adapter items and define header viewholder binding
Use session interactor for header button clicks. Bind in the adapter
* Retrieve list of bookmarks asynchronously on home
Interactor and controller tests
Address review comments
Split up tests for recent bookmarks
Update to new interactors
Dark mode and light mode styles
Refactor bookmarks home stuff
* Add RecentBookmarksFeature to home
Move interactor to SessionControlInteractor
Clean up lint, styles, and dimens.
* Bookmarks use case tests for retrieving recently saved bookmarks. Linting.
* View holder tests
* Match ux to designs for colors, margins, and scrolling
* Clean up clean up
* Tests for the view bound feature
* Controller test
* Clean up: check state of store in feature tests; ellipsize textviews for bookmark item; remove unused attr; format
Co-authored-by: Jonathan Almeida <jalmeida@mozilla.com>
This new method allows a single source of truth for getting the up-to-date
account status without clients interesting in this needing to know what to
check for.
As in the previous version of tabs tray when tray is expanded while in portrait
it should have a 40dp offset and when the tray is expanded while in landscape
it should have a 0dp offset - effectively making it fullscreen.
These values were set in code, always overriding the xml set value so I
removed that xml declaration.
Setup a new TabSheetBehaviorManager with all the dependencies it needs to
set the initial tray's behavior.
This same manager will later be called to update behavior's properties.
- Renames `BrowserInteractor` to `DefaultBrowserTolbarInteractor`
- Renames `BrowserTooolbarViewInteractor` to `BrowserToolbarInteractor`
- Refactors `BrowserToolbarViewInteractor` interface from `BrowserToolbarView.kt` to `BrowserToolbarInteractor` as `BrowserToolbarInteractor`
We were crashing because we were specifying the wrong `CreditCardNumber` type when constructing the `UpdatableCreditCardFields`.
We only had the plaintext card number from the user input, but was placing it off as an encrypted card number, which resulted in the crash.
In our current MVI implementation the View Interactors are first called in
response to a direct user action and contain methods following the
"onXXHappened" naming scheme and then delegate other Interactors / Controllers
for specific actions.
Controllers contain the business logic for actually updating the app's state
and offer methods following the "handleXXAction" naming scheme.
We now have a BrowserTrayList.
- Renamed from `BaseBrowserTrayList`.
- Removed the abstract `configuration` and used a `lateinit var`
instead.
- Removed `NormalBrowserTrayList` and `PrivateBrowserTrayList`.
The main cause for this is that the `LifecycleProvider` needs to be set
to `State.RESUMED` to avoid the account manager's internal
`ObserverRegistry` from putting the UI observers into the paused state.
The rest of the changes is to rely the internal (safe) logic to
correctly sync and then update the tabs list.
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.
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>
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.
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.
Alexandru2909
MatthewTighe
Mugurell
Gabriel Luong
mcarare
jknair
jhugman
Arturo Mejia
Noah Bond
mike a
sarah541
Brais Gabín
Sebastian Kaspari
Jonathan Almeida
Elise Richards
Christian Sadilek
Grigory Kruglov
Roger Yang
Rohan Maity
Lucius C
mavduevskiy
Grisha Kruglov
aime Soriano Pastor
MickeyMoz
Noah Bond
Jonathan Almeida
Michael Comella
Ben Dean-Kawamura
sunil9211
codrut.topliceanu
bendk
Mickey Moz
Rohan Maity
Vitaly V. Pinchuk
Marc Leclair
Codrut Topliceanu
Mihai Adrian Carare
rxumoz
ZianeA
Ionut Cristian Bedregeanu
Kate Glazko