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 #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.
* For #13336: Open bookmarks in current tab
* For #13336: Fix tests to verify bookmark opening in current tab
* Change test name for handleBookmarkTapped
* 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 #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 #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 #22534 - Update homescreen section name to "Recently visited"
* For #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 #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 #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>
* For #22410 - Refactored tab sorter metrics into a middleware
* For #22410 - Created distribution metric for tab group sizes
* For #22410 - Created tests for tabs tray middleware
* For #22410 - Merge fixes
* For #22410 - Added PR number to metric
* For #22410 - Fixed unit tests post merge. Added waitUntilIdle to new tests.
* For #22410 - Added missing line to middleware to have the Store process actions
* For #22410 - Updated metric expiration to December
* For #22410 - PR Feedback
* For #22410 - Removed else from middleware when
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.
* For #22075 - Added event to track the count of recent bookmarks
* For #22075 - Added data review issue number
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
* For #22107 - Added probe to track if the Recent tabs / jump back in section is visible
* For #22107 - Fixed lint errors
* For #22107 - added data review number to metric
* For #22166 - fixed expiration date
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
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>
* For #21903 - Added telemetry for interacting with inactive tabs
* For #21903 - Added missing inactive tab delete count event to delete all event
* For #21903 - Added PR numbers to metrics
* For #21903 - Updated broken unit tests. Resolved critical lint warning.
* For #21903 - Fixed inactive tabs setting toggle metric
* For #21903 - Updated FenixApp unit test
* For #21903 - Updated newline character in Metrics. Set inactive tab metrics' lifetime to default. Updated expiration to Nov 2022. Refactored inactive tabs metric to be a single metric.
* PR: addendum for last commit that missed a file
* For #21903 - Changed logic check for reporting inactive tab count
* PR: fixed merge conflict
* For #21903 - Removed tab close tracking when the user closes ALL inactive tabs
* For #21903 - Removed individual tab close metric verify from CLOSE ALL test
* For #21903 - Updated inactive tabs toggle setting expiration to match the expiration of the other events
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.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
