[fenix] For https://github.com/mozilla-mobile/fenix/issues/10494: Process HomeMenu...
commit497e2aabefc43022f32699d6a8a8a48c0d2456f5
authorGrisha Kruglov <gkruglov@mozilla.com>
Fri, 22 May 2020 18:56:23 +0000 (22 11:56 -0700)
committerEmily Kager <emilykager@gmail.com>
Fri, 22 May 2020 20:50:57 +0000 (22 13:50 -0700)
tree93b894bbc0c3091fd7aa98d000faf3351ee48cb8
parentfa6008477ece3a3ceac48722be246f1d3b94d1b4
[fenix] For https://github.com/mozilla-mobile/fenix/issues/10494: Process HomeMenu builder changes on the main thread

Problem was that we were trying to process menu changes (in response to account manager events) on some background thread as that's what account manager emits them on, so some code internally in PopupWindow's dismiss handling (i think, didn't dig very deeply here) was silently giving up and we'd get into a bad state.

The reason this seemingly only happened if you quickly opened a menu on startup is because account manager isn't initialized until sometime after the startup finished. So the trick was to open the menu (and register account manager state callbacks) before it got initialized, so that the callbacks are invoked.

This should also reproduce in other, much more obscure ways, e.g. if you open the menu right before sync is scheduled to run in the background, change FxA password on another connected client, and then eventually receive a onAuthenticationProblem callback.
mobile/android/fenix/app/src/main/java/org/mozilla/fenix/home/HomeMenu.kt