Fenix: [Bug] Opening Fenix does not perform the same account sync tasks as the 'Sync Now' button

Created on 2 Dec 2020  路  7Comments  路  Source: mozilla-mobile/fenix

Steps to reproduce

  1. Attach a debugger to Fenix.
  2. Add a breakpoint at a DeviceConstellationObserver.onDeviceUpdated observer.
  3. Observe.
  4. Hit the refresh button.
  5. Observe again.

Expected behavior

  • At 3, we should have had the observer invoked.
  • At 5, we should have had the observer invoked.

Actual behavior

  • At 3, the observer is NOT invoked.
  • At 5, the observer is invoked.

Device information

  • Android device: n/a
  • Fenix version: All releases as of today.

This affects observers like the FxaPushSupportFeature which needs that notification to know if the push subscription has expired and needs to recover.

Push S3 馃悶 bug

All 7 comments

For context, Desktop also doesn't do exactly the same thing in both cases:

  • Desktop checks the push subscription every time the device list is fetched (ie, it isn't really tied to the push feature as such)
  • It only checks for missed commands when the button is pressed and only every 24 hours on a "scheduled" sync to try and avoid excessive load on these servers (which apparently struggle a bit more than the sync storage servers do)
* Desktop checks the push subscription every time the device list is fetched (ie, it isn't really tied to the push feature as such)

This sounds sensible! We should definitely do this on mobile too. Fetching the device list however, is tied to the 'sync now' button or by opening the share UI.

@mhammond when does desktop fetch the device list? Is this the part that is polled at an interval?

@mhammond when does desktop fetch the device list? Is this the part that is polled at an interval?

For better or worse, desktop tends to fetch the device list soon after starting up, and every time the device list is needed for UI. There are probably optimizations that could be made here, but lots of things are tangled and we never prioritized untangling them.

Best I can tell (ie, according to the debugger in a local build), Fenix already refreshes the device list on every startup via authenticationSideEffects. However, the code that tries to renew the subscription isn't called as it's observer isn't setup yet - the observer is setup here and the complex state machinery does things in an unfortunate order.

I don't think I can untangle the state stuff (particularly because I don't understand the difference between accountStateSideEffects and authenticationSideEffects (maybe @grigoryk can help) but I'm about to add a PR for (a) handling no push subscription the same as it being expired and (b) polling for missed commands when we are in this state - it will help a little, but without the state stuff untangled it's still not going to be ideal.

I can't tell if it is the same problem: if I send a tab from PC and then open firefox on mobile, it will not give me a notification about the tab from PC until I hit sync manually.
BTW, if you cold start firefox and open settings immediately, it will wrongly display that I'm logged out. I have to wait a while before it tells me that I'm logged in so that I can sync manually, which cause an even longer time to send a tab.

@ddarfantasy these are different issues from this one.

The send tab failure is tracked in https://github.com/mozilla-mobile/fenix/issues/16721

The account settings issue is a UI bug. Please file a separate issue for that with steps to reproduce. Thanks 馃檪

@mhammond with your change in https://github.com/mozilla-mobile/android-components/pull/9112, I don't think there's much value or urgency in this issue now.

Was this page helpful?
0 / 5 - 0 ratings