95151 - Delete profile dialog is confusing

Status: RESOLVED EXPIRED

(SeaMonkey :: Startup & Profiles, defect)

Description

[Yuying Long]

Please make dup if there is one existing.

Build: 08-10 Win32 trunk build on Win2k-CN, N6.1RTM on all platforms.

Steps to reproduce:
1. Start Profile Manager.
2. Click on "Manager Profile".
3. Hightlight any profile that you want to delete, click on "Delete Profile".
4. There will 3 buttons appears:
   Don't Delete Files, Delete Files, Cancel.
5. Click on "Don't Delete Files".

Result:
The profile will get delect from the list of profile, and if you go to the 
actually the profile location(path), this profile still there.
If you quit profile manager and re-start it again, you won't see this profile 
inside the profile manager list.

Comment 1

[Jon Rubin]

This looks like bug 65068.  Maybe this is an example of UI that could be
improved, since some people might not realize that a profile consists of files
and therefore could interpret "Don't Delete Files" as a way of canceling Profile
deletion (even though there is a separate Cancel button).

Comment 2

[Grace Bush]

I believe  Communicator 4.x behaved this way.  
What happens now is 'as designed'.  Profile should get deleted, profile files 
should not get deleted.

A user can create another profile and reuse the non-deleted files.  

cc'ing ccarlen

Comment 3

[Conrad Carlen (not reading bugmail)]

The behavior described here is exactly right - choosing "Don't Delete Files"
deletes the profile but does not delete the files. Choosing "Cancel" is what
does nothing at all. I recently changed this dialog for bug 87904 in order to
show what folder was going to be deleted.

Maybe the text of the buttons could be made still clearer, maybe "Cancel" should
be called "Don't Delete Profile" Since the behavior is correct but maybe the
dialog confusing, changing summary.

Comment 4

[timeless]

Remove Profile | Delete Files and Profile | Cancel?

[case subject to negotiation]

Comment 5

[Conrad Carlen (not reading bugmail)]

How about just two buttons: 

Remove Profile | Cancel

along with a check box:

X Delete profile data files

Having just two buttons makes the choice more clear: delete it or not. Deleting
the files as well is a modifier (hence a check box) which obviously applies only
if Cancel is not chosen.

Comment 6

[Conrad Carlen (not reading bugmail)]

Attachment: proposed 2 button dialog

Comment 7

[Conrad Carlen (not reading bugmail)]

Just for fun, here's a screen shot of my proposed two button dialog. I bet my
dog could figure this one out ;-) It's only a slight change from the current
dialog which is pictured on bug 87904.

Comment 8

[James Green]

mpt, could probably use your words of wisedom here.

Comment 9

[Matthew T (active 1999-2002)]

*** Bug 37387 has been marked as a duplicate of this bug. ***

Comment 10

[Matthew T (active 1999-2002)]

From bug 95151: this is dataloss, as on Mac OS, the `Delete Files' button is 
currently where users will expect the `Cancel' button to be. (The same problem 
applies to Conrad's design.)

I suggest:
+------------------------------------------------------------+
|::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
+------------------------------------------------------------+
|   ,   Are you sure you want to permanently delete the      | <caption>
|  /!\  messages, bookmarks, certificates, and other files   |
|  """  in the profile "mpt"?                                |
|                                                            |
|       To hide the profile from the Profile Manager without | <description>
|       deleting its files, choose "Remove From List".       |
|                                                            |
|       ( Remove From List ) ( Cancel ) (( Delete Profile )) | [Mac]
+------------------------------------------------------------+

If bug 95649 was fixed this design would be achievable using nsIPrompt, but for 
now it has to be raw XUL.

Comment 11

[Matthew T (active 1999-2002)]

Och. So as not to regress bug 87904, change `profile "mpt"' to `folder 
"Macintosh HD:Documents:Settings:Mozilla:mpt"' in the above.

Comment 12

[Brant Gurganus]

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.

Comment 13

[Brian 'netdragon' Bober]

I think we should have an additional confirmation if the user checks the
checkbox. On something done so infrequently as this, it won't hurt to have an
extra confirmation. Its the equivalent of, in regular conversations, making
extra sure someone really really wants to do something and knows the consequences.

+------------------------------------------------------------------------+
| You have checked the option to not just remove a profile, but also     |
| remove the files in associated with it. All files in this directory    |
| will be removed, and all your profile settings will be permanently     |
| deleted (bookmarks, themes, mail, etc). If you want to remove the      | 
| profile from Profile Manager, but don't want to delete the files,      |
| choose "Don't delete" below, and you will be able to go back and       |
| uncheck the box. We recommend this option if you aren't sure.          |
|                                                                        |
| Are you sure you want to permanently delete the files in directory     | 
|"/home/someuser/.mozilla/blah"?                                         |
|                                                                        |
|            [ Delete ]       [[ Don't delete ]]                         |
+------------------------------------------------------------------------+

Comment 14

[Brian 'netdragon' Bober]

I just realized that message in comment #13 should come up as soon as the user
checks the checkbox.

Conrad: 
http://bugzilla.mozilla.org/attachment.cgi?id=45773&action=view
I think you should be able to reuse a profile removed from the profile list if
you don't delete the files. That's a different issue though.

Is it obvious enough the files will remain on the disk and take up space if the
user doesn't check the checkbox?

Comment 15

[Brian 'netdragon' Bober]

Erm.. sorry if I sounded ambigious. If the user chose "Don't delete files", the
checkbox would remain unchecked if it pops up on a mousedown event. Otherwise,
it would be checked if the user chose "Delete files". They would still have to
choose "Delete Profile" in the original dialog (attachment 45773 [details]) before
anything happened.

There is no cancel on the dialog mentioned in comment #13 because that would
infer "cancel profile creation" which is already on the dialog for attachment 45773 [details].

Comment 16

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 17

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 18

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 19

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 20

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 21

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 22

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 23

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420