1585292 - Addresses sync preference disappear after disabling sync

Status: RESOLVED WONTFIX

(Firefox :: Firefox Accounts, defect)

Description

[Vasilica Tamas, QA [:vtamas]]

Attachment: addresses-option.gif

[Affected versions]:
Firefox 71.0a1 (2019-09-30)

[Affected platforms]:
Windows 10 64-bit

[Steps to reproduce]:
1.Launch Firefox and login using a Firefox Account.
2.Navigate to about:preferences#sync and click on “Change” button from sync preferences area.
3.Click on “Disconnect..” button from “Choose What To Sync panel”
4.Click “Disconnect” button from “Disconnect Sync?” dialog.
5.Enable back the Sync by clicking on “Set Up Sync…” button.

[Expected Results]:
All 7 sync preferences are successfully displayed.

[Actual Results]:
Addresses option is no longer displayed.

[Additional notes]:
I am attaching a video recorded on Windows 10 x64.

Comment 1

[Mark Hammond [:markh] [:mhammond]]

This is, sadly, complicated. The pref services.sync.engine.addresses.available indicates whether the engine is available, and the default is false. However, if the engine is enabled, it becomes true. Resetting sync resets all sync preferences - including that "available" pref. So I'm afraid this isn't a bug - it's more an unexpected interaction with an engine that isn't really supported in the first place. IOW, the bug here is more that the addresses engine is disabled by default.

Comment 2

[Stefan Deiac]

Hello Mark,
I found a new scenario about the "Addresses" option.

After re-enabling the Sync, the "Addresses" option appears on the list but if you choose to select the "Change" button from the sync preferences area, the "Addresses" option is not on the list. So that means I can't disable/enable the "Addresses" option.

I found this issue using the latest Nightly 71.0a1 (2019-10-08) on Windows 10 64-bit.
Do you think I should open a different ticket about this issue?

Comment 3

[Mark Hammond [:markh] [:mhammond]]

Vasilica: thanks for the original report. How did you originally enable the "addresses" engine? I believe it's only possible to enable on a browser where services.sync.engine.addresses.available has been manually set to true. Because disconnecting sync will reset that pref, there's definitely a good chance that you will need to manually set that pref again after, but that's by design.

Stefan: Your issue is roughly the same - if you manually set that preference on some other device, then this device will show addresses as currently syncing, but because services.sync.engine.addresses.available is false on this machine, all settings for changing that engine are also disabled on this machine.

In both cases, it would be possible to, for example, explicitly set that preference to true whenever we notice it was previously enabled anywhere else - but we are choosing to not do that - the default value for that preference is false because the use of and syncing of the addresses feature isn't of the quality we need to enable it by default. It was previously set to true on Nightly, but that changed some time ago - it's not even considered good enough just for Nightly users - but the fact it did previously default to true on Nightly might explain how some of your test accounts ended up with it enabled.

Can you both please confirm that the above makes sense and explains what you are seeing here? If so, I'll end up closing this bug as invalid, so please be clear if you think that even with the above explanation there remains a bug we should fix.

Comment 4

[Vasilica Tamas, QA [:vtamas]]

Hi Mark, so this is what we see on Latest Nightly 71 from 2019-10-16:

• services.sync.engine.addresses.available pref is set to TRUE by default on a new clean profile
• Addresses option appears on Choose What to sync step from Create a FxA account flow (the pref is still set to true): https://prnt.sc/pkg88e
• The account is created and Addresses option appears in “You are currently syncing these items” list from about:preferences#sync: https://prnt.sc/pkgayf
• Disconnecting sync turns to FALSE the services.sync.engine.addresses.available pref
• Attempting to turn ON the sync will prompt a “Choose what to sync” dialog which does not display the Address option: https://prnt.sc/pkgd3f
• After the sync is enabled the Addresses option is displayed in “You are currently syncing these items” list from about:preferences#sync and services.sync.engine.addresses.available remains set to false: https://prnt.sc/pkgema

Please let us know if you need additional testing around this.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:markh, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 6

[Mark Hammond [:markh] [:mhammond]]

Thanks Vasilica,
This is more subtle than I thought. The default for services.sync.engine.addresses.available is false, but based on some other preferences, it will often be flipped to true as the browser starts - IIUC, always on Nightly, and on other channels it depends on the user's location and locale (eg, it will also be true for users in the US using en-US builds)

So what happens here is that sync resets every 'services.sync.*` preference when you disconnect - so it gets reset back to false. Next time the browser starts, it again gets flipped back to true for Nightly/US users.

The end result is that when a user disconnects from sync, if they try and reconnect in the same browser session, addresses is not available. However, if they reconnect after a browser restart, it does become available.

This sounds like a low-impact issue and wasn't caused by the recent "sync decoupling" work - it's been true for quite some time. Personally I'd be inclined to ignore it - I suspect users are very unlikely to hit in practice (disconnecting then reconnecting in the same session seems somewhat unlikely), although I'm probably just being lazy, because fixing it probably isn't too difficult (eg, we'd probably just move the .available pref to somewhere outside the services.sync branch?

Matt, WDYT?

Comment 7

[Matthew N. [:MattN]]

(In reply to Mark Hammond [:markh] from comment #6)

This sounds like a low-impact issue and wasn't caused by the recent "sync decoupling" work - it's been true for quite some time. Personally I'd be inclined to ignore it - I suspect users are very unlikely to hit in practice (disconnecting then reconnecting in the same session seems somewhat unlikely), although I'm probably just being lazy, because fixing it probably isn't too difficult (eg, we'd probably just move the .available pref to somewhere outside the services.sync branch?

Matt, WDYT?

I agree with your conclusions that this doesn't seem like something that is a high priority to fix.