1131415 - Avoid having Sync initialize if only reading-list is configured to sync

Status: RESOLVED INVALID

(Firefox :: Sync, defect, P4)

Description

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

We will be pretending there is a sync reading-list engine, but the implementation of that engine will not use Sync.  If the user configures Sync but only selects the reading-list engine, we should ensure Sync itself doesn't actually start just to do nothing.

Comment 1

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

The fly in this ointment is 3rd-party engines - it seems impossible to know for sure when such engines exists, as the old documentation for such engines offered advice to look for the various Sync observer notifications to register their engines.

I don't think we should suddenly drop support for such engines, nor to break them by creating a new canonical way to register such engines given that I expect users with only reading-list enabled will hopefully be rare.

So I think the best we can really do here is to ensure service.js "does the right thing" when there are no engines - which basically means to do as little as possible at sync time.

Richard, what's your take here?

Comment 2

[Richard Newman [:rnewman]]

I see two ways to look at this.

The superficially most simple is to say that Sync is a magic identity-attached service that can be trusted to do nothing, and so doesn't need to be turned off -- one of those TVs that doesn't have a power button.

Then we look at this situation as "how can we make Sync do no work?".

There are two problems with that.

One is that, in short: in the current world, you cannot have a configured Sync client that syncs nothing -- it always has to sync meta. That means this approach is actually dependent on the change we want to make in 39 to have per-device syncing preferences.

Currently, Sync's enabled state is synced with the server: if we decide not to sync when no boxes are checked, then that functionality breaks. You'll flip a checkbox on one device, and whether your desktop picks it up will depend on whether it has *any* boxes already checked!


The second issue is that it's a bad precedent and warrants user skepticism to do anything at all, and perhaps even to have the code loaded. "I unchecked every box; why is my Firefox phoning home every time my computer wakes from sleep?". Off should mean off.


But our UX folks are not fond of having a "Sync" checkbox.

The other way to look at this is to think of Sync as having an *invisible* master checkbox that's independent of Firefox Accounts (and I do propose introducing a real services.sync.enabled pref; users have been asking for that for a while, for unrelated reasons).

You can have an FxA without Sync being turned on. Checking any of the boxes during setup flips the "turn on Sync" switch. Leaving them all turned off will give you an FxA but no Sync.

The problem then can be rephrased as: what inputs do we use, both during setup and later, to decide when to flip that switch either on or off?

That's my high-level perspective on this.

At the code level, I feel that having an explicit pref control syncing, checked in Weave.js (lazy-loading), and explicitly changed as a result of user actions, is the clearest way forward. It's a little bit of rules-lawyering to make sure we both behave "Sync-correctly" (always sync meta) and "user-correctly" (do nothing if nothing is checked).

Comment 3

[Justin Dolske [:Dolske]]

P4 on Sync cost presumably not being a huge deal, and that most users will presumably end up using either both or neither.

Comment 4

[Marco Mucci [:MarcoM]]

Deprioritized during backlog review.  Removed from IT 39.2 priority backlog and not part of the initial Q2 campaign release.

Comment 5

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

The stuff we really care about is in bug 1131414, and fixing this correctly is a much bigger job than it appears, mainly as browserid_identity is needed to perform alot of the FxA heavy-lifting for reading list.

So unassigning and revising point value.

Comment 6

[Edwin Wong [:edwong]]

reading list is postponed - closing.