Closed Bug 60668 Opened 24 years ago Closed 24 years ago

Mail won't automatically download new messages at start up.

Categories

(SeaMonkey :: MailNews: Message Display, defect, P2)

x86
Windows 98
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.8

People

(Reporter: w4azj, Assigned: racham)

References

Details

(Whiteboard: [nsbeta1+])

Attachments

(6 files)

I have the account configured to automatically check for new messages every 10
minutes, and download them if new ones are found.  This part works fine.
However, it never checks at startup.  It waits 10 minutes, then checks.

Work around is to manually hit the retrieve button, but I'm lazy and would
rather have it grab the new messages when I fire the program up.  NS, IE, and
Eudora (if memory serves) behaves this way...shouldn't Moz?? :-)
This behavior occurs in Moz nightly build 2000111404.
Yeah, I see this too in the 20001117 nightly
Status: UNCONFIRMED → NEW
Ever confirmed: true
Are you using Pop?  Reassigning to sspitzer.
Assignee: putterman → sspitzer
Keywords: mail3
QA Contact: esther → laurel
mike mailed me and said it was with pop.
racham might be taking this one from me...
Taking this one from Seth..
Assignee: sspitzer → racham
Adding nsbeta1 keyword.
Status: NEW → ASSIGNED
Keywords: nsbeta1
QA Contact: laurel → fenella
marking nsbeta1+ and moving to mozilla0.8
Priority: P3 → P2
Whiteboard: [nsbeta1+]
Target Milestone: --- → mozilla0.8
I have an implementation where we can open the default account and start the
message downloading process. Even if the account is with closed twisty status,
the account is opened, inbox is selected and action to get new messages is
kicked off. Will post the patch in the next update.

Seth, beinvenu, please do r= and sr= for this one..

Seth, I know the bug 14301 you are working on has a realtion with this bug.
However, they can work together without having to make any major changes. I
guess in your implementaion, you simply make the account chosen by the user to
be the default one for the next session (stored in prefs, I guess). So, all this
bug needs to know is what is the default account as the messenger is fired up.
So, the flow is smooth.
Keywords: patch
> I guess in your implementaion...

I haven't implemented the "login at start up" part yet, just the ui and the
backend to allow a per server boolean pref for it.

let me review your patch now...
some comments:

there is no guarantee that the default account will be where you think it will
be in the tree.  (as you know, soon we are going to allow users to re-order the
servers in the folder pane.)

the right way to get the default server is to go through the account manager. 
we do it a few lines earlier in loadStartFolder().

it looks like loadStartFolder(uri) was written to find the default account and
select the inbox if uri not passed in.  On start up, I bet uri is not passed in.

you should fix your patch to piggy back on that work.

you should fix implement a js function that given a server (or account), opens
it up if it is not already open.

after you've ensured that it is open, the old code will work and we'll select
the inbox.

then you'll have to call your TriggerGetMessages(), which will make it so for
pop we actually get new messages.  (it happens for free on imap when we select
the folder.)

does that make sense?




looking at loadStartFolder(), we have:

	
var startFolder = document.getElementById(startFolderUri);
//if it's not here we will have to make sure it's open.
if(!startFolder)
{

}

I bet that when the twisty is closed, the inbox isn't in the dom.

You'd probably want to just do:

var startFolder = document.getElementById(startFolderUri);
//if it's not here we will have to make sure it's open.
if(!startFolder)
{
	OpenTwistyForServer(server);
	startFolder = document.getElementById(startFolderUri);
	// startFolder should not be null now.
}
Seth,

I agree with you. I need to search for the node that corresponds to the default
server. Updated patch coming soon. Your comments are welcome.
Attached patch updated patchSplinter Review
the new looks great.

on top your latest patch, can you:

1) initialize treeNode to null in GetTreeNodeForServerURI()
2) initialize server to null in loadStartFolder()
3) please test that after your patch that the right thing happens the first time
we launch mail on a new profile.  we should still land here:

"Exception in LoadStartFolder caused by no default account.  We know about
this\n"

since we have no default account

do all that, then r=sspitzer

nice job.
I just realized that loadStartFolder() gets called whenever we open a new
3-pane, not just on start up.

this affects my fix for #14301, too.

I'm pretty sure you change it so we only call TriggerGetMessages() if the passed
in variable startFolderUri was null, we'll only call it on start up.

In my local tree, I've applied your patch, made this change, made the changes I
suggested on 2000-12-23 13:02, and added my fix for #14301.

I'll attach it for you to review.
sr=bienvenu
was this checked in?
There are couple of more issues that need to be sorted with bug 14301 ("Log into
this account at startup" doesn't work) and submit the patch that can fix both at
once. Expecting to ge done with this one today.
All current issues related to Login at startup are also resolved (issues realted
bug 14301).

* At startup, login into all accounts which have checkbox "Log onto this account
at startup" turned on.

* All new accounts created after this fix goes in will not have this checkbox
turned 'on' by default.

Will post patches related to these bugs (60668 and 14301) soon.
In the prefs patch, please ignore accountcentral related patch..(i.e., pref
mailnews.account_central_page.url
)

Seth, Scott/Bienvenu,

Will you please review and sr these patches? thanks.

bhuvan
looks good.  r=sspitzer

(I'm glad the default for that pref is "false", I'm sure we would have gotten a
lot of hate mail over that.)
We download messages for default account now always. In addition with fix for
bug 14301, we also download messages for all other accounts chosen to login at
startup.

If the default accountis collapsed, we open the twisty, select the Inbox and
download messages facilitating user directly jump on reading his mail.

Fixed. Thanks for reviews. 
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Linux (2001-01-29-08 mtrunk)
Win32 (2001-01-29-06 mtrunk)
Mac(2001-01-29-09 mtrunk)
This problem is fixed.
Status: RESOLVED → VERIFIED
It doesn't work in build from package mozilla-win32.zip dated January 30 at 23:48.
I'm using Windows 2000 SP1 on PC.
It works again in build 2001013104.
Could this fix be causing bug 68014?
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: