Closed Bug 1096788 Opened 10 years ago Closed 10 years ago

about:accounts doesn't let you manage your account when configured for legacy sync

Categories

(Firefox :: Sync, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: markh, Assigned: markh)

References

Details

Attachments

(1 file)

Attached patch t.patchSplinter Review
As part of the sync migration, we are allowing about:accounts to be opened before sync is configured with FxA (bug 1017931)

However, in this configuration about:accounts shows only a "manage" button that takes you to Sync prefs - but Sync might still be configured for legacy sync (as the migration hasn't completed).  This makes it impossible to even see what your username is, or to log out etc.

A short-term solution is attached - when that "manage" button is clicked it redirects about:accounts to the normal online "manage" page.  One issue with this page is that there is still no "log out" facility - ie, the user can't change what account is used after they have signed in once.

Chris, Ryan, what should we do?  One option might be to stick with this patch and have "manage" offer logout.  Another would be a new <div> in aboutaccounts.xhtml
Attachment #8520396 - Flags: feedback?(rfeeley)
Attachment #8520396 - Flags: feedback?(ckarlof)
I forgot e10s was enabled in that profile, so this sounds lot like bug 1085813
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
ack - wrong bug - sorry about that.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
It's not clear to me how we're expecting someone to see this page when they're using old sync or are in the process of migrating. Are there cases beyond "entered the URL manually"?

Shouldn't about:accounts in this case just be directing you to start/complete the migration? I.e. get rid of the "manage" button and show a "Migrate" button instead?
Flags: firefox-backlog+
Hi Mark, can you assign a point value and mark it for QE verification.
Assignee: nobody → mhammond
Status: REOPENED → ASSIGNED
Iteration: --- → 36.3
Flags: qe-verify?
Flags: needinfo?(mhammond)
(In reply to :Gavin Sharp [email: gavin@gavinsharp.com] from comment #3)
> It's not clear to me how we're expecting someone to see this page when
> they're using old sync or are in the process of migrating. Are there cases
> beyond "entered the URL manually"?

Well, as currently spec'd, that's true.  However, if the user makes a typo entering their address (such that the verification mail never arrives and resending isn't going to work either) they would be stuck in the current flow.

So in effect, I think this bug really is "allow the user to change their FxA acct name after incorrectly entering it or they are at a dead-end.

> Shouldn't about:accounts in this case just be directing you to
> start/complete the migration? I.e. get rid of the "manage" button and show a
> "Migrate" button instead?

Yeah, although I'm mainly concerned with after they've done that once and realize they made a mistake.
(In reply to Marco Mucci [:MarcoM] from comment #4)
> Hi Mark, can you assign a point value and mark it for QE verification.

I'll do that as soon as we know what we are going to actually do.
Flags: needinfo?(mhammond)
(In reply to Mark Hammond [:markh] from comment #6)
> (In reply to Marco Mucci [:MarcoM] from comment #4)
> > Hi Mark, can you assign a point value and mark it for QE verification.
> 
> I'll do that as soon as we know what we are going to actually do.

Sounds good, I'll remove it from the iteration until then.
Iteration: 36.3 → ---
Comment on attachment 8520396 [details] [diff] [review]
t.patch

Review of attachment 8520396 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/base/content/aboutaccounts/aboutaccounts.js
@@ +284,5 @@
> +  let xps = Cc["@mozilla.org/weave/service;1"]
> +    .getService(Ci.nsISupports)
> +    .wrappedJSObject;
> +  if (!xps.fxAccountsEnabled) {
> +    document.location.href = Services.prefs.getCharPref("identity.fxaccounts.settings.uri");

If confused why it would be useful to direct them here. All they could do from the Web settings page is to delete their account or change their password. Wasn't the goal to provide them a way to disconnect?
Attachment #8520396 - Flags: feedback?(ckarlof) → feedback-
(In reply to Chris Karlof [:ckarlof] from comment #8)
> If confused why it would be useful to direct them here. All they could do
> from the Web settings page is to delete their account or change their
> password.

Sorry, I should have been clearer - I believe some server-side change will be necessary anyway, and thought allowing that settings URI to offer a log out seems natural and logical from the user's POV.  I'd be fine with a new entry-point just for this if you think that's easier or better.

> Wasn't the goal to provide them a way to disconnect?

To be clear, just "log out" rather than "disconnect" in the sync sense.

How do you suggest we handle this?
Flags: needinfo?(ckarlof)
> Sorry, I should have been clearer - I believe some server-side change will be necessary anyway, and thought allowing that settings URI to offer a log out seems natural and logical from the user's POV.  I'd be fine with a new entry-point just for this if you think that's easier or better.

Tricky one here. We explicitly removed the sign out link from the Web settings page. Clicking "log out" in that case does destroy your FxA session, but doesn't actually disconnect you from the browser (they are decoupled and we currently don't have any messaging between the two). Instead the user would see a "reconnect to Sync" message in the browser, which would be confusing.
Flags: needinfo?(ckarlof)
(In reply to Chris Karlof [:ckarlof] from comment #10)
> Clicking "log out" in that case does destroy your FxA
> session, but doesn't actually disconnect you from the browser (they are
> decoupled and we currently don't have any messaging between the two).

Maybe we should fix that using the same mechanism used for stuff like UITour and remote troubleshooting?
> Maybe we should fix that using the same mechanism used for stuff like UITour and remote troubleshooting?

We also landed the WebChannel work with an eye to that. 

However, longer term I'm not sure what the right thing to do is. If FxA was only used for Sync, then it might make sense, but it's intended to be used for other properties. Just because I want to sign out of my account settings on the Web doesn't necessarily mean I want to disconnect Sync.
:markh asked in IRC about whether it was appropriate to link to accounts.firefox.com/settings from the Sync pref pane. 

I don't know.

FxA is now used for:
Sync
Marketplace
FMD
Hello

It is no longer Sync specific, so actions taken on accounts.firefox.com/settings will potentially affect other applications as well. It seems that accounts.firefox.com/settings should have its own independent logout mechanism that doesn't affect your logged-in-ness with other applications, but it's a good question.

Ryan, can you weigh in on what the side effects of the log out link should be on accounts.firefox.com/settings?
Flags: needinfo?(rfeeley)
This is a tough one.

One approach would be to remove the account management link from the browser, limiting all user account interactions to add, removing or re-authenticating a Firefox Account. This might be the quickest fix, and appears to be the approach Google takes with iOS clients.

The second approach is to duplicate all of the account features in the native browser chrome (much like Apple does with the Apple ID in OS X preferences). Users can change their avatar, password and other more in both places. I don't want to burden the desktop team with this, and think it will only slow us down if we take this approach.

The third approach would be to make the manage link list all of the connected clients and allow them to manage the view from there.

https://www.dropbox.com/s/vgjev1hjcb3dlei/Connected%20Services.pdf?dl=0

If the user wanted to change their password, we could give them the option of allowing existing clients to remain signed in, so that only new clients would require the new password.

This is a pretty big change, but something I'd like us to explore, and certainly I'd like to hear other ideas!
Flags: needinfo?(rfeeley)
IIUC, we agreed in the recent sync meeting that the "forget" button in sync prefs is the only way we will expose to do this, so WONTFIX.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → WONTFIX
Attachment #8520396 - Flags: feedback?(rfeeley) → feedback-
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: