374638 - trash_folder_name doesn't work

Status: RESOLVED FIXED

(MailNews Core :: Networking: IMAP, defect)

Description

[Michael Jahn]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2
Build Identifier: 1.5.0.10 (20070221)

I have two accounts at the same provider which has a custom trash folder name. 
I've set the folder names like this in prefs.js

user_pref("mail.server.server1.trash_folder_name", "Papierkorb");
user_pref("mail.server.server2.trash_folder_name", "Papierkorb");

This only seems to work for the first account, although all other settings seem to be the same. A folder named "trash" is still created for account 2.


Reproducible: Always




Confirmed under Linux + Windows.

Comment 1

[james davis]

version 3.0a1 (20070514)

I'm seeing this - sort of. My imap account that used to used "Deleted Items" (exchange yuck) doesn't use the prefs.js entry anymore - it is using "Trash"
no matter what.

For my server4 - imap:
user_pref("mail.server.server4.trash_folder_name", "Deleted Items");

But the account properties - server settings - say move to "Trash".
I can attempt to change it to "Deleted Items" and save but reopening the server
settings shows "Trash" again... The prefs.js has the change but the running
app ignores it and uses "Trash". This regressed sometime in the last few months
(it worked when I was moved to imap/exchange and changed the trash folder
to "deleted items"). Not sure when yet - I guess I need to try some old
releases.

I'm going to confirm this bug (at least for Windows).

Comment 2

[james davis]

I'm also going to change the version to trunk - that's where I see this regression.

Comment 3

[Jürgen 'JiHa' Harter]

I see this on my SeaMonkey-Suiterunner build (self compiled)
Build identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a6pre) Gecko/2007060301 Mnenhy/0.7.5.0 SeaMonkey/2.0a1pre

Actually my first server is for local folders where I didn't set the pref. I set it for server2 and server3 where the pref does not work.

Comment 4

[Matt Klich]

I also see this problem in the 3.0a1 official build (not self-compiled).

I was successfully using the prefs.js file in previous versions to force the deleted mail to go to the Exchange "Deleted Items" folder. Since I upgraded to the alpha build this no longer works. I have tried deleting the pref, restarting Thunderbird, re-setting the pref in about:config, restarting again. The pref will show up in my prefs.js file but it is not obeyed.

What I'm running:
OpenSuse 10.2
Thunderbird version 3.0a1pre (20070626)

Comment 5

[Wayne Mery (:wsmwk)]

Michael did this happen for you in TB 1.5 20070221? And did it work prior to 20070221?

Can someone determine when this regressed  and give a date range using older nightlies?
  http://archive.mozilla.org/pub/thunderbird/nightly/

ref: bug 24064

Comment 6

[Steffen Wilberg]

This is a trunk-only regression.

WORKS:
2007-05-08-03-trunk
2007-05-09-06-trunk

BROKEN:
2007-05-10-03-trunk
2007-05-12-03-trunk

Regression range: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=mozilla%2Fmail%2Cmozilla%2Fmailnews&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-05-09+06%3A00&maxdate=2007-05-10+03%3A59&cvsroot=%2Fcvsroot

So bug 379070 is the culprit.

Comment 7

[Michael Jahn]

Hi,

I just installed Thunderbird 2.0 (Version 2.0.0.4 - 20070604), erasing all previous data from a thunderbird installation. This version does not exhibit this problem here, but I don't know whether this is due to the fresh install or version 2.0. The previos version installed was 1.5 but I do not know the build number.

Comment 8

[Wayne Mery (:wsmwk)]

