You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
c84d0805ec
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>
(cherry picked from commit
|
2 years ago | |
|---|---|---|
| .. | ||
| androidTest | 2 years ago | |
| beta | 2 years ago | |
| debug | 2 years ago | |
| main | 2 years ago | |
| nightly | 2 years ago | |
| release | 2 years ago | |
| test | 2 years ago | |