Bugzilla

I actually couldn't reproduce the issue on either the current Nightly or a local build. I was only seeing the expected calls, once when the element is inserted on load (from connectedCallback) and again each time I sync, e.g. by going to the FxA subview in the app menu (from the notification observer callback). Interacting with the feature callout didn't seem to have any effect.

Then I tried changing my sync settings to include "Settings" and I could finally reproduce the issue. Unfortunately, I lost a ton of prefs. Super annoying that when you enable syncing settings on one instance, it automatically enables it in the other because the sync settings are apparently themselves synced. But therein seems to lie the problem... do you have this pref set, Daniel? `services.sync.prefs.sync-seen.browser.firefox-view.feature-tour`

I'm guessing that's our issue. At one point, since I was syncing a local build with my normal profile, both running on the same computer, I changed the feature tour pref manually in about:config and less than a second later, it reverted back to the value from the other profile. I'm convinced that, since interacting with the feature callout changes prefs (the feature tour pref that persists the tour's state, plus impressions), that is causing a sync, and the sync service [is notifying](https://searchfox.org/mozilla-central/rev/0948667bc62415d48abff27e1405fb4ab4d65d75/services/sync/modules/SyncedTabs.jsm#186-198) Firefox View to gather the tabs again. That might not be exactly right but that seems to be the gist. If you disable "Settings" in the "what to sync" subdialog, I think you'll be able to confirm that this bug goes away.

If I understand correctly, the underlying issue seems to be, why are we firing `services.sync.tabs.changed` when tabs haven't necessarily changed? We seem to be basically translating one topic into another, but these topics are not the same. One seems to fire on every sync and the other should only fire when tabs changed. There's got to be a way to compare the last value to the current value before dispatching that seemingly tabs-specific notification.

I actually couldn't reproduce the issue on either the current Nightly or a local build. I was only seeing the expected calls, once when the element is inserted on load (from connectedCallback) and again each time I sync, e.g. by going to the FxA subview in the app menu (from the notification observer callback). Interacting with the feature callout didn't seem to have any effect.

Then I tried changing my sync settings to include "Settings" and I could finally reproduce the issue. Unfortunately, I lost a ton of prefs. Super annoying that when you enable syncing settings on one instance, it automatically enables it in the other because the sync settings are apparently themselves synced. But therein seems to lie the problem... do you have this pref set, Daniel? `services.sync.prefs.sync-seen.browser.firefox-view.feature-tour`

I'm guessing that's our issue. At least for me, it's apparently syncing the feature tour pref, and leaving that pref as evidence. At one point, since I was syncing a local build with my normal profile, both running on the same computer, I changed the feature tour pref manually in about:config and less than a second later, it reverted back to the value from the other profile. I'm convinced that, since interacting with the feature callout changes prefs (the feature tour pref that persists the tour's state, plus impressions), that is causing a sync, and the sync service [is notifying](https://searchfox.org/mozilla-central/rev/0948667bc62415d48abff27e1405fb4ab4d65d75/services/sync/modules/SyncedTabs.jsm#186-198) Firefox View to gather the tabs again. That might not be exactly right but that seems to be the gist. If you disable "Settings" in the "what to sync" subdialog, I think you'll be able to confirm that this bug goes away.

If I understand correctly, the underlying issue seems to be, why are we firing `services.sync.tabs.changed` when tabs haven't necessarily changed? We seem to be basically translating one topic into another, but these topics are not the same. One seems to fire on every sync and the other should only fire when tabs changed. There's got to be a way to compare the last value to the current value before dispatching that seemingly tabs-specific notification.

It seems that we just sync way less often when we're not syncing prefs. Apparently when syncing prefs is enabled, changing prefs can immediately trigger syncing. At least if we're actively using 2 profiles at the same time - I didn't try syncing prefs while only actively using one "device" so that might matter somehow.

But either way, it seems like we would still want to avoid triggering a sync when this particular pref is changed, just in light of the fact that it's basically a UI state. I'm not sure if this pref is intended to be synced. At least, we don't seem to be explicitly setting `services.sync.prefs.sync.browser.firefox-view.feature-tour`, it just seems to be getting set automatically. I think Meg might know more about that, I vaguely remember some recent discussion about syncing messaging system prefs?