20607 - [dogfood] can't see new msgs in inbox, but can see other folders

Status: VERIFIED FIXED

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

Description

[daver]

On yesterday's and today's build I launch mail, select inbox and nothing
happens.  I have the tree control with all the folders.  I expect that when I
select inbox I'd get the prompt for my password.  But I don't.  If I select any
other folder I get my password prompt and can see that folder but I still can't
see my inbox contents.

I think Cindy Roberts reported this a few days ago so it could be dup.  JAR says
it's related to instant messenger, turn off IM and you can see your inbox.  I
tried this yesterday but that didn't work for me.

Comment 1

[lchiang]

Cindy's bug is http://bugzilla.mozilla.org/show_bug.cgi?id=20514.

Comment 2

[Phil Peterson]

Dave, you're using IMAP, right? Cindy's bug is bug 20514 and she's using POP

Comment 3

[daver]

Yes IMAP

Comment 4

[Phil Peterson]

David, can you take a look at this? cc jefft in case he has any ideas

Comment 5

[David :Bienvenu]

accepting - no clue yet, though.

Comment 6

[leger]

Putting on PDT+ radar.

Comment 7

[David :Bienvenu]

Scott P and I tracked this down to the fact that the m_server member variable
does not seem to be set for the Inbox nsMsgFolder. This also causes the Get New
Msgs crash that is climbing up the full circle charts, and that Dave sees.

I tried using Dave's prefs.js on my machine and did not see this problem (though
I couldn't get authenticated against the imap server because Dave was gone). It
might be interesting to run a debug build remotely from Dave's machine.

I won't be in tomorrow, so I won't make any progress on this unless I can
reproduce the bug.

Comment 8

[daver]

I can run a debug build on my machine tomorrow.  I could even pull the latest
stuff and doing a build.  Should I plan on it?

Comment 9

[jefft]

I'll be in the office tomorrow. I can take a look on Dave's machine.

Comment 10

[David :Bienvenu]

If you can run a debug build, I think we can nail this pretty quickly. We can
either do it over the phone, or Scott P can help (Jeff, we have several theories
already about this, revolving around the idea that m_server isn't getting set
for some reason).

in mailnews/base/util/nsMsgFolder.cpp

nsMsgFolder::Init(const char* aURI)

we suspect that we're returning out of here before m_server is getting set. My
guess is tha FindServer is failing.

Comment 11

[David :Bienvenu]

If Scott doesn't nail this today, I'll work on it Monday.

Comment 12

[scottputterman]

Adding hyatt and waterson to the cc list.

Here is what is going on and what we are going to do about it, plus some
questions.

Currently we use persist on folders to save threading state.  This means it gets
saved in localstore.rdf.  Currently, localstore.rdf appears to get loaded before
a xul file is read in.  When the profile manager or profile picker is shown,
localstore.rdf is read in and the folders that were saved off are created.  When
this happens, finding the server for the folder fails since we can't load the
account manager due to the fact that preferences haven't been loaded yet.  Then
when we try to access this folder later on we fail because there's no server.
That's the reason for this bug.

Alec is going to make it so that the server can be found later on even if it
isn't found in init.

However, that won't get rid of the assertions we are going to see at startup.
Also, this won't even be an issue once I do resource delegation, but that won't
happen until M13.

Here's what I'm wondering?  How can localstore.rdf be loaded before a profile is
read in?  Currently the code seems to use the localstore.rdf of the last profile
used.  That seems wrong to me. I'd think that we wouldn't use any profile's
localstore.rdf at this point. Any thoughts?

Finally, this is a different bug, but I'm seeing multiple entries in
localstore.rdf:

<NC:persist
resource="news://[e-mail]/netscape.public.mozilla.mail-news"/>

<NC:persist resource="mailbox://[e-mail]/Inbox"/>

<NC:persist resource="mailbox://[e-mail]/Trash"/>

<NC:persist resource="imap://[e-mail]/RDF"/>
    <NC:persist
resource="chrome://messenger/content/#sidebar-panels"/>
    <NC:persist
resource="chrome://messenger/content/#sidebar-splitter"/>
    <NC:persist
resource="chrome://messenger/content/#messengerWindow"/>
    <NC:persist
resource="chrome://messenger/content/#title-box"/>
    <NC:persist
resource="chrome://messenger/content/#SubjectColumn"/>
    <NC:persist
resource="chrome://messenger/content/#AuthorColumn"/>
    <NC:persist
resource="chrome://messenger/content/#DateColumn"/>
    <NC:persist
resource="chrome://messenger/content/#PriorityColumn"/>
    <NC:persist
resource="chrome://messenger/content/#StatusColumn"/>
    <NC:persist
resource="chrome://messenger/content/#SizeColumn"/>
    <NC:persist
resource="chrome://messenger/content/#UnreadColumn"/>
    <NC:persist
resource="chrome://messenger/content/#TotalColumn"/>
    <NC:persist
resource="imap://[e-mail]/INBOX"/>
    <NC:persist
resource="chrome://messenger/content/#gray_horizontal_splitter"/>

Comment 13

[Chris Waterson]

Yeah, the dups entries are 16516. I'm not real sure why we're loading
localstore.rdf before we get a profile. That seems like a bug in the code that
retrieves the current profile. It used to be the case that the localstore would
just bail before the profile directory was found. I imagine I could be using
the wrong nsSpecialSystemFileSpec API there.

Comment 14

[Alec Flett]

it's actually the in the appshell code... basically the localstore50 directory
gets translated into the currentprofile directory, which gets translated into
the "first profile" directory, since no profile has been selected.
it's a mystery in an enigma... (oooooh, aaaahh, goes the crowd)

But really in one of those steps we should return an error.

Comment 15

[David Hyatt]

The chrome registry does this profile dir checking, and it knows how to bail.
Look at CheckForProfileFile in nsChromeRegistry.cpp... it's in rdf/chrome/src

Comment 16

[David :Bienvenu]

fixed checked in by alecf, verified by daver, with lots of help from scottip.

Comment 17

[lchiang]

Scott says that if you have more than one profile and in one of those profiles,
you sort by thread, you will see a problem upon restart.

We'll verify this on 12/7.

Comment 18

[esther]

Using the 12/06 builds I tried the scenario listed above in comment 12/06 on
win98 I could reproduce the problem, but on mac I didn't and on linux with
builds 12/05 and later, my system is having problems when I have 2 profiles so I
can't tell if this scenario reproduces the problem on linux.   On 12/07 I will
verify the fix with the win32 12/07 build.

Comment 19

[esther]

Using build 1999120712m12 on win98 I get my password and see my msgs in the
thread pane of my 1st IMAP account, when my 2nd IMAP account INBOX is sorted by
Thread.   I believe this is the scenario to test this.  I will verify this,
however, I did run into another bug (so far only reproducible on my system)=the
first time you open the IMAP account that is not sorted by thread after viewing
the other IMAP account that is sorted by thread I will crash after the messages
are downloaded.  Launching again does not crash, I will investigate more and log
a bug if I can reproduce that on another system.   Verified