44104 - Creating a new folder with a duplicate name behavior

Status: NEW

(SeaMonkey :: MailNews: General, defect)

Description

[jglick]

2000-06-28-09-M17

1. Select the default Inbox.
2. File|New|Folder. New Folder dialog opens.
3. Select default account.  Create new folder with the name of an existing 
folder.
4. click ok.
Results: Alert dialog appears with text, "The current command did not success. 
The mailserver responded:Mailbox already exists (box symbol)." Click the OK 
button, the alert goes away.

Expected results:
1. If possible, alert should appear on top of New Folder dialog.
2. Text of alert should read: "A folder with that name already exists.".
3. When the user clicks the OK button, focus should return to the New Folder 
dialog with focus in the name text edit field and the duplicate name highlighted 
so the user can start typing a new name immediately.

Comment 1

[scottputterman]

moving to future milestone.

Comment 2

[robinf]

Adding myself to cc: list.

Comment 3

[jglick]

Add mail3 keyword so bug is considered for 6.5.

Note: the proposed text change on this dialog was broken out into a sep bug 
45041 per putterman's request during version 6 work (thought we might be able to 
 get that part of the bug in for 6).

Comment 4

[scottputterman]

reassigning to sspitzer

Comment 5

[Fabian Guisset]

I can't reproduce this nor can I find where the alert is called from.
Anyone point me to the file? Or has this behavior been removed?
Fabian.

Comment 6

[jglick]

Just duplicated this with Windows RTM build.  

1. Select the default Inbox.
2. File|New|Folder. New Folder dialog opens.
3. Select default account.  Create new folder with the name of an existing 
folder.
4. click ok.
5. CLOSE EMAIL APP. (this step wasn't necessary before but seems to be necessary 
now).

Comment 7

[scottputterman]

marking nsbeta1+ and moving to mozilla0.8.  Let's see if we can tell that the
folder is a dup prior to exiting the dialog.

Comment 8

[Fabian Guisset]

I did :
1) Open mail
2) Select default Inbox
3) File | New | Folder
4) Select Default Account --> Can't, the dialog is modal
Please note the following : If I type the name of an already existing folder, I
get "A folder with that name already exists", and the modal dialog is no longer
modal (this is probably another modal bug), then I can do step 4
4) Select Default Account
5) Type in the name of an already existing folder
Results : "A folder with that name already exists"
Is this IMAP only (I'm using a POP3)? Did I do anything wrong? 

Comment 9

[scottputterman]

reassigning to naving

Comment 10

[scottputterman]

moving to mozilla0.9.  It look like this bug and 44104 are almost dups of each
other.

Comment 11

[scottputterman]

marking nsbeta1- and moving to future milestone.

Comment 12

[James Green]

I think this is fixed. huang: please test the various folder types (imap, pop3,
news, custom created, blah) and report if you didn't get the expected behaviour
(testing bug 45041 may be necessary).

Comment 13

[jglick]

I just tested this again today and this is still broken.

Alert dialog appears with the text, "The current command did not success. 
The mailserver responded:Mailbox already exists." Click OK on the dialog, it 
closes but the New Folder dialog does not re-appear. 

Expected results:
1. If possible, alert should appear on top of New Folder dialog.
2. Text of alert should read: "A folder with that name already exists. Please 
enter another name".
3. When the user clicks the OK button, focus should return to the New Folder 
dialog with focus in the name text edit field and the duplicate name highlighted 
so the user can start typing a new name immediately.

Comment 14

[jglick]

Using IMAP Mail.

Comment 15

[Navin Gupta]

IMAP behavior will be different from local because folder creation is 
asynchronous. we have to go to the server and then comeback and display 
server's response, in case we cannot create one. 

The new folder creation dialog is closed just before we ask the protocol object
to create a new folder. in short this behavior is ok, also there is no box
in the error msg. 

Comment 16

[scottputterman]

Is it possible to look at the folder list locally before going to the server?

Comment 17

[jglick]

Reopening. This was plused in triage, so I believe it was felt this was 
important to try and fix properly. Take a look at 4.x. With IMAP folders, it 
works the way I have described.

Comment 18

[Navin Gupta]

Is it possible to look at the folder list locally before going to the server?

I believe that is what 4x is doing.

Comment 19

[(not reading, please use [e-mail] instead)]

mass re-assign.

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]

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 24

[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 25

[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 26

[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 27

[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

Comment 28

[Karsten Düsterloh]

Folder creation still has issues, but not this one => WFM.

Comment 29

[Karsten Düsterloh]

Oops, wrong bug.

Creation of a folder with the same name provokes an error dialog for movemail/pop3/local, but fails silently(!) for IMAP.