1205928 - Auto-disconnect when showing the migration infobar

Status: RESOLVED FIXED

(Firefox :: Sync, defect, P1)

Description

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

It's possible that people still using legacy Sync are getting the migration infobar, but for whatever reason don't want to upgrade and don't realize that clicking the "upgrade" button will take then to Sync prefs where they can "unlink this device" (which is the terminology used by legacy sync IIRC). Eg, see bug 1205437 comment 5.

IOW, there may be users who are simply putting up with the migration bar because they aren't sure how to make it go away without causing (perceived) pain.

Given Sync is very soon EOL, we should consider updating the migration UI to offer a button saying "disconnect" or "stop using Sync" or something similar.

Alternatively: given 43 is the earliest we could realistically get this out to users (with 44 being more likely), we could decide to silently and automatically disconnect - by then Sync will have not been working for a significant amount of time so it seems fairly clear they don't care.

Whatchya think?

Comment 1

[Ryan Kelly [:rfkelly]]

> Given Sync is very soon EOL, we should consider updating the migration UI to offer a button
> saying "disconnect" or "stop using Sync" or something similar.

If it's a relatively simple change, then yeah, I think this would be worthwhile.  There's clearly a lot of users syncing and seeing the notice and not doing anything about it.

Comment 2

[Chris Karlof [:ckarlof]]

Given that the earliest we can get out changes is 43 or 44, is it worth doing anything?

Comment 3

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

(In reply to Chris Karlof [:ckarlof] from comment #2)
> Given that the earliest we can get out changes is 43 or 44, is it worth
> doing anything?

Anecdotally, I was helping my parents the other day and saw the 2 stacked bars, which they had no idea what to do with, nor how to make go away. I suspect that they would still have had the bars in version 45 had I not helped them remove it.

So I think we should do something - but given these time-frames, I'm thinking we should just silently and automatically disconnect (if the migration offer still exists then, I think it is safe to say these people just want it gone). Chris, what do you think?

Comment 4

[Chris Karlof [:ckarlof]]

A string-less fix sounds reasonable. What are the conditions under which we would "silently and automatically disconnect"?

Comment 5

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

(In reply to Chris Karlof [:ckarlof] from comment #4)
> A string-less fix sounds reasonable. What are the conditions under which we
> would "silently and automatically disconnect"?

I was thinking aggressively - as soon as we got an EOL notification from the EOLinator (ie, at the time we currently show the infobar). The next question is whether we should also remove the migration code - if we think it may be useful in the future to enterprises, then I'd say we add a new pref (services.sync.disconnectOnEOL) that we set to true, but enterprises using Sync 1.1 may prefer to set to false so they can get the same migration experience. Alternatively, we just ignore enterprise and make the migration their local problem.

Comment 6

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

We agreed that in 44, we will:
* disconnect from Sync as soon as we get an EOL message (probably based on a pref in comment 5)
* change the text of the infobar to say "You have been disconnected [learn more][connect to sync]"
* profit!!??

Comment 7

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

I believe we also agreed to not bother with the preference mentioned in comment 5 and just delete all relevant migration code from the tree. This reduces the engineering overhead of the migration code at the cost of leaving enterprise users of Sync on their own when it comes to migration from Sync 1.1 to Sync 1.5 - but it seems unlikely our migration could would actually be of benefit in that environment.

Comment 8

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

CC Nick so he is aware of our plans. tl;dr - this bug is likely to land in 44 (Jan 2016) or 45 (March 2016) by which time I think we can safely assume that anyone still seeing this bar simply doesn't know how to get rid of it, so we will automatically disconnect them.

Comment 9

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

Attachment: 0001-Bug-1205928-update-the-Sync-migration-code-to-automa.patch

Lots more code removal :) This patch automatically disconnects from legacy Sync once it sees an EOL notification.

Comment 10

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

Attachment: auto-disconnect.png

Ryan, are you happy with this UX? Note that once the infobar goes away for any reason it never comes back - the user is just in the "not connected to Sync" state.

Comment 11

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

(oh - and the "learn more" link takes the user to the same place it did when we actually migrated, which isn't perfect but IMO it is good enough)

Comment 12

[Ryan Feeley [:rfeeley]]

Attachment: Sync Broken.pdf

I suppose just getting rid of the bars makes sense at this unfortunate juncture, but I'm confused. The UX spec had covered the "Sync broken" state  (attached)very clearly. The design was last updated December 19, 2014. What happened?

Comment 13

[Edwin Wong [:edwong]]

:rfeeley - that hard disconnect task just got lost, it needed a discrete bug or brought up on the sync meetings. Markh informally brought up this idea and took the initiative to create a patch.

Comment 14

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

Yeah, we always planned on doing the hard EOL UX "later", but then the Sync decommissioning approached quickly and we ran out of time to get that done and on the trains before the servers were turned off - the end of May was the deadline for that and we missed it.

Comment 15

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/1df2049352ff

Comment 16

[Carsten Book [:Tomcat]]

sorry Mark, had to back this out for test failures like https://treeherder.mozilla.org/logviewer.html#?job_id=5234673&repo=fx-team

Comment 17

[Pulsebot]

Backout:
https://hg.mozilla.org/integration/fx-team/rev/fd4bf5ebb3cd

Comment 18

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

https://treeherder.mozilla.org/#/jobs?repo=try&revision=ac71ca0342c7

Comment 19

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/ddb5b8e191c9

Comment 20

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/ddb5b8e191c9