Using IMAP/ssl to a UOW imap server. today's build 20020513. Server Settings: |X| check for new mail at startup |X| Check for new messages every |1| minutes However, mail/news does *not* check at for new mail at startup. When I start mail/news nothing happens whatsoever. I have to click on INBOX before the connection is brought up. After that, everything works correctly.

More details: problem is independent of ssl. In order to reproduce it is essential to have close the folder sidebar before closing a previous mozilla instance. If the previous mozilla instance was exited with the folder sidebar open the startup check works correctly.

Are you using a branch or a trunk build?

This is using a local build of the CVS source from cvs-mirror.mozilla.org:/cvsroot. So trunk, I think.

Qa > esther

As of today's build, 20020516, the problem has almost gone. mozilla now checks for INBOX email at startup and brings up the connection. The only remaining issue is that the INBOX is not actually loaded as the current folder at startup, provided that mozilla was previously closed with the folder sidebar closed (and INBOX loaded). If "check for new mail at startup" is set, I would expect the previously loaded INBOX to be loaded again. No?

I am seeing something very similar in smoketesting when I create an account for testing (IMAP) The inbox shows a number of mail messages available but they aren't shown in the thread pane. Clicking another box, ie "sent", then clicking back on the Inbox reveals the messages in the thread pane. This also happened upon setting up an AOL mail account. Seen on windows commercial build 2002-05-17-04-trunk. Is this the kind of behavior this bug is referring to? If not, I'll log a new bug.

No, it's not, but I also occasionally see the exact behaviour you describe. Probably needs a new bug, though it's hard to reproduce. This bug is [now] describing the following: IMAP server set to check for new mail at startup. Close folder sidebar; restart mozilla Start mail/news - login/password prompt appears and a succesful login occurs but but INBOX is not loaded. If folder sidebar is not closed in previous mozilla instance problem does not occur. Happens on both Linux & Solaris. First appears in 20020513.

Confirmed broken behavior in 20020517 on linux. Seems like if you don't have the folder pane opened there is no default selection for folders so nothing gets loaded in the message header window. When i open the sidebar folder pane i see that the message count for the inbox is correctly updated, but is not selected. Someone who knows the code needs just to do if (sidebar visibility=0 && default folder=NULL) then default folder=1st mail server/INBOX

change qa contact ->huang

this has been working for a several days now. was there a fix checked in?

Still broken with our 20020610 build (Solaris/SPARC); behaviour as in my earlier comment 7.

I just downloaded todays commercial branch build(2002-06-10-08) Creating a new profile with imap account does not load inbox on startup. I saw this behavior on linux. Blank thread pane is not very user friendly.

nomintaing this for better user experience. With all default settings and logging into the account should display all the messages in the thread pane. This is not just UOW imap server. I saw this with my imap work account.

reassigning to cavin. We need to fix this for rtm.

bug 147896, a trunk-only, recently fixed bug, would cause something like this, so it might be confusing the issue a little.

Sheela, I just wanted to make sure you saw this on the branch. Can you reproduce this? What about on other platforms besides Linux?

I installed today's branch build on linux and saw this behavior. I will check this on mac and windows and will updated the bug. On linux I remember doing the following: Create a new profile Set up imap account At the log in prompt I cancelled and did not log into the account I went to account and settings I created one more account ( which is a pop account) I go back to 3 pane view Having 1st account which is imap inbox selected I click on get message button I am prompted to log in I successfully log in I see the message download status and headers are downloaded but not visible in the 3 pane. Just clicking on one of the folders and going back to inbox will show all the messages. I am not sure if this would reproduce the behavior. Let me check with mac and windows.

Yes it did reproduce the behavior. I was able to duplicate it on both mac as well as windows on today's branch builds. I followed the same steps that I have described in my comments#17. It is all platforms.

Yes, I am also seeing it w/ sheela's steps.

Karen and I just ran a few test cases and we saw that it is only after you dismiss the password dialog with the cancel button. This can be reproduced by just creating a single imap account in a new profile. And dismiss the password dialog by clicking cancel button. Then Click on Get message to get the password dialog again. Then log into the account you should see that the thread pane is blank. Note that if you log in with the password at the first prompt itself we do not see this problem.

Using branch build 06-10-08-1.0.0 build: Nail down the problem as following: Based on the original reporter's scenario, updating the summary to specify this problem: INBOX displays on the bottom and does not load headers at startup when closing the folder sidebar. I am thinking the inbox displays on the bottom is more critical to fix from this bug. The other issues are: 1) Does not load Headers at startup when closing the folder sidebar. 2) Does not load Headers at startup after dismiss password dialog.

