Closed Bug 108229 Opened 23 years ago Closed 23 years ago

Mail Prefs for Copies & Folders don't stick

Categories

(SeaMonkey :: MailNews: Account Configuration, defect, P1)

Product:
SeaMonkey
Component:
MailNews: Account Configuration
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.7

People

(Reporter: marina, Assigned: racham)

References

Details

Attachments

(4 files)

console output of debug build
28.28 KB, text/plain
Details
patch, v1 - return message folder as derived, folder creation happens on demand..
1.52 KB, patch
naving
: review+
Details | Diff | Splinter Review
patch, v2 - revised patch with a boolean added to getMsgFolderFromUri() to decide whether or not to check folder attributes
10.48 KB, patch
Details | Diff | Splinter Review
patch, v3 - GetMsgFolderFromUri() moved into widgetglue.js and patch reworked on that
14.76 KB, patch
sspitzer
: superreview+
Details | Diff | Splinter Review 
**** observed with 2001-11-01 trunk build ***
Steps to reproduce:
- select a mail account;
- go to Edit|Mail/newsgroup account settings;
- select Copies and Folders;
- change settings for Drafts and Templates to be hold on Local;
- close the Prefs dlgbox;
- reopen it;
//note: the Drafts are reverted back to "Click to select a server" and
Templates's radio button is deselected and revert to "Click ..." as well ( it
doesn't happen on the Windows build)
-> MailNews
Assignee: sgehani → racham
Component: Preferences → Account Manager
Product: Browser → MailNews
QA Contact: sairuh → nbaca
Trunk build 2001-11-02-04: Mac 9.1

Can you try with the 11/2 build since I am unable to duplicate the problem. I've
tried in a:
- Migrated IMAP account
- Migrated POP account
- New profile, POP account
Ninoschka, i think what i am seeing is bug # 108198 (overriten prefs in prefs.js
by a bogus value). I'll keep an eye on this bug because i didn't see it
happening in Win build before we will solve it as a dup
This problem is still there in 2001110805 on Mac OS X.
This still happens with 0.9.6 build 2001111610 on Mac OS X. Start up with a new
profile, create an IMAP account, and then try to set the new account's Copies
and Folders settings.
bug# 108198 is verified as fixed, it turns out that this bug wasn't it dup ( and
i haven't seen it on Win to begin with...), so i beleive it deserves attention
since it still happens on MacOSX and Mac OS 9.1
I have downloaded the laetst mac trunk build from sweetlou (Build ID :
2001111908). All Copies&Folders prefs are sticking properly. I have Mac OS 9.0
(9.0.4 US).

I have created a new profile and also tried with an existing profile. It works
fine both these cases. 

Ninoschka, Can you try on MasOS X and update with your findings. If works fine
there also, I will close this as WFM.

Meanwhile, if anyone around can reproduce this, I want to come by and take a look.


thanks,
bhuvan.
Status: NEW → ASSIGNED
i am trying to retest this and in 2001-11-20 i am still seeing this with
2001-11-20 build on MacOS9.1: setting up two accounts (pop and imap and chosing
one of them to hold sent mail on the Sent folder for the other account,
close/reopen prefs are reverted)
bug 110998 and bug 110509 both report similar problems. I see this in the linux
and mac 0.9.6 branch builds. 
another one that looks like a dupe: bug 109365
I'm experiencing the very same problem with build 2001112009 on WinNT.
this is XP.
OS: Mac System 9.x → All
Hardware: PC → All
*** Bug 109688 has been marked as a duplicate of this bug. ***
*** Bug 111174 has been marked as a duplicate of this bug. ***
*** Bug 110998 has been marked as a duplicate of this bug. ***
*** Bug 109365 has been marked as a duplicate of this bug. ***
Removing 'Mac:' from summary. I see that may people reporting this problem even
with latest builds on all platforms. I will try to reproduce this on cuople of
this platforms (note: 11/19 build worked fine for me, but looks like many people
are still facing problems here.., so I will try with my updated builds again)
and then proceed further.
Summary: Mac: Mail Prefs for Copies & Folders don't stick → Mail Prefs for Copies & Folders don't stick
See http://bugzilla.mozilla.org/show_bug.cgi?id=110998 and
http://bugzilla.mozilla.org/show_bug.cgi?id=110938 may shed light on things.