(In reply to comment #7)
> I just installed Thunderbird 2.0 (Version 2.0.0.4 - 20070604), erasing all
> previous data from a thunderbird installation. This version does not exhibit
> this problem here, but I don't know whether this is due to the fresh install or
> version 2.0. The previous version installed was 1.5 but I do not know the build
> number.

Since Michaels non-regression branch problem is gone for him and he may not be able to recreate it, it wont be so rude to continue on the new life this bug took (but its generally not a good idea to morph someone else's problem to a different one) ... unless James installs a build prior to 2007-05-09-06 and still sees the problem.

Comment 9

[Steffen Wilberg]

This prevents me from dogfooding trunk builds.

Comment 10

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #0)
> I have two accounts at the same provider which has a custom trash folder name. 
> I've set the folder names like this in prefs.js
> user_pref("mail.server.server1.trash_folder_name", "Papierkorb");
> user_pref("mail.server.server2.trash_folder_name", "Papierkorb");
> 
> This only seems to work for the first account, although all other settings seem
> to be the same. A folder named "trash" is still created for account 2.

As Jürgen 'JiHa' Harter says in Comment #3, pseudo account of "Local Folders" is internally created upon first account definition by user, and it uses account1/server1 usually when account is defined via UI and if user doesn't modify prefs.js manually.
Following definitions usually, when 2 account are defined cleanly via UI :
  Local Folders           : account1/server1/no identity
    mail.accountmanager.localfoldersserver = server1
    no mail.account.account1.identities for account1
  User defined Account #1 : account2/server2/id1
  User defined Account #2 : account3/server3/id2

To Michael Jahn(the bug opener):

Did you correctly define trash_folder_name for IMAP accounts when Comment #0?
(server1 was for "Local Folders" when Comment #0, wasn't it?)
You did define trash_folder_name correctly with fresh profile when Comment #7, didn't you?

(Off-Topic)
Because no identity for account1="Local Folders", server no.=account no. but id no.=account no.-1 usually, if no multiple identities for an account is used.
I hate this mismatch and waste of the first valuable account1/server1 by "Local Folders". So I usually do next;
 1. Define a dummy POP3 account (account2) with proper SMTP server
 2. Change number of "Local Folders" to 666, The OMEN (account666/server666)
    (because only one account at this step, modification is not so hard work)
 3. Delete dummy POP3 account, and delete directory for it
 4. Start account definition => Tb starts to define from account1/server1/id1

Comment 11

[Magnus Melin [:mkmelin]]

Updating summary, currently it shouldn't work for any accounts.

Comment 12

[Magnus Melin [:mkmelin]]

Attachment: proposed fix

Use the pref value if we had one:)

Comment 13

[Scott MacGregor]

Comment on attachment 284501 [details] [diff] [review]
proposed fix

looks ok to me, but let's double check with David.

Comment 14

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #11)
> Updating summary, currently it shouldn't work for any accounts.

Oh, you looks to have changed INVALID original bug report(report on 1.5 and 2.0) to report of similar explanation of phenomenon but different problem on trunk, which was found by all other comment posters except original bug opener... 

Comment 15

[David :Bienvenu]

Comment on attachment 284501 [details] [diff] [review]
proposed fix

d'uh, thx for the fix/patch!

Comment 16

[Magnus Melin [:mkmelin]]

I don't know what the 1.5/2.0 issues were, but I verified it works fine on trunk for several account with this patch. On the other hand, it wouldn't ever get fixed for 1.5 at this point, and the 2.0 was reported WFM AFAICT.

Checking in mailnews/imap/src/nsImapIncomingServer.cpp;
/cvsroot/mozilla/mailnews/imap/src/nsImapIncomingServer.cpp,v  <--  nsImapIncomingServer.cpp
new revision: 1.371; previous revision: 1.370
done

->FIXED

Comment 17

[[e-mail]]

This was a regression from bug 379070; GetUnicodeValue never fails, explaining the behaviour you were seeing. I had looked through those patches, but there were too many and I gave up, so I don't know whether I'd looked at that one or not.

Nit: else after return is bad style.

Comment 18

[Magnus Melin [:mkmelin]]

Attachment: fix the "else" nit

Comment 19

[David :Bienvenu]

Comment on attachment 284667 [details] [diff] [review]
fix the "else" nit

right, thx.

Comment 20

[[e-mail]]

Comment on attachment 284667 [details] [diff] [review]
fix the "else" nit

Bah, that'll teach me to nitpick... I'd better not mention AssignLiteral then :-P

Comment 21

[David :Bienvenu]

Comment on attachment 284667 [details] [diff] [review]
fix the "else" nit

did I plus the wrong one? oh well...

Comment 22

[WADA:World Anti-bad-Duping Agency]

(Off-Topic)
(In reply to comment #16)
> I don't know what the 1.5/2.0 issues were,
If server2.trash_folder_name(==First account user defined) is set but server3.trash_folder_name(==Second account user defined) is not set, folder name change via trash_folder_name works for "First account"(==server2) only. I believe this is true even after your patch on trunk :-)

Comment 23

[Magnus Melin [:mkmelin]]

Checking in mailnews/imap/src/nsImapIncomingServer.cpp;
/cvsroot/mozilla/mailnews/imap/src/nsImapIncomingServer.cpp,v  <--  nsImapIncomingServer.cpp
new revision: 1.372; previous revision: 1.371
done

Comment 24

[Magnus Melin [:mkmelin]]

(In reply to comment #22)
WADA: if the trash_folder_name isn't set for server3, I don't see how it would "work" either. Anyway, if you can reproduce a problem with it, file a new bug.

Comment 25

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #24)
> WADA: if the trash_folder_name isn't set for server3, I don't see how it would
> "work" either. Anyway, if you can reproduce a problem with it, file a new bug.
Magnus, Comment #0(and initial bug summary before you changed) is apparently the report of it.

Comment 26

[WADA:World Anti-bad-Duping Agency]

(Off-Topic)
To Magnus: 

Please read comment #0 again, and read comment #8 also.
 (comment #0) 
  server1.trash_folder_name : set <= Local Folders, unless altered manually 
  server2.trash_folder_name : set <= Usually First Account (which user defined)
  server3.trash_folder_name : bug opener never refer to this entry
                              (Usually Second Account user defined)
I think phenomena of comment #0 and comment #1 is:
 Phenomenon of comment #0 : (initial bug summary and explanation by comment #0)
  server2.trash_folder_name(=First Account) works, because it is set,
  server3.trash_folder_name(=Second Account) doesn't work, because it isn't set
 Phenomenon of comment #1 : 
  serverN.trash_folder_name is set properly, but doesn't work on trunk
Is it wrong?

I absolutely agreed with Wayne Mery on her(his?) Comment #8, and I tried to close this bug as INVALID after getting answer to comment #10 from bug opener, in order to open separate bug for problem on trunk found by comment #1 and other comments, in order to avoid confusions, in order to do correct bug processing, but...

Comment 27

[Magnus Melin [:mkmelin]]

Yeah, this probably got hijacked... Might have been a problem in 1.5 but we create  Trash and Junk lazily in 2.0 and up iirc.

Comment 28

[Michael Jahn]

Sorry for the late answer, I'm quite busy at the moment.

To comment #10:

I did define trash_folder_name correctly with original bug report (comment #0) and correctly defined it again with new install (2.0) in commit #7. I'm 100% sure that it was correctly defined in comment #0, I rechecked it a couple of times before submitting this bug and also tried to copy and paste,  but it would only work with the first user-defined account in Thunderbird 1.5. 

To all: 

I cannot reproduce my original problem with Thunderbird 2.0, as it WFM on all installations of Thunderbird 2.0 . I had the problem that trash_folder_name worked very well for the first user-defined account but did not work for the second user-defined account, even though they were both properly defined. If you have further questions, do not hesitate to ask although it Works For Me now. 

Comment 29

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #28)
> I did define trash_folder_name correctly with original bug report (comment #0)

In your comment #0, you said next (1 & 2).
> user_pref("mail.server.server1.trash_folder_name", "Papierkorb");
> user_pref("mail.server.server2.trash_folder_name", "Papierkorb");

Michael Jahn:(bug opener):
"You did NOT define as follows(2 & 3) when comment #0." 
Is it right?
> user_pref("mail.server.server2.trash_folder_name", "Papierkorb");
> user_pref("mail.server.server3.trash_folder_name", "Papierkorb");
Did you manually alter server number assignment for "Local Folders" account in prefs.js when Comment #0?

Comment 30

[Michael Jahn]

(In reply to comment #29)

> In your comment #0, you said next (1 & 2).
> > user_pref("mail.server.server1.trash_folder_name", "Papierkorb");
> > user_pref("mail.server.server2.trash_folder_name", "Papierkorb");
> 
> Michael Jahn:(bug opener):
> "You did NOT define as follows(2 & 3) when comment #0." 
> Is it right?
> > user_pref("mail.server.server2.trash_folder_name", "Papierkorb");
> > user_pref("mail.server.server3.trash_folder_name", "Papierkorb");
> Did you manually alter server number assignment for "Local Folders" account in
> prefs.js when Comment #0?
> 

I'm pretty confident, that I did not manually alter the number assignment for the "Local Folders" account. I wouldn't make sense for me to do that, however I am not 100% sure. So it might have been account #2 and #3 (contrary to comment #0).

Comment 31

[WADA:World Anti-bad-Duping Agency]

To Michael Jahn:(bug opener):

Question about your Comment #7 on 2007-07-22 for status with Tb 2.0.
You say no problem when TB 2.0, with new installation/profile/definition.
What user_pref("mail.server.serverN.trash_folder_name", "Papierkorb"); are currently defined in your prefs.js with which problem doesn't occur?
 1. Tools/Options/Advanced/Config editor
 2. Type "trash_folder_name" in filter field

Comment 32

[Michael Jahn]

(In reply to comment #31)

> You say no problem when TB 2.0, with new installation/profile/definition.
> What user_pref("mail.server.serverN.trash_folder_name", "Papierkorb"); are
> currently defined in your prefs.js with which problem doesn't occur?
>  1. Tools/Options/Advanced/Config editor
>  2. Type "trash_folder_name" in filter field

N = 2 and N = 5 on first PC.
N = 2 and N = 3 on second PC. 

Comment 33

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #32)
> user_pref("mail.server.serverN.trash_folder_name", "Papierkorb");
>  N = 1 and N = 2              (your comment #0, with Tb 1.5)
>  N = 2 and N = 5 on first  PC (your comment #32, with Tb 2.0, no problem)
>  N = 2 and N = 3 on second PC (your comment #32, with Tb 2.0, no problem) 
And, you say you never changed server number assignment for "Local Folders".

I believe you put your settings in comment #0 correctly(no typo) when you wrote comment #0. So I believe my guess of comment #10 is right. i.e. Comment #0 is INVALID bug report. You had to set N=2 and N=3(or larger) with TB 1.5 when comment #0. And, you properly set when you transfered to Tb 2.0.