Jim Mathies [:jimm] Assignee
	Description • 11 years ago

spun off from grab bag bug 865318:

"Pressing "Disconnect" button sometimes takes 2-3 minutes to fully disconnect from the sycning account. On some occasions, it wouldn't disconnect until Firefox Metro was closed and then restarted."


I think this is on purpose, we probably don't force a sync until the default timeout is reached. Ally suggested we remove this button entirely.

	Jim Mathies [:jimm] Assignee
	Comment 1 • 11 years ago

(In reply to Jim Mathies [:jimm] from comment #0)
> I think this is on purpose, we probably don't force a sync until the default
> timeout is reached. Ally suggested we remove this button entirely.

Ignore this, left over comment from the clone.

	Jim Mathies [:jimm] Assignee
	Comment 2 • 11 years ago

http://mxr.mozilla.org/mozilla-central/source/services/sync/modules/service.js#838

Looks like we do a lot of data purging when we disconnect. Maybe we can do some of this asynchronously. I'll try to figure out what parts of this take longer than others.

	Richard Newman [:rnewman]
	Comment 3 • 11 years ago

"Disconnect" should be used almost never: it means "disconnect from the Sync account and start over", not "stop syncing for a little while".

(On desktop it's labeled "Unlink this device", which is a more accurate description of what's happening.)

But it's only a slightly heavyweight process: it deletes client-specific data from the server (tabs, client record), and then modifies a bunch of prefs.

	Jim Mathies [:jimm] Assignee
	Comment 4 • 11 years ago

(In reply to Richard Newman [:rnewman] from comment #3)
> "Disconnect" should be used almost never: it means "disconnect from the Sync
> account and start over", not "stop syncing for a little while".
> 
> (On desktop it's labeled "Unlink this device", which is a more accurate
> description of what's happening.)
> 
> But it's only a slightly heavyweight process: it deletes client-specific
> data from the server (tabs, client record), and then modifies a bunch of
> prefs.

Yeah I think we need to change this button's label. We might want to warn with a popup before we take action too.

	Jim Mathies [:jimm] Assignee
	Comment 5 • 11 years ago

ui-review request for:

- new sync disconnect button label
- flyout prompt positioning
- flyout prompt text message
- flyout prompt button text

	Yuan Wang(:Yuan) – Mobile Firefox Design Lead
	Comment 6 • 11 years ago

Comment on attachment 744658 [details]
flyout

I agree that we need to confirm with the users when they tap "unlink device". 

My comment to the attached screenshot is:
We should keep the flyout simple with one flat hierarchy. Avoid using pop-up windows.

Please see the attachment below.

	Yuan Wang(:Yuan) – Mobile Firefox Design Lead
	Comment 7 • 11 years ago

The page when sync is connected.

I used "Disconnect" not "Unlink" because we have been using the word "Connect" during set up process. And the confirm dialog uses "Disconnect". I think it makes sense to keep the language consistent here.

"Disconnect" is a link not a button, which indicates that this is not an action. In this case, tapping on the "Disconnect" link will trigger the disconnect confirm dialog (see next attachement)

	Yuan Wang(:Yuan) – Mobile Firefox Design Lead
	Comment 8 • 11 years ago

The flyout page to confirm the action when the user taps "Disconnect".
A confirmation dialog should replace the "Disconnect" link. Tapping "Disconnect" will perform the action. Tapping "Cancel" will turn the user back to previous stage.


I believe the I got the texts from the current Sync dialog we have: "All your personal data on both this device and Sync account will remain intact."

But in Jim's screenshot, the texts indicate that "all the personal data will be removed". 

Richard/Jim, could you please clarify when you disconnect sync on Metro, what will happen to the data on the device and sync account? Thanks!

	Yuan Wang(:Yuan) – Mobile Firefox Design Lead
	Comment 9 • 11 years ago

The page when the disconnect action has been finished. 

The user should just be directed back to "Set up sync" page.

	Jim Mathies [:jimm] Assignee
	Comment 10 • 11 years ago

I'm confused by your use of "dialog", it looks like the prompt for disconnect confirmation is inline within the flyout. Is that correct?

Also, do we have a bug filed on revamping the sync flyout UI? This doesn't match the current UI we landed about a month ago.

	Jim Mathies [:jimm] Assignee
	Comment 11 • 11 years ago

(In reply to Yuan Wang(:Yuan) – Firefox UX Team from comment #8)
> Created attachment 744700 [details]
> [Mockup] Disconnect sync

In the case of disconnection, once the disconnect button is pressed, we'll need some sort of progress UI here (other elements hidden and a throbber of some sort displayed) since the disconnect work can take a while. Can you work something for that?

We also might want the same type of progress view for "connecting" and "syncing".

	Yuan Wang(:Yuan) – Mobile Firefox Design Lead
	Comment 12 • 11 years ago

(In reply to Jim Mathies [:jimm] from comment #10)
> I'm confused by your use of "dialog", it looks like the prompt for
> disconnect confirmation is inline within the flyout. Is that correct?
> 
> Also, do we have a bug filed on revamping the sync flyout UI? This doesn't
> match the current UI we landed about a month ago.

Yes, the prompt is inline, not a pop-up.

The related bugs are :
https://bugzilla.mozilla.org/show_bug.cgi?id=836393 
https://bugzilla.mozilla.org/show_bug.cgi?id=845468

Seems like the work has been moved to V2 triage.

	Richard Newman [:rnewman]
	Comment 13 • 11 years ago

Comment on attachment 744700 [details]
[Mockup] Disconnect sync

Minor nit: "from", not "with".

The warning is good (and accurate), but it's almost reassuring a user into thinking that this is a reversible action, when it's absolutely not.

To continue your point about symmetry: a user expects that when they hit "disconnect", the button then turns into "connect". 

Disconnecting is something users do on a regular basis -- wifi networks, chat clients, Xbox Live, etc. It's perhaps even weaker than "sign out", because that has the implication of a cleared sign-in box for someone else to type into.

Removing your device from a Sync account is a potentially unrecoverable action, and there's no one-click "reconnect" concept (and shouldn't be; so much state must be discarded that it's not possible to resume where we left off).

The only way to recover is to set up Sync again, and go through the whole first sync rigamarole. Assuming you have access to another device...

A user who's traveling might want to temporarily disconnect because of bandwidth concerns, read this reassuring statement about how safe all their data will be in the mean time, and end up costing themselves a hundred bucks in roaming charges to set up Sync again.

(Quite apart from the concern that their Sync data will probably be gone by the time they come back...)

I understand that symmetry is important, but I argue that either it's worth breaking in this case (because the user actions aren't symmetric: connect once, disconnect never), or you should fix the setup flow to use other language like "Add this device to my Sync account", "Configure", "Start using", "Set up", with corresponding 'stop' language like "Stop using Sync on this device", "Unlink this device", "Permanently disconnect", etc.


And our confirmation dialog should include language that clarifies what's going to happen: "Your browser data on this device will remain intact, but you will no longer be able to sync with this Sync account. You cannot undo this action."

	Jim Mathies [:jimm] Assignee
	Comment 14 • 11 years ago

Ok folks, we are going to scale this back. Revamping the UI has been moved to a future train, and clearly there are still language and flow details to be worked out. I'm going to move this info over to bug 836393. I'll also file a bug on checking the language of the existing UI (without changing any layout), and a bug about adding a warning prompt for disconnect.

	Jim Mathies [:jimm] Assignee
	Comment 15 • 11 years ago

Back to the original problem reported in this bug. I haven't been able to reproduce the disconnect taking a long time problem. We actually kind of hack this, sync does a lot of work when you make a call to startOver, but we reset the ui as soon as we receive 'weave:service:logout:finish', and there's no networking before that's sent.

Also, we never disable the disconnect button via script. We react to the push, and collapse the button if there's no configured account. So a disabled but visible button doesn't even seem possible. *shrug*.