Just some clarifications: > INBOX displays on the bottom > This happens when you re-open the folder pane sidebar. The INBOX folder icon should be at the top of the folder list. > 2) Does not load Headers at startup after dismiss password dialog. > This only happens to new accounts on new profiles, right? In other words, only when the msg headers in INBOX have never been downloaded.

2) Does not load Headers at startup after dismiss password dialog. >This only happens to new accounts on new profiles, right? In other words, only >when the msg headers in INBOX have never been downloaded. Yes. It occurs on a new profile. If you login and cancel from an existing profile, msg headers displays fine.

Same problems happen to POP, Webmail and AOL accounts.

I believe the following scenario has never worked before: "if the folder pane is collapsed/closed at startup (ie, it was closed from the previous session) then messages in INBOX of the default account should be loaded/displayed in the thread pane" After talking to bhuvan about the problem, we feel that it's a bit too risky to fix the problem at this stage of the release cycle. So, as a workaround solution, we'll make it so that if the folder pane is collapsed/closed at startup it'll be (forced) opened automatically (with a default width). In addition, thread pane window will list messages in the inbox of the default account. Showing messages in the thread pane window under this scenario should resolve some of the reported bugs that have statements like "not being able to see any messages at startup", "when I launched mail for the first time I was able to see the messages but the message list was empty when I launched mail the second time", etc. Ccing jglick for the workaround solution.

Added function ForceFolderPaneOpen() to open folder pane if it's already collapsed. I had to delay the call to SortFolderPane() in loadStartFolder(), rather than in OnLoadFolderPane(), when folder pane was collapsed at startup because the call failed in OnLoadFolderPane() due to the 'view' in the tree body frame was still null at that point. Calling SortFolderPane() at the time we load the start folder seems to fix the problem of "INBOX is being displayed at the bottom of the folder pane when the folder pane is opened". This delay call has no impact on the case where the folder pane is already opened at startup.

Sounds like an acceptable work around.

Comment on attachment 87609 [details] [diff] [review] Proposed fix, v1 Have you tried using SetTimeout("SortFolderPane("..")", 0), it may work, then you would not need that global var.

Problem described by comment #17 is a different problem from the original one (ie, not caused by having the folder pane closed at startup) so Sheela can you file a separate bug to address it? Thanks.

No, setTimeout("SortFolderPane(folderNameCol);", 0) doesn't seem to fix the folder sorting problem.

OK it works as I should have used the single quote for the function parameter in the call like the following: setTimeout("SortFolderPane('folderNameCol');", 0); However, in case the folder pane is open at startup (ie, normal case) you'll see the folder pane list refreshes itself (ie, unsorted folder list followed by a sorted list) if setTimeout() call is used. The list does not refresh itself if SortFolderPane() call is used. So I think I'll call both functions depending on whether or not the folder pane is closed at startup. Good suggestion as we can remove this global var. I'll post a new patch.

If folder pane is closed at startup then use the followig call: setTimeout("SortFolderPane('folderNameCol');", 0); Otherwise, use the existing call (ie, no change).

Comment on attachment 88025 [details] [diff] [review] Remove global var. r=naving, thx cavin.

Comment on attachment 88025 [details] [diff] [review] Remove global var. sr=mscott

Let's land this on the branch.

Due to the removal of js function SortFolderPane() by bug 123719 in the trunk, I'll have remove the call to SortFolderPane() in my patch. The new patch works better in that if the folder pane is collapsed at startup the folder list no longer refreshes itself (I think this is fixed by bug 123719). I'll post another patch and carry over r= and sr= from the last patch since not much change has been made. I think bug 123719 has not been posted to the branch so we'll need the last patch for the branch.

Comment on attachment 88209 [details] [diff] [review] Remove SortFolderPane() call. Carry over r=naving, sr=mscott.

Fix checked into the trunk.

Bug 123719 contains all you need to know to fix this bug. Reopening so I can mark this as duplicate. Also, the hack you checked in should be backed out.

*** This bug has been marked as a duplicate of 123719 ***

Oh, and it doesn't look like you tested the alternate 3-pane layout, did you?

this was resolved as a dupe. removing adt1.0.1 nomination.

I don't think the following problem is addressed by bug 123719 at least from the tests I did: "if the folder pane is collapsed/closed at startup (ie, it was closed from the previous session) then messages in INBOX of the default account should be loaded/displayed in the thread pane" This is what the patch was trying to fix. So I'm reopening the bug.

Marking adt1.0.1 and FIXED.

Bug 123719 was checked in on 06/20 and my tree is a few days older than that so I'll get a new tree and see how the patch works.

With the new tree, patch of bug 123719 without my patch does fix the original problem of this bug, so reopening it and marking a dup of bug 123719.

*** This bug has been marked as a duplicate of 123719 ***

Need to back out the last patch.

Backing out the last patch should fix bug 153220.

Verified: original problem report symptoms not now in trunk.