* Revert "For #26790 - Dismiss search dialog when opening recent bookmark dropdown menu"
This reverts commit 262aa16991.
* Revert "For #26790 - Dismiss search dialog when opening recent visit dropdown menu"
This reverts commit b93b0850
* Revert "For #26790 - Dismiss search dialog when opening recent tab dropdown menu"
This reverts commit 44b71bb590.
* Revert "For #26690 - Dismiss search dialog when opening recent synced tab dropdown menu"
This reverts commit bda817a608.
* For #26957 - Remove code to dismiss search dialog when interacting with homescreen top sites
* For #26957 - Remove code to dismiss search dialog when interacting with homescreen collection
* For #26957 - Remove code to dismiss search dialog when interacting with homescreen recent visits
* For #26957 - Remove code to dismiss search dialog when interacting with homescreen recent tabs
* For #26957 - Remove code to dismiss search dialog when interacting with homescreen recent bookmarks
* For #26957 - Remove code to dismiss search dialog when interacting with pocket stories
* For #26957 - Dismiss search dialog when interacting with home fragment
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
We're seeing crashes in the Fenix copy of the `CFRPopup` that are
happening when our activity has already been destroyed, and then we are
trying to add a view to it with the WindowManager.
Our guess from looking at the traces are that the
`BrowserToolbarCFRPresenter` is receiving the `collect call on the main
thread, but further down the event loop. As well as the Runnable in
`CFRPopup#show` that is posting to the end event loop - both of these
calls are putting us in a state where the activity we want has already
been destroyed before we get to the moment where we want to use it.
This is a crash that is difficult to synthesize or write a test for.
As a result, our fix is rather speculative but still straight-forward
and safe to uplift, should it work.
There are three remaining follow-ups to do when fix is confirmed:
1. There is a CFRPopup that was upstreamed which is based on the Fenix
implementation. We should upstream this patch to that component as
well.
2. We should remove this copy of the CFRPopup and use the upstreamed
version to avoid confusion between the two copies.
3. With this change, we are now gracefully failing when our users get
into this state, however our telemtry and onboarding flows are
unaware that the CFR was never shown.
We need to to correct telemetry for `TrackingProtection.tcpCfrShown`
to stop incorrectly reporting false positives and reset our
`shouldShowTotalCookieProtectionCFR` pref to false so that we can
try again at the appropriate time.
Co-authored-by: Christian Sadilek <christian.sadilek@gmail.com>