Summary: A patch (which has been backed out in today's build) broke access to
local folders. If your mail prefences copied any mail to those local folders
during sending or recieving, you got errors, and in addition, mail preferences
cannot be saved.

Hope this helps.





I've just tested on WinMe 2001112104, and I can't change any folder settings. If
I try to change them in Mailprefs, they just revert to "select folder". Seems
the actual mechanism for changing the folder prefs is broken. You can switch to
an older build, change prefs and then they'll be correct in today's build - but
unchangable without breaking the settings.
Some see it and some don't. It's a mystery! Ninoschka and myself couldn't
reproduce this. We saw Asa reproduing this. So, it is there. We need to kill
this one. It's bad. If any of you have debug builds where you notice this
behavior, can you please attach the entire console output to this bug. On the
machines, where it is going wrong, we have noticed that there are couple of
other places where things are wrong like,  

* Default account is not selected for Templates group by default (instead shows
click to select an account)
* Clicking on Other makes the menulist to go blank (dropdown contains all valid
accounts though)

All these are probably tied. In either case, this panel needs to work on
everyone's machine.




An excellent way to reproduce this is as follows:

1. Use courier IMAP as the server
2. create a Sent, Drafts, and Templates directory (they end up being INBOX.Sent,
INBOX.Drafts, and INBOX.Templates)
3. All folders appear as subfolders of INBOX when using courier IMAP
4. Go to mailnews preferences to setup Sent, Drafts, and Templates folders on
the IMAP server
5. Choose Other since its the only way to properly choose these folders (with
this IMAP server)
6. Notice how nothing is being saved when clicking on OK in Account Settings
dialogue

I doubt this is a symptom of courier IMAP but this particular IMAP server forces
you to use the Other selection when choosing your folders.
with 0.9.6 WIn32 I was able to set something but there are quite a few problems:
The settings persist between two openings of the prefs only sometimes. When I
first click Copies&Folders they are displayed as empty (Click to select) but
after showing a news account prefs (which seem to work but not always) I
sometimes get parts of what I set up earlier. The fields also change when
switching Store on account and  Store in other folder.

It may be (at least partially) a refresh bug rather than a pref saving bug.
*** Bug 110509 has been marked as a duplicate of this bug. ***
Also cannot save outgoing server settings in Mail/News Prefs.  Can uncheck
username and password but after exiting and restarting box is still checked.  Am
using 0.9.6 Win32 on Windows 2000.
I cheated and took out the prefs file lines that specify where the folders. 
Restarted Mozilla end everything worked much better. - win 2000 - 
*** Bug 112374 has been marked as a duplicate of this bug. ***
I am at a stage where I could reproduce this for just first time Copies&Folders
settings check of a newly created account ( i.e., create a new imap account,
check Copies & Folders settings). If I close the app and bring it up again, I
don't see this again. So, I have to keep creating new accounts to hit the bug.
That's fine.

The error I got is the same as everyone else who has consistenly seen it.
msgFolder derived out of the imap URl of the Sent folder is 'null'. I guess RDF
resources seem to have not built by the time of query. So, someone changed some
underlying code recently and hence this bug. I am going to debug further to find
the exact location that is failing us. 

Getting this into the current milestone.
Target Milestone: --- → mozilla0.9.7
Keywords: nsbeta1+
Priority: -- → P1
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6+) Gecko/20011127

I renamed all prefs.js and liprefs.js I could find on my machine to see if
creating an account from scratch would allow me to change these preferences, but
now it won't remember any changes in the copies and folders pane.

Can anyone tell me the syntax of what needs coded into prefs.js to do a bcc to
my email address please?  I can't see where it is on my backup copies of the js
files (curious, I don't know how it worked before!)

If anyone can provide a URL for a document which describes the syntax of *all*
possible entries in prefs.js, I'd appreciate it.  All I can find is the
customizing page, and it doesn't list the ones I need.

Thanks!
Brian

Ah, after a search I found prefs for mailnews at
http://www.mozilla.org/mailnews/arch/accountmanager.html

I'll try coding in by hand and update here if they work.

Handcoding:

user_pref("mail.identity.id1.bcc_self", true);

into prefs.js worked for each account (adjusting id1 to id2 for the second
account etc) although the preferences gui doesn't show the email address
although the (unlabelled) tick box for 'bcc to self' is ticked.

I also noticed that the folder names for Drafts and Templates are wrong:

user_pref("mail.identity.id1.draft_folder", "imap://brianc@IMAPHOST/Drafts");

which seems to be set by default should be:

user_pref("mail.identity.id1.draft_folder", "imap://brianc@IMAPHOST/INBOX.Drafts");
(without the line break if one appears)

but that's probably another bug, though it shows up in the Copies and Folders
prefs dialog with Drafts folder on... unchecked and "click here to select an
account", but only as such on the first account, although saving a message to
the Draft folder works OK (after adding the INBOX. to the folder name) so it
would appear that the prefs dialogue is simply not displaying the prefs
correctly, and that may be why they're not saved correctly.

I hope this additional info is helpful.



I have a fix for this. This regression was result of Navin's checkin to make
filters work properly by ensuring the destination folder exists (bug 94968).
GetMsgFolderFromUri is being used by am-copies also to get the msg folder to be
displayed in the picker. Incase of new IMAP accounts those folders would not
exists  and they are created when user triggers action (like Sent folder getting
created when user sends a message & drafts when users saves a message as a
draft, etc). So, for that to happen, we needed to present that folder URI in the
picker even though they didn't exist (& are created on demand) [see bug 23625
for more details]. 

