[fenix] Bug 1799996 - Speculative fix checks CFRPopup.anchor is attached to window
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>pull/600/head
parent
dd8b924b49
commit
b4b031b8b6
Loading…
Reference in New Issue