Speculative fix based on the Firebase logs which shows that on a second check
of R.id.tab_wrapper it is not found the screen.
It may be because after `advanceToHalfExpandedState` and before getting a
reference to it in `waitForTabTrayBehaviorToIdle` it was already animated off
the screen.
With this in mind I've added a null check for the view reference before trying
to register an idling resource on it's Behavior.
Also added and used a way to click at a specific location in a View, not just
in the default middle in the View.
It was observed from the Firebase videos that a "click" on the topBar actually
selected the private tabs section. This would leave us to believe that the
"click" was caught by that other View which was placed above the x,y middle of
the topBar.
* 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.
