45041 - clean up text of alert dialog when user does "New Folder" with duplicate name

Status: RESOLVED WORKSFORME

(SeaMonkey :: MailNews: Message Display, defect)

Description

[jglick]

This was originally part of bug #44104, which was marked as future. This bug 
requests that the text on the alert dialog be changed. Putterman requested I 
file a new bug instead of modifying bug #44104.

Creating a new folder with a duplicate name. Alert dialog appears with text, 
"The current command did not success. The mail server responded:Mailbox already 
exists (box symbol)." 

If possible, change the text of this alert so it is a bit less techy. Text of 
alert should read: "A folder with that name already exists.".

Comment 1

[jglick]

Nominate as nsbeta3. Priority 3.

Comment 2

[scottputterman]

mail triage marking [nsbeta3-]

Comment 3

[jglick]

Add mail3 keyword so bug considered for 6.5

Comment 4

[scottputterman]

reassigning to sspitzer

Comment 5

[Fabian Guisset]

Can anyone point me to the file in which the alert is called? I can't seem to
find it.
Fabian.

Comment 6

[scottputterman]

marking nsbeta1+ and moving to mozilla0.8

Comment 7

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

"The current command did not success. The mail server responded:Mailbox already 
exists

yikes, that is not good.

Someone has fixed the "success" typo.  see
mozilla/mailnews/imap/resources/locale/en-US/imapMsgs.properties

so now we have:

"The current command did not succeed. The mail server responded:Mailbox already
exists (box symbol)."

I don't think we are going to able to turn this alert text into. "A folder with
that name already exists."  We don't know what type of error we have.  all we
know is that the server reported an error.

see nsImapIncomingServer::FEAlertFromServer() which [eventually] gets called
from nsImapServerResponseParser::GetNextLineForParser().

what we can do is turn 

"The current command did not succeed. The mail server responded:Mailbox already
exists (box symbol)."

into

"The current command did not succeed. The mail server responded:  Mailbox
already exists."

(notice, spaces between ":" and "Mailbox".  and not "box symbol").

the box symbol thing seems unicode related...

re-assign to naving

Comment 8

[jglick]

"A folder with that name already exists" is the 4.x behavior.

>We don't know what type of error we have.  all we
>know is that the server reported an error.

If "The mail server responded:Mailbox already exists (box symbol)." is the error 
reported from the server, is it safe to assume the folder name already is being 
used?

Comment 9

[Matthew T (active 1999-2002)]

Why can't we, when the folder is created/renamed, look to see if a folder with 
that name exists on the server before sending the create/rename command? That 
way we can report a nice error (`A folder with the name "Junk" already exists. 
Please use a different name.'), instead of just parroting raw error text from 
the server. Server error text might not even be in the appropriate language. 
Sure it would take a bit longer, but creating/renaming folders isn't exactly a 
common occurrence, so speed should not be so much of an issue.

Comment 10

[scottputterman]

If we fix 44104, which we said we'd like to fix now that 6.0 is out, then isn't
this bug irrelevant.  It seems that 44104 is what mpt suggests anyway.

If we agree to that then we can just close this.

Comment 11

[Matthew T (active 1999-2002)]

I just thought of a complication ... We don't have offline IMAP yet, but when 
we do, what if we're offline when we create/rename the folder, so we don't 
discover that there was another (unsubscribed) folder with the same name until 
we go online again? In that case, the error alert will be rather unexpected.

Comment 12

[jglick]

Yes, if we fix 44104 this bug is taken care of.  

mpt, we could either:
1. throw up a dialog when the user goes back online and make them select a new 
name
2. quietly notice the conflict and rename the newer folder "<foldername>2". 
3. throw up a dialog when the user goes back online notifying them that a 
duplicate folder name was found and that the duplicate was renamed 
"<foldername>2".

Comment 13

[Navin Gupta]

I have checked in changes to the alert message as suggested by Seth. Since it 
seems unclear what we are finally going to do with the alert message I am 
not marking it fixed. 

Comment 14

[scottputterman]

I think this can also happen in the case where the user creates a new folder
before imap folders are discovered.  Does anyone have any idea how hard it will
be to resolve the conflict after discovery or going back online?  I imagine
searching for duplicates in the known list of folders wouldn't be too hard.

moving to mozilla0.9

Comment 15

[Matthew T (active 1999-2002)]

Putterman, that's what I was referring to in my 2001-01-04 comment.

Comment 16

[scottputterman]

marking nsbeta1- and moving to future milestone.

Comment 17

[James Green]

I don't easily have facilities to test this on imap/etc., can someone update
this and say what, if anything, is "wrong" here?

Comment 18

[jglick]

Currently when you attempt to create a new folder with a name that already 
exist, you get a dialog that says "The current command did not success. The mail 
server responded:Mailbox already exists." 

This bug is requesting that the text be changed to something more user friendly. 
"A folder with that name already exists. Please enter a different name".

Comment 19

[Navin Gupta]

As I said in that other bug, for imap the behavior will have to include 

"The server said..."

for local we already have 

"A folder with that name already exists". 

Do we want to change this to

"A folder with that name already exists. Please enter a different name".

Comment 20

[jglick]

Bug 44104, was the original bug that described the desired behavior and text for 
a duplicate folder. When that was not seen as doable, this bug was filed to just 
clean up the text of the error message.

I'd really liked to see this fixed as described (4.x parity). Its just a much 
better user experience to clearly explain to the user what went wrong and bring 
them back the New Folder dialog to allow them to fix the problem than to simply 
show a server generated error. 

If this just isn't technically feasible right now, I understand. But untimately, 
this should be fixed not just for Local folders, but for IMAP folders as well.

Comment 21

[Navin Gupta]

Have a fix for imap folders as well. 

Comment 22

[Navin Gupta]

Cleaned up alert of text but imap folders problem need to be solved separately. 
It is a matter of few lines but still needs to be done. not for now. 

Comment 23

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

mass re-assign.

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]

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 28

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

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

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

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

[Karsten Düsterloh]

This is WFM for non-IMAP. Delegating IMAP to bug 312703.