We do this in order to make it easier to analyze in GLAM: see the metric
descriptions for more details.
Additionally, we change the time unit to milliseconds to make it easier
to analyze in GLAM.
This was the previous behavior for both the top and bottom toolbars.
Regressed when changing to use a new custom behavior for the top toolbar.
When entering fullscreen we will now collapse and hide the toolbar, allow the
browser to expand to the entire screen estate and then, when exiting fullscreen
expand the toolbar.
Collapsing and then expanding the toolbar will trigger the
EngineViewBrowserToolbarBehavior to place the browser below the toolbar.
When the user opts out of telemetry, we need to reset the user identifiers
used by the experiment system, so that there's no risk of tracking the
user across the reset event if they later decide to re-enable telemetry.
* For #17352 - Fixes deleted downloads reappearing
The `getDeleteDownloadItemsOperation` job would check fragment context not null after the fragment was stopped. Removing that check and only passing the downloadUseCase as a parameter fixes the problem.
Previously when the toolbar was on top the banner was inflated in the toolbar's parent - an AppBarLayout.
After migrating to use a custom behavior for scrolling the toolbar and not use
anymore the AppbarLayout for this we needed a new solution.
Using a new behavior to keep this banner in sync with the y translation of the
toolbar gives us most of the old behavior back.
* Feature flag for toolbar menu redesign. Add new items to menu and reorder.
* Handle toolbar items in menu controller
* Menu controller tests
* Make icons invisible
* Lint
* UI tests reflect design change
* Refactor test names
* Lint fixes
* UI tests
* For #17418 - Adds channel "ts" to TrackKey
This is used to track if the `InContentTelemetry` is a result of the user using the Google Top Site. It looks for `&channel=ts` within the uri.
* For #17418 - Adds TopSite PerformedSearch back in
* For #17418 - Check now looks for equality with GOOGLE_URL
* For #17418 - Adds test for topSite changes
The IntentReceiverActivity one is particularly useful to quickly determine
when we can begin executing code in the WARM VIEW case (i.e. "Set selection
begin here").
The HomeActivity one is useful for COLD start up analysis in similar
ways and to see the Activity transitions in WARM VIEW.
This comes to unify the experience (with improvements but also specific issues)
for the url toolbar irrespective of it being placed at the bottom or at the top
Going further this will ease development and ensure the best UX for users.
* Moved Nimbus setup from Analytics to its own file
* Change experiment identifiers to fit new run of the experiment
* Re-enable nimbus for debug and nightly builds
* ./gradlew ktlint && detekt
Add privacy notice related strings
Pop out privacy notice with onboarding
Using embeded geckoview to display details about privacy
Present or hide privacy pop window according to isMozillaOnline
Add activity_privacy_content_display.xml into layoutNotToTest due to EngineView
We can't see the private API that we interact with on the OS, but after
some internal investigation it appears that there might be an upper
limit to the request code we can use.
For now, let's try a value similar to that use in the GVE code to see
our requests are failing because of that.
The awesomeBar was set to stay hidden for the first consumeFrom(store) if the SearchDialogFragment.kt. However, recent changes send an additional store update when the view is created. To work around it we can take a look at AwesomeBarView.update(), we see that the awesomeBar suggestions get provided only if the query != url. So we can use the same method to keep the awesomeBar hidden until the user changes anything in the url.
When testing out WebAuthn support with the privileged API,
we need our app to be signed by an allowed signing key.
We're seeing our tests fail with this error when testing locally:
```
[FidoApiImpl] updateTransaction is called for stop
[FidoApiImpl] finishSecurityKeyRequestController should not be called when SecurityKeyRequestController is null.
```
Our theory is that if we try this code on our signed APK, we should see
it work.
I validated:
- that the log statement appeared in Nightly but not in Beta.
- that the local runtimes of our perftest increased (the median diff is 124ms)
* For #16373: Added performance Inflater to counter # of inflations
This class is quite straight forward. The only thing that I have to point out is the onCreateView method. It usually
calls its super if you don't override it. The problem with that is that the super.onCreateView actually uses
android.view. as a prefix for the XML element it tries to inflate. So if we have an element that isn't part
of that package, it'll crash. As I said in the code, a good example is ImageButton. Calling android.view.ImageButton
will make the app crash. The method is implemented the same way that PhoneLayoutInflater does (Another example
is the AsyncLayoutInflater)
* For #16373: Added test for PerformanceInflater
This test got quite awkward / complicated fast. I wanted to test the to make sure we don't break *any* of our layouts
and to do so, I decided to just retrieve all our XML in our /res/layout folder. However, this gets quite a bit outside of a unit test scope.
The point was to get every layouts and get their LayoutID through the resources using the testContext we have. It gets even weirder, since some
of the XML tags have special implementation in android. One of them is the <fragment> tag. That tag actually is inflated by the OS using the Factory2
that the Activity.java implements. In order to get around the fragment issue, we just return a basic FrameLayout since the system LayoutInflater doesn't deal
won't ever get a <fragment> tag to inflate. Another issue was the <merge> tag. In order to inflate those, you need 1) a root view and 2) attach your view to it.
In order to be able to test those layouts file, I had to create an empty FrameLayout and use it as the root view for testing. Again, I know this is beyond the spirit of a unit test but if we use this inflater, I think it should make sure that no layouts are broken by it.
* For #16373: Overrode getSystemService to return PerformanceInflater
This allows PerformanceInflater to be called in every inflation to keep track of the number of inflations we do.
* For #16373: Added UI test for # of inflations
* For #16373: Lint fix
* For #167373: Changed the LayoutInflater cloneInContext to take this instead of inflater
The inflater parameter is set on the first call from the OS from the Window object. However, the activity itself sets multiple factories on the inflater
during its creation (usually through AppCompatDelegateImpl.java). This means that, once we initially set the inflater with a null check, we pass an inflater
that has no factory initially. However, since we keep a reference to it, when cloneInContext was called, it cloned the inflater with the original inflater
which didn't have any factories set up. This meant that the app would crash on either browserFragment creation or any thing that required appCompat (such as
ImageView and ImageButton). Now, passing itself with a cloneInContext means we keep all the factories initially set by the activity or the fragment.
* For #16373: Fixed code issues for PR. No behavior change
* For #16373: fixed some code nits
* For #11580 - Tracks text selection context menu usage
Tracks Copy, Search, Select All and Share items from the text selection context menu. Uses AC's DefaultSelectionActionDelegate to achieve this.
Co-authored-by: Gabriel Luong <gabriel.luong@gmail.com>