So, I have added a new routine (which simply returns the message folder) that
would serve copies&folders settings exclusively per it's unique requirement. 

Patch coming up...
Adding Navin & David for reviews.
seems like the name of the methods should indicate what's going on here so that
people won't get confused. GetMsgFolderFromUri will only get existing folders.
Your new method might be called something like
GetMsgFolderFromUriEvenIfFolderDoesntExist :-) Or at least add a comment to that
effect.
Comment on attachment 60350 [details] [diff] [review]
patch, v1 - return message folder as derived, folder creation happens on demand..

Changing the name would
be better than adding a
comment

r=naving
Attachment #60350 - Flags: review+
...I'd rather see us have just one, and have it take a boolean...that determines
what it will do.

Hi,

racham@netscape.com, sorry I kind of hijacked this bug with the inbox.drafts
thing.  I have to point out, however, that the Draft folder did exist, but not
where Moz expected it to be.  However, it is impossible to make it where Moz
wanted it to be because the IMAP server (Courier-imap) forbids folders at the
same level as inbox; they all have to be subfolders of inbox, hence the name has
to have 'INBOX.' prepended.  I'm not sure if this is the case for all imap
servers though.

Would the fix mean that the preferences in Copies & Folders would stick?


OK. Let us have one routine with boolean input param to decide what to return. I
will post a new patch modifying all those places that call GetMsgFolderFromUri().

Brain, we may have to handle the case you have mentioned in a separate bug. 
Done.  INBOX missing posted as bug
http://bugzilla.mozilla.org/show_bug.cgi?id=113525
I'd hate to include another js file into compose, as we've been trying to make
it as sleek as possible.

can you see if it makes more sense to put that function in widgetglue.js,
instead of mailcommands.js?

other than that, it looks good.  make sure to test well (all affected dialogs,
stand alone msg window, etc.)
*** Bug 113704 has been marked as a duplicate of this bug. ***
*** Bug 113576 has been marked as a duplicate of this bug. ***
I have tested all the cases where this routine is involved, viz.,

1. Open & set copies and folders settings for a given (imap) server
2. Launch account central and makesure all the links from there work as expected
3. Create a new folder checking the folderpicker effectiveness
4. Create mail (regular imap account & isp accounts like aol) and news
(news.mozilla.org) accounts
5. Subscribe to newsgroups on news.mozilla.org
6. Send/Receive messages
7. Open a standalone message window
8. Open filters and create a new filter and send mail to check the filter
functionality. Create new subfolder from within the new filter dialog.
9. Set preference that says 'Show when messages are saved' (in copies&folders)
and save a message as a draft and as a template.

and in every case, app works fine.
Comment on attachment 60926 [details] [diff] [review]
patch, v3 - GetMsgFolderFromUri() moved into widgetglue.js and patch reworked on that

sr=sspitzer

looks good and sounds like you tested thoroughly.
Attachment #60926 - Flags: superreview+
When will this be in the nightlies (or is it already?)

I'm experiencing other, new "prefs/mailprefs not saving settings" problems, and
wondered if it was related or if I should wait for this patch to go in before
reporting a bug
Fix checked in. Thanks for the reviews.

John, it is possible that problems with your copies and folders settings may
have been caused this bug. Should be OK tomorrow. As far as other settings
concerned, please look at bug 113682 and use the workaround suggested.

Marking fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6+) Gecko/20011209

Sorry, still not fixed.  Prefs do not show up correctly, and changes are still
not saved. :-(

Can you take another look at it please?

#51, I don't think the code was checked in when we all expected (got this from
reading various other related bug reports) and you are using a 09 Dec build. Try
again with todays 10th Dec build (its what I'll be doing later!) 
Brian, don't be so unpatient :-), you are using a build from before the fix has
been checked in. It would be a wonder if it was fixed in yours, otherwise please
retest tomorrow...
*** Bug 114452 has been marked as a duplicate of this bug. ***
*** Bug 114791 has been marked as a duplicate of this bug. ***
Trunk build 2002-01-28-03: WinMe
Trunk build 2002-01-28-08: Linux RH 7.1
Trunk build 2002-01-28-08: Mac 10.1
Verified Fixed.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: