See https://github.com/mozilla-mobile/fenix/issues/4046 for a detailed discussion of this.
In short, this patch removes code that would conditionally hide desktop bookmarks depending
on the signed-in state of the browser.
Setting the `navigationBarColor` is done in the ThemeManager for the
attached activity. Since the migration UI is separate from that, we did
not get this for free.
This hides the keyboard after committing a URL in the
Toolbar right before we navigate from the SearchFragment
to the BrowserFragment. If the BrowserFragment is being
displayed before the keyboard is gone an expensive
resize of the engine view (content) is triggered when the
keyboard finally goes away. This is to prevent that.
We need to access the data in stat to get the process start time, so we
can calculate the time from process start until application.init for the
frameworkStart probe.
If we just use the HomeFragment itself, we end up with a memory leak since the lifecycle events
that would clean up the registry (e.g. destroy) won't run (if the fragment is retained in the backstack, for example).
* 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
This is triggered on collection expanding or shrinking that is animated.
The animation has android:fillEnabled="true" android:fillAfter="true".
This interferes with set visibility to gone and the click still triggers.
Disabling button avoids changing animation or force clearing it.
They were both in their packages by themselves, which feels unnecessary.
Unfortunately, a utils pkg is discouraged by kotlin but we don't have a
better place for them right now. Maybe an annotations/ pkg for the
latter?
Added a new option in Private browsing menu to allow or prevent screenshots from being taken while in private mode by adding or removing the FLAG_SECURE flag from the home activity's window.
This method is called whenever the activity is initialized to account for the browsing mode being changed and whenever the setting from the Private browsing menu is changed.
The setting is by default set to true (screenshots are allowed to be taken)
We could consider renaming the Activity to make it clearer that it's the
main activity and doesn't just feature the homescreen but I'm concerned
that renaming it will break too many things (e.g. automation that starts
a specific activity). For quick fix, I added this comment.
AccountObserver listeners were being triggered correctly, however, during every time
we open HomeFragment, home menu gets re-created, which causes us to re-run the initialization
block. Before this patch, the init block would never touch the account manager.
After this patch, it will query it if account manager has already been initialized.
`init` blocks are executed before `val` initialization which is declared afterwards
in the class. In this case, we had `quitItem` and `reconnectToSyncItem` as lazy,
but declared after the `init` block which may need them. And so, while this compiles
just fine, in practice we run into an NPE as the `init` block tries to get the lazy's value.
Simply re-ordering initialization fixes the problem.
* For #8412: Passes error handling function to 'CustomTabWindowFeature'
Change required for showing error message when the app can't handle a specific
scheme. Implemented in AC:
https://github.com/mozilla-mobile/android-components/pull/6122
* Upgrade AC version
Co-authored-by: Sawyer Blatz <sdblatz@gmail.com>
In order to hide the time it takes for the account manager to be initialized
(which always involves disk IO, and often network IO), let's kick it off
after "visual completeness".
This makes sure that for most users, by the time they interact with the account
manager-related functionality (e.g. in Settings), it's ready to go.
Also, for signed-in users, this will establish background sync workers.
This refactor "reverses" relationship between these two classes, allowing
HomeMenu to inform its parent, HomeFragment, of any changes to the menu.
Once that's in place, we start observing account manager changes (once its ready)
for account problems.
This solves two problems:
- initialization of the account manager is no longer necessary to build a home menu
- home menu now starts observing changes to the account manager's state (before it was static)
Instead of always kicking off accountManager's init and telling it to sync right away in
'onResume', we move these tasks to some abstract point later on, whenever account manager
is available.
This replaces the StartupTaskManager we had with a more general class.
New implementation is a thread-safe "gated task executor", which either
runs the task right away if it's marked as 'ready', or queries it to be
executed later on.
This ability to either execute or queue a task will be useful later on in the
commit series.
* let animation in top toolbar mode play nicely.
* remove duplicate methods, make code readable.
* migrate getToolbarNavOptions method to BrowserAnimator, one method to rule them all.
* Update linting
Co-authored-by: ahmedmamdouh13 <ahmedmamdouh13196@gmail.com>
In order to eat the perceived performance costs, we initialize storage
once we're visually complete. This way, we're reducing chances of user performing
a UI action which will trigger storage init and delay said action.
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).
In order to target specific variants of Fenix, we're adding schemas that
are specific that app in order to avoid collisions with the other
variants and with other forks of fenix that may have the same schemas.
The current schema for variants:
- Fenix Nightly: `fenix-nightly://`
- Fenix Beta: `fenix-beta://`
- Everything else: `fenix://`
This monitor for hot start was intended to be used by FNPRMS to measure
hot start. However, hot start was deprioritized so it's now essentially
unused.
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.
This patch removes the need to process() and then match() on every intent processor.
A successful process() means that we already matched. Doing this in two steps caused
issues when the process() failed but later the simple check in match() returned true.
After this patch lands I intent to remove the match() API from the IntentProcessor
interface in AC:
https://github.com/mozilla-mobile/android-components/issues/6097
Workaround for issue described in:
https://github.com/mozilla-mobile/android-components/issues/5989
For debug builds it is unnecessary to use the actual location provider since those builds
do not have an API key configured. With that patch we replace the location provider with
a dummy implementation in debug builds.
As far as I can tell, we never actually exercise the a-s libraries in Fenix tests currently (this was one of the presumed reasons for having a direct dependency).
In a different branch I've started work on adding end-to-end tests, but currently that's blocked on trying to figure out to load native libraries in tests (somehow, fenix's setup is different than what we have in A-C, not yet clear to me in what way).
Another reason for a direct dependency (i think) is that we needed it to configure a `fenix` megazord. This could be solved via a `support-megazord-fenix` a-c component that provides the correct transient dependencies,
but we can also just switch to use the `full` megazord instead, which is essentially what fenix megazord is at this point. A-S team wants to remove the fenix megazord, so this will help. This is what this patch does.
* For #8565: Create custom SharedPreferenceUpdater for String Preferences
* For #8565: Use custom updater to correctly update DropDownPreference
* For #8565: Set default values for dropDown preferences
* For 8565: add tests for findEntriesValue
* For 8565: clarified findEntryValue
Co-authored-by: Severin Rudie <Baron-Severin@users.noreply.github.com>
Added kapt plugin + dependencies in order to be able to use Room
Added recent apps to share fragment (top 6)
Extracted dimens of share_to_apps.xml in the dimens file
This patch refactors the widget layouts so that we can reuse the app icon and do not have to have
another logo resource with different constraints. This will also make it easier to update the
branding in #8277 and #8278.
Changed the order of the whitelisted migrations in order to respect the UI specifications.
Now using linked hash map instead of hash map for the whitelisted migrations so we can preserve the
order of the steps upon status changing in the migration process.
This new event will be sent when the user has successfully migrated from Fennec
to Fenix.
This event will only be sent to Leanplum and not to the other telemetry
services like Glean or Adjust.
Co-authored-by: ValentinTimisica <valentin.timisica@softvision.ro>
In order to ensure that the user's migration screen is not being bypassed by mistake, we handle the
migration's store COMPLETED state the same way we handle the MIGRATING state.
We can do this because we can treat the initial state (NONE) as being either a fresh start of the
app, either the user's intention of starting the home activity.
Before this change, if the app was being open from the shortcut after the migration was complete,
the user would have been encountered the home activity instead of the migration one.
The migration steps' status was already being shown as succeeded instead of showing an "unchecked" list of
steps.
These changes will make the steps being "checked" one by one as the migration advances.
In an early iteration of his patch on a beta build, I saw no improvement over
6 runs (Pixel 2):
- Before: 401.5ms
- After: 402.17ms
This may be attributed to noise in startup performance. However,
BrowsersCache disappears from profiles completely and results in
theoretical performance gains.
When using the StartupTimeline class (not landed yet), I see a 27.75ms
runtime improvement on beta builds after this patch.
- 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.
This removes Fretboard. The goal is to reduce cold startup costs associated with loading the experiments on the main thread. We currently have two experiments frameworks in use and should only require one.
Cache the list of installed browsers. Calling `Browsers.all`
the application directly redundantly recalculates the list.
Accessing the list of installed browsers through this cache
will reduce that overhead.
* For #4977 - Support opening Fennec pinned website shortcuts in Fenix
Fennec's pinned website shortcuts are set to open the BrowserApp activity.
So we need a new activity alias to actually catch such Intents. Otherwise they
would open "org.mozilla.firefox/.App" without any way to inform that this is
the result of the user clicking on a pinned shortcut.
For actually checking if the newly received Intent is of a Fennec pinned
shortcut we introduce a new FennecBookmarkShortcutsIntentProcessor which will
prepare the Intent to open the shortcut's URL in a new tab.
* For #4977 - Don't keep IntentReceiverActivity on the back stack
For successive Fennec pinned shortcuts to create a new IntentReceiverActivity
and be processed as normal we need to not keep this as our task root.
* For #4977 - Test the FennecBookmarkShortcutsIntentProcessor
This annotation was not applied correctly and lint was unable to ensure
it was used properly: it declared an error in lint saying so but that
error was ignored. I did not know how to apply the annotation - and I
felt it had limited utility - so I removed it entirely in order to
permit the lint baseline file to be removed (it was the only error).
* For #220
- Added advanced header + locale settings item in the settings fragment
* For #220
- Added locale selection page with lib state + handling of locale changes
* For #220
- Removed registering for locale changes in the manifest, allow system
to restart activity in that scenario
* For #220
- Added unit tests for locale settings page
* For #220: fixed an outdated unit test
ga-a
Co-authored-by: Severin Rudie <Baron-Severin@users.noreply.github.com>
* For #7410: rewrite updateBookmarkFromObservableInput with coroutines
* For 7410: remove RxJava from project. :(
* For 7410: converted updateBookmarkFromTextChanges to Flow per review
* For #7352: integrate highlightable browser menu changes
* For 7352: invalidate menu when reader mode availability changes
* For 7352: removed highlight from reader mode appearance per UX
* For #7254: Replace anko applyConstraintSet
* Anko has been deprecated and will not be continued
* Refactor ConstraintSet changes
* Replace applyConstraintSet in SearchLayouts
* Refactor HomeFragment ConstraintSet
* Define anonymous ConstraintSet
* Remove ConstraintSet prefix from PARENT_ID
Uninstall engine immediately and allow reinstall in onCancel.
Set previous list with default engine in onCancel.
Keep default engine change in operation and remove now unnecessary view refresh.
* For #7219 - Use accent color for downloads dialog positive button
* For #7219 - Fixes gap beneath download notification dialog
* switch to setimageresource
This call will acquire a "write" lock at the storage layer (sqlite's reserved+),
which may interfere with migrations that run during startup as well (they need to
write to storage, and so also need to acquire a lock). If these operations clash,
we get a SQLITE_BUSY crash. For now, just disable the maintenance operation.
* Fixes#7048.
Adds extension function to check if online or not based on capabilities
Modified `buildDeviceList`
Modifies tests
* Fixing lint error for max length
Fixing test in AppRequestInterceptorTest.kt
* Adds suppression for deprecation
Moving away from using anko for ConnectivityManager instance
* Creates ConnectivityManager extension component
* Fixes#7180
Refactors test cases to fix static mocks
If the intent that starts the HomeActivity includes an extra
boolean flag named finishonboarding and it is set to true,
Fenix will "finish onboarding".
As mentioned in the class comment, we could use an alternative
implementation to measure perf from outside the application however
it's more complicated to set up and less consistent with our cold
startup methodology so we'll start with this.
Add/Remove fullscreen flags in home fragment's onResume / onPause
Change homeLayout padding to include system bars height (status&navigation).
Change homeMenu orientation to UP to properly display menu.
Change home bottomBar background to transparent.
* For #5334: added private custom tab processor
* For #5334 - Fixes up IntentReceiverActivity for handling intents
* For 5334: update styling for private custom tabbs
* For 5334: update tests to account for new processors
Note that two are still failing. These appear to be true failures, and will be corrected in a later commit.
* For 5334: fixes bug introduced by changes to IntentReceiverActivity
RCA: intent className and extra were previously set based on which processors matched, not which successfully processed. This patch reintroduces that behavior.
* For 5334: add tests for custom tabs processing
* For #5574 - Part 1: Port TabAction.SaveTabGroup to TabSessionInteractor and SessionControlController. (#6651)
- Introduces the TabSessionInteractor, SessionControlInteractor and SessionControlController classes.
- Removes the TabAction.SaveTabGroup.
* For #5574 - Part 2: Port TabAction.PrivateBrowsingLearnMore to TabSessionInteractor and SessionControlController (#6651)
* For #5574 - Part 3: Port TabAction.ShareTabs to TabSessionInteractor and SessionControlController (#6651)
* For #5574 - Part 4: Remove unused TabAction.Share and TabItemMenu (#6651)
In #2205, the tab overflow button was removed which would have shown the
TabItemMenu when clicked. So, we can remove TabItemMenu since it is not
used and as a result, we can also remove TabAction.Share since there are
no consumers.
* For #5574 - Part 5: Port TabAction.PlayMedia and TabAction.PauseMedia to TabSessionInteractor and SessionControlController (#6651)
* For #5574 - Part 6: Port TabAction.Select to TabSessionInteractor and SessionControlController (#6651)
* For #5574 - Part 7: Port Onboarding.Finish to OnboardingInteractor and SessionControlController (#6651)
* For #5574 - Part 8: Port TabAction.Close and TabAction.CloseAll to TabSessionInteractor and SessionControlController (#6651)
- Removes TabAction
* For #5574 - Part 9: Port CollectionAction.Delete to CollectionInteractor and SessionControlController (#6651)
* For #5574 - Part 10: Port CollectionAction.ShareTabs to CollectionInteractor and SessionControlController (#6651)
* For #5574 - Part 11: Port CollectionAction.AddTab and CollectionAction.Rename to CollectionInteractor and SessionControlController (#6651)
* For #5574 - Part 12: Port CollectionAction.RemoveTab to CollectionInteractor and SessionControlController (#6651)
* For #5574 - Part 13: Port CollectionAction.OpenTab to CollectionInteractor and SessionControlController (#6651)
* For #5574 - Part 14: Port CollectionAction.CloseTabs to CollectionInteractor and SessionControlController (#6651)
* For #5574 - Part 15: Introduce a HomeFragmentStore (#6651)
- We will hook up the HomeFragmentStore in later parts.
- Removes List<Tab>.toSessionBundle(context: Context) since it is unused.
* For #5574 - Part 16: Port CollectionAction.Collapse and CollectionAction.Expand to CollectionInteractor and SessionControlController (#6651)
- We assume the store is hooked up to the SessionControlController in this part,
but this work will be done in a later part.
- Removes CollectionAction.
* For #5574 - Part 20: Remove the architecture module. (#6651)
* For #5574 - Part 17: Remove duplicate subscribeToTabCollections in BrowserFragment.kt (#6651)
There is a duplicate call of subscribeToTabCollections() in both HomeFragment and BrowserFragment.
In this patch, we remove the call in BrowserFragment to avoid passing the HomeFragmentStore to
BrowserFragment in order to dispatch the CollectionsChange event.
* For #5574 - Part 18: Delete SessionControlComponent and fix TabCollection and Tab imports (#6651)
* For #5574 - Part 19: Use the new HomeFragmentStore in the HomeFragment (#6651)
- Renames SessionControlUIView to SessionControlView
* For #5574 - Part 21: Fix white screen on home fragment (#6651)
* For #5574 - Part 22: Fix formatting in SessionControlInteractor and replace See with @see in SessionControlController (#6651)
* For #5574 - Part 23: Move to metrics.track call to the beginning of handleCollectionRemoveTab (#6651)
This ensures that the metrics.track will be called immediately before the tab is removed from the collection.
* For #5574 - Part 24: Use the sessionManager getter in SessionControlController (#6651)
* For #5574 - Part 25: Use mapNotNull in List<Tab>.toSessionBundle (#6651)
* For #5574 - Part 26: Simplify closeTab and closeAllTabs functions by assigning a deletionJob constant (#6651)
* For #5574 - Part 27: Replace listOf() with emptyList() in removeAllTabsWithUndo (#6651)
* For #5574 - Part 28: Replace the Context parameter with the HomeActivity in SessionControlController (#6651)
* For #5574 - Part 29: Add test for HomeFragmentStore, DefaultSessionControlController and SessionControlInteractor (#6651)
* For #5574 - Removes running CI against the architecture debug build varient
Thanks to the work of the team at application-services, it is possible
to asynchronously initialize the Http client and logger used by megazord
Use that power to hide the time necessary to complete this initialization
within the time that it takes to warmup the gecko runtime.
* For #5694 & #6054: Adds preference screen for toolbar
* For #5694: Adds changing toolbar position functionality
* No issue: Updates telemetry links to actually work lol 😬
* For #6054: Adds toolbar position to core ping
ekager
Mihai Branescu
mcarare
Simon Chae
Arturo Mejia
David Walsh
Vlad Filippov
ValentinTimisica
Roger Yang
Sawyer Blatz
Michael
Jeff Boek
Jonathan Almeida
Grisha Kruglov
Christian Sadilek
Michael Comella
Emily Kager
Mihai Adrian
Mihai Eduard Badea
Abhay Agarwal
Mugurell
Michael Droettboom
MickeyMoz
Gabriel Luong
codrut.topliceanu
Sebastian Kaspari
Edouard Oger
mcarare
Amaan Marfatia
Kate Glazko
ValentinTimisica
Severin Rudie
Elise Richards
Severin Rudie
Jim Porter
Josh Vocal
Andrew Gaul
Harshal Lele
Will Hawkins
MarcLeclair
Sparky93
Dennis Schubert
Mihai Branescu
Emma Malysz
Tiger Oakes
Kadeem
Mohammaduvez
Tiger Oakes
Sören Hentzschel
Chenxia Liu
Kaaira Gupta
Alessio Placitelli
Colin Lee
Rushab Kumar
mawen7
kglazko
Suraj Shah
Patrick Martin
Afzal Najam
Ryan Kelly
cesar