Bug 1784055 Comment 1 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

So, this is kinda interesting... The disconnect sync button per the STR, ends up calling `Weave.Service.StartOver()` per here: https://searchfox.org/mozilla-central/source/browser/base/content/browser-sync.js#1790

And that looks like it deletes user data but doesn't change the "identity.fxaccounts.enabled" and "services.sync.engine.tabs" prefs (the latter part explains why it gets stuck on the loading spinner). But because FX view finds out about this via the "weave:service:start-over" observer in [SyncedTabs.jsm](https://searchfox.org/mozilla-central/source/services/sync/modules/SyncedTabs.jsm#188), which also resets the `lastTabFetch` pref, it think it just needs another tab refresh and gets stuck there.

If you then click on "Turn on syncing" in the same place you disconnect it, a weave login notification triggers a UIState update and then shows most recent tabs (so it doesn't at least delete any tab data).

So I'll add that archived error state and have the button do the same thing the "Turn on syncing" button does.
So, this is kinda interesting... The disconnect sync button per the STR, ends up calling `Weave.Service.StartOver()` per here: https://searchfox.org/mozilla-central/source/browser/base/content/browser-sync.js#1790

And that looks like it deletes user data but doesn't change the "identity.fxaccounts.enabled" and "services.sync.engine.tabs" prefs (the latter part explains why it gets stuck on the loading spinner). But because FX view finds out about this via the "weave:service:start-over" observer in [SyncedTabs.jsm](https://searchfox.org/mozilla-central/source/services/sync/modules/SyncedTabs.jsm#188), which also resets the `lastTabFetch` pref, it think it just needs another tab refresh and gets stuck there.

If you then click on "Turn on syncing" in the same place you disconnect it, a weave login notification triggers a UIState update and then shows most recent tabs (so it doesn't at least delete any tab data).

So I'll add that archived error state and have the button do the same thing the "Turn on syncing" button does (not the third card in the setup flow to re-enable the pref, since that isn't the thing that was changed).
So, this is kinda interesting... The disconnect sync button per the STR, ends up calling `Weave.Service.StartOver()` per here: https://searchfox.org/mozilla-central/source/browser/base/content/browser-sync.js#1790

And that looks like it deletes user data but doesn't change the "identity.fxaccounts.enabled" and "services.sync.engine.tabs" prefs (the latter part explains why it gets stuck on the loading spinner). But because FX view finds out about this via the "weave:service:start-over" observer in [SyncedTabs.jsm](https://searchfox.org/mozilla-central/source/services/sync/modules/SyncedTabs.jsm#188), which also resets the `lastTabFetch` pref, it think it just needs another tab refresh and gets stuck there.

If you then click on "Turn on syncing" in the same place you disconnect it, a weave login notification triggers a UIState update and then shows most recent tabs (so it doesn't at least delete any tab data).

So I'll add that archived error state and have the button do the same thing the "Turn on syncing" button does (not show the third card in the setup flow to re-enable the pref, since that isn't the thing that was changed).

Back to Bug 1784055 Comment 1