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

VERIFIED FIXED in mozilla0.8


MailNews: Message Display
17 years ago
13 years ago


(Reporter: Mike W., Assigned: racham)


Windows 98

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nsbeta1+])


(6 attachments)



17 years ago
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?? :-)

Comment 1

17 years ago
This behavior occurs in Moz nightly build 2000111404.

Comment 2

17 years ago
Yeah, I see this too in the 20001117 nightly
Ever confirmed: true

Comment 3

17 years ago
Are you using Pop?  Reassigning to sspitzer.
Assignee: putterman → sspitzer
Keywords: mail3


17 years ago
QA Contact: esther → laurel

Comment 4

17 years ago
mike mailed me and said it was with pop.
racham might be taking this one from me...

Comment 6

17 years ago
Taking this one from Seth..
Assignee: sspitzer → racham

Comment 7

17 years ago
Adding nsbeta1 keyword.
Keywords: nsbeta1


17 years ago
QA Contact: laurel → fenella

Comment 8

17 years ago
marking nsbeta1+ and moving to mozilla0.8
Priority: P3 → P2
Whiteboard: [nsbeta1+]
Target Milestone: --- → mozilla0.8

Comment 9

17 years ago
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.

Comment 10

17 years ago
Created attachment 21211 [details] [diff] [review]
patch to get messages automatically at startup


17 years ago
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.


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.
	startFolder = document.getElementById(startFolderUri);
	// startFolder should not be null now.

Comment 14

17 years ago

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.

Comment 15

17 years ago
Created attachment 21227 [details] [diff] [review]
updated patch
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

since we have no default account

do all that, then r=sspitzer

nice job.
Blocks: 14301
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.
Created attachment 21362 [details] [diff] [review]
a revised patch for this bug and #14301.  note, I'll be removing those dumps()
Created attachment 21363 [details] [diff] [review]
ignore that last patch, wrong patch.

Comment 20

17 years ago

Comment 21

17 years ago
was this checked in?

Comment 22

17 years ago
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.

Comment 23

17 years ago
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.

Comment 24

17 years ago
Created attachment 22927 [details] [diff] [review]
NEW patch for login and set focus on default account at startup...

Comment 25

17 years ago
Created attachment 22928 [details] [diff] [review]
prefs related patch

Comment 26

17 years ago
In the prefs patch, please ignore accountcentral related patch..(i.e., pref

Seth, Scott/Bienvenu,

Will you please review and sr these patches? thanks.

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.)

Comment 28

17 years ago
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

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. 
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 29

17 years ago
Linux (2001-01-29-08 mtrunk)
Win32 (2001-01-29-06 mtrunk)
Mac(2001-01-29-09 mtrunk)
This problem is fixed.

Comment 30

17 years ago
It doesn't work in build from package dated January 30 at 23:48.
I'm using Windows 2000 SP1 on PC.

Comment 31

17 years ago
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.