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 7a8b0a91c0)
The signing tasks are failing due to how one of their dependencies was
triggered (`build-docker-image-base`). We ran this task the proper way
so they should be fixed going forward. However, we need a new Decision
task to run so this new task is used as a dependency instead.
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>
Ryan VanderMeulen
github-actions[bot]
Jonathan Almeida
Mozilla Releng Treescript
MickeyMoz
rahulsainani
AndiAJ
mozilla-l10n-automation-bot
oana.horvath
jeddai
Andrew Halberstadt
Noah Bond
Arturo Mejia
Mugurell
DreVla
t-p-white
Zac McKenney
Aaron Train
Roger Yang
priyanka0906