98418 - outliner: migrating an existing profile or activating new mail account results in 2 inboxes when messenger is first started

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[grylchan]

commercial trunk builds 2001090408 on NT 4.0, linux 2.2, mac 9.1

I have seen this for awhile. Sometimes it isn't always reproducable.
I think this is an outliner problem. Tried querying but couldn't find
an existing bug and not sure it's a Mail front end or XP tookit
component problem.

steps to reproduce:
1.Convert an existing 4.x profile
2.Start messenger.
3.login
4.look at folder pane
results: Initially you see 2 inbox folders
         It will dissapear if you click the twisty (triangle by mail account)
         which results in folders not being displayed, then click the
         twisty again and you only see 1 inbox folder.
expected: only to see 1 inbox folder

Comment 1

[grylchan]

Attachment: screen shot of 2 inboxes on initial startup

Comment 2

[Håkan Waara]

*** Bug 98545 has been marked as a duplicate of this bug. ***

Comment 3

[Karen Huang]

This is also occurring on a new activated Webmail account, so problem is not 
only occurring on a migrating profile......update the summary a little bit.
Nominating nsbranch since users will not feel good for seeing this on UI folder 
pane.

Comment 4

[Scott MacGregor]

seeing 2 inboxes sounds bad. How common is this? Marking nsBranch- for right now
but if it's very common and resizing doesn't make it go away we'll have to
reconsider.

Comment 5

[grylchan]

Hey Scott.
Playing around with 9/12 commercial branch builds.

I saw the double inbox everytime i first logged into
a converted mail profile. You don't see it ever again
in subsequent logins.

If I create a brand new profile and when I first login
instead of seeing double inboxes, I don't see any inbox.
See attachment below. Clicking the twisty, corrects
this problem. Subsequent logins to the same account, I always
see the inbox.

I think the problem is when you first login to mail account
(either migrated/new) the twisty arrow starts off pointing 
down (\/) instead of sideways (>). I found with a new profile
before I click read mesg, when I am logging into the new mail
account for the first time, if I click the twisty to be sideways,
then read/login to mail account, I see inbox initially instead of
no inbox. This doesn't apply to converted profile as it automatically
starts with 2 inboxes as the twisty is pointing down.

Comment 6

[grylchan]

Attachment: screen shot of new mail profile with no inbox displayed on initial startup

Comment 7

[grega]

Do we want to reopen this one as nsbranch+?

Comment 8

[laurel]

*** Bug 101331 has been marked as a duplicate of this bug. ***

Comment 9

[scalkins]

Clearing for nsbranch re-consideration.
This occurs for all mail accounts migrated on a new install, or activated via
activation. It's a bad first experience for users.
I see this every day on new installs when I migrate my Imap accounts on a clean
install. 

Comment 10

[scalkins]

Attachment: SCreen shot on linux. I resized to see if it would clean up the two inboxes (no joy there) :-(

Comment 11

[scalkins]

I still see this on 
Win 2k  2001-10-01-05 0.9.4 Branch
Mac OSx 2001-10-01-04 0.9.4 (10.x)
Linux 2001-10-01-04 0.9.4 Brnch

Comment 12

[scalkins]

Attachment: Screen shot on my Win 2k box

Comment 13

[(not reading, please use [e-mail] instead)]

this is a dup of http://bugzilla.mozilla.org/show_bug.cgi?id=96853, I think.

I'll go investigate.

Comment 14

[(not reading, please use [e-mail] instead)]

fixed for me on the trunk.  I'll go try to figure out what landed on the trunk 
to fix this.

Comment 15

[(not reading, please use [e-mail] instead)]

*** Bug 96853 has been marked as a duplicate of this bug. ***

Comment 16

[Jaime Rodriguez, Jr.]

Thanks Seth. Once, you figure it out, let's see if we can get an ETA, and if it
should go into the branch.

Comment 17

[(not reading, please use [e-mail] instead)]

appears to have been fixed between 9-19 and 9-20, looking at checkins...

Comment 18

[(not reading, please use [e-mail] instead)]

hmm, I wonder if we assert twice in this scenario:

nsXULTemplateBuilder::OnAssert(nsXULTemplateBuilder * const 0x0378e62c, 
nsIRDFDataSource * 0x0378fc90, nsIRDFResource * 0x03f9fe70, nsIRDFResource * 
0x01201b00, nsIRDFNode * 0x03fd1510) line 554
CompositeDataSourceImpl::OnAssert(CompositeDataSourceImpl * const 0x0378fc94, 
nsIRDFDataSource * 0x03f99930, nsIRDFResource * 0x03f9fe70, nsIRDFResource * 
0x01201b00, nsIRDFNode * 0x03fd1510) line 1543
nsMsgRDFDataSource::assertEnumFunc(nsISupports * 0x0378fc94, void * 0x0012c500) 
line 400
nsSupportsArray::EnumerateForwards(nsSupportsArray * const 0x03f998c0, int 
(nsISupports *, void *)* 0x026442e0 nsMsgRDFDataSource::assertEnumFunc
(nsISupports *, void *), void * 0x0012c500) line 669 + 20 bytes
nsMsgRDFDataSource::NotifyObservers(nsIRDFResource * 0x03f9fe70, nsIRDFResource 
* 0x01201b00, nsIRDFNode * 0x03fd1510, int 0x00000001, int 0x00000000) line 384
nsMsgFolderDataSource::OnItemAddedOrRemoved(nsISupports * 0x03f9fe70, 
nsISupports * 0x03fd1510, const char * 0x041a0288, int 0x00000001) line 820
nsMsgFolderDataSource::OnItemAdded(nsMsgFolderDataSource * const 0x03f99960, 
nsISupports * 0x03f9fe70, nsISupports * 0x03fd1510, const char * 0x041a0288) 
line 786
nsMsgMailSession::OnItemAdded(nsMsgMailSession * const 0x03ef30f4, nsISupports 
* 0x03f9fe70, nsISupports * 0x03fd1510, const char * 0x041a0288) line 251
nsMsgFolder::NotifyItemAdded(nsMsgFolder * const 0x03f9fe8c, nsISupports * 
0x03f9fe70, nsISupports * 0x03fd1510, const char * 0x041a0288) line 2400
nsImapMailFolder::CreateClientSubfolderInfo(nsImapMailFolder * const 
0x03f9ff48, const char * 0x041a0168, unsigned short 0x005e, int 0x00000000) 
line 831
nsImapMailFolder::GetSubFolders(nsImapMailFolder * const 0x03f9fe8c, 
nsIEnumerator * * 0x0012cb64) line 519
nsMsgFolderDataSource::createFolderOpenNode(nsIMsgFolder * 0x03f9fe8c, 
nsIRDFNode * * 0x0012cbfc) line 1287 + 36 bytes
nsMsgFolderDataSource::createFolderNode(nsIMsgFolder * 0x03f9fe8c, 
nsIRDFResource * 0x01201940, nsIRDFNode * * 0x0012cbfc) line 969 + 16 bytes
nsMsgFolderDataSource::GetTarget(nsMsgFolderDataSource * const 0x03ef2f70, 
nsIRDFResource * 0x03f9fe70, nsIRDFResource * 0x01201940, int 0x00000001, 
nsIRDFNode * * 0x0012cbfc) line 341 + 25 bytes
GetTargetHasAssertion(nsIRDFDataSource * 0x03ef2f70, nsIRDFResource * 
0x03f9fe70, nsIRDFResource * 0x01201940, int 0x00000001, nsIRDFNode * 
0x01201850, int * 0x0012cd28) line 171 + 48 bytes
nsMsgFolderDataSource::DoFolderHasAssertion(nsIMsgFolder * 0x03f9fe8c, 
nsIRDFResource * 0x01201940, nsIRDFNode * 0x01201850, int 0x00000001, int * 
0x0012cd28) line 2014 + 34 bytes
nsMsgFolderDataSource::HasAssertion(nsMsgFolderDataSource * const 0x03ef2f70, 
nsIRDFResource * 0x03f9fe70, nsIRDFResource * 0x01201940, nsIRDFNode * 
0x01201850, int 0x00000001, int * 0x0012cd28) line 497 + 33 bytes
nsXULOutlinerBuilder::IsContainerOpen(nsIRDFResource * 0x03f9fe70, int * 
0x0012cd28) line 1695
nsXULOutlinerBuilder::OpenSubtreeOf(nsOutlinerRows::Subtree * 0x034dbb18, 
nsIRDFResource * 0x037a0660, int * 0x0012d074) line 1531
nsXULOutlinerBuilder::OpenContainer(int 0xffffffff, nsIRDFResource * 
0x037a0660) line 1446
nsXULOutlinerBuilder::Rebuild(nsXULOutlinerBuilder * const 0x034dba10) line 950
nsXULTemplateBuilder::AttributeChanged(nsXULTemplateBuilder * const 0x034dba18, 
nsIDocument * 0x0238a260, nsIContent * 0x0312ed60, int 0x00000000, nsIAtom * 
0x011ff580, int 0x00000002, int 0xffffffff) line 332
nsXULDocument::AttributeChanged(nsXULDocument * const 0x0238a260, nsIContent * 
0x0312ed60, int 0x00000000, nsIAtom * 0x011ff580, int 0x00000002, int 
0xffffffff) line 1742
nsXULElement::SetAttr(nsXULElement * const 0x0312ed60, nsINodeInfo * 
0x0312cbf0, const nsAString & {...}, int 0x00000001) line 3093
nsXULElement::SetAttribute(nsXULElement * const 0x0312ed64, const nsAString & 
{...}, const nsAString & {...}) line 1430 + 31 bytes
XPTC_InvokeByIndex(nsISupports * 0x0312ed64, unsigned int 0x0000001e, unsigned 
int 0x00000002, nsXPTCVariant * 0x0012d6e0) line 139
XPCWrappedNative::CallMethod(XPCCallContext & {...}, XPCWrappedNative::CallMode 
CALL_METHOD) line 1952 + 42 bytes
XPC_WN_CallMethod(JSContext * 0x02c13030, JSObject * 0x02809d80, unsigned int 
0x00000002, long * 0x028301dc, long * 0x0012d918) line 1262 + 14 bytes
js_Invoke(JSContext * 0x02c13030, unsigned int 0x00000002, unsigned int 
0x00000000) line 807 + 23 bytes
js_Interpret(JSContext * 0x02c13030, long * 0x0012e6bc) line 2719 + 15 bytes
js_Invoke(JSContext * 0x02c13030, unsigned int 0x00000001, unsigned int 
0x00000002) line 824 + 13 bytes
js_InternalInvoke(JSContext * 0x02c13030, JSObject * 0x00c74d00, long 
0x00c74e40, unsigned int 0x00000000, unsigned int 0x00000001, long * 
0x0012e89c, long * 0x0012e7e4) line 899 + 20 bytes
JS_CallFunctionValue(JSContext * 0x02c13030, JSObject * 0x00c74d00, long 
0x00c74e40, unsigned int 0x00000001, long * 0x0012e89c, long * 0x0012e7e4) line 
3362 + 31 bytes
nsJSContext::CallEventHandler(nsJSContext * const 0x02c13270, void * 
0x00c74d00, void * 0x00c74e40, unsigned int 0x00000001, void * 0x0012e89c, int 
* 0x0012e898, int 0x00000000) line 956 + 33 bytes
nsJSEventListener::HandleEvent(nsJSEventListener * const 0x02c3ab50, 
nsIDOMEvent * 0x03f87d44) line 139 + 74 bytes
nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x02c3a9f0, 
nsIDOMEvent * 0x03f87d44, nsIDOMEventTarget * 0x02c13440, unsigned int 
0x00000001, unsigned int 0x00000007) line 1196 + 20 bytes
nsEventListenerManager::HandleEvent(nsEventListenerManager * const 0x02c3a790, 
nsIPresContext * 0x02c18950, nsEvent * 0x0012efac, nsIDOMEvent * * 0x0012ef64, 
nsIDOMEventTarget * 0x02c13440, unsigned int 0x00000007, nsEventStatus * 
0x0012efd4) line 1869 + 36 bytes
GlobalWindowImpl::HandleDOMEvent(GlobalWindowImpl * const 0x02c13430, 
nsIPresContext * 0x02c18950, nsEvent * 0x0012efac, nsIDOMEvent * * 0x0012ef64, 
unsigned int 0x00000001, nsEventStatus * 0x0012efd4) line 604
DocumentViewerImpl::LoadComplete(DocumentViewerImpl * const 0x02c12d60, 
unsigned int 0x00000000) line 1089 + 47 bytes
nsDocShell::EndPageLoad(nsIWebProgress * 0x022bf044, nsIChannel * 0x022a7260, 
unsigned int 0x00000000) line 3730
nsWebShell::EndPageLoad(nsIWebProgress * 0x022bf044, nsIChannel * 0x022a7260, 
unsigned int 0x00000000) line 898
nsDocShell::OnStateChange(nsDocShell * const 0x022bf1a4, nsIWebProgress * 
0x022bf044, nsIRequest * 0x022a7260, int 0x00020010, unsigned int 0x00000000) 
line 3651
nsDocLoaderImpl::FireOnStateChange(nsIWebProgress * 0x022bf044, nsIRequest * 
0x022a7260, int 0x00020010, unsigned int 0x00000000) line 1095
nsDocLoaderImpl::doStopDocumentLoad(nsIRequest * 0x022a7260, unsigned int 
0x00000000) line 734
nsDocLoaderImpl::DocLoaderIsEmpty() line 632
nsDocLoaderImpl::OnStopRequest(nsDocLoaderImpl * const 0x022bf034, nsIRequest * 
0x03f7c350, nsISupports * 0x02c18950, unsigned int 0x00000000) line 563
nsLoadGroup::RemoveRequest(nsLoadGroup * const 0x022a4690, nsIRequest * 
0x03f7c350, nsISupports * 0x02c18950, unsigned int 0x00000000) line 516 + 44 
bytes
imgRequestProxy::OnStopRequest(imgRequestProxy * const 0x03f7c358, nsIRequest * 
0x03f7c100, nsISupports * 0x00000000, unsigned int 0x00000000) line 385
imgRequest::OnStopRequest(imgRequest * const 0x03f7c078, nsIRequest * 
0x03f7c100, nsISupports * 0x00000000, unsigned int 0x00000000) line 641
ProxyListener::OnStopRequest(ProxyListener * const 0x03f7c030, nsIRequest * 
0x03f7c100, nsISupports * 0x00000000, unsigned int 0x00000000) line 391
nsJARChannel::OnStopRequest(nsJARChannel * const 0x03f7c104, nsIRequest * 
0x03f86444, nsISupports * 0x00000000, unsigned int 0x00000000) line 579 + 49 
bytes
nsOnStopRequestEvent::HandleEvent() line 162
nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x03f87c64) line 65
PL_HandleEvent(PLEvent * 0x03f87c64) line 590 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x0053ae70) line 520 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x00930158, unsigned int 0x0000c110, unsigned 
int 0x00000000, long 0x0053ae70) line 1071 + 9 bytes
USER32! 77e13eb0()
USER32! 77e1401a()
USER32! 77e192da()
nsAppShellService::Run(nsAppShellService * const 0x011a7d50) line 453
main1(int 0x00000004, char * * 0x00485c60, nsISupports * 0x00000000) line 1288 
+ 32 bytes
main(int 0x00000004, char * * 0x00485c60) line 1616 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e87903()

Comment 19

[(not reading, please use [e-mail] instead)]

I have something that fixes it, I'll attach the patch.

Comment 20

[(not reading, please use [e-mail] instead)]

Attachment: patch

Comment 21

[(not reading, please use [e-mail] instead)]

argh.  that patch fixes the inbox problem, but with it, on the second time you 
launch, all the accounts are "doubled".  I'll keep working on it.

Comment 22

[(not reading, please use [e-mail] instead)]

I've got a one line hack fix, for the branch only.

currently, in OnLoadFolderPane(), we set the datasources and ref attributes for 
our outliner.

setting the ref attribute causes the outliner to be rebuilt.

nsXULTemplateBuilder::AttributeChanged() calls nsXULOutlinerBuilder::Rebuild()
if the attribute is "ref".

so, after setting ref once, my hack (for the branch) is to set it again.
that causes us to rebuild and it works around this problem.

my first patch also fixes prevents this problem 
(http://bugzilla.mozilla.org/attachment.cgi?id=51861&action=view), but causes 
doubling up of accounts.  see related to existing bugs #73953 and #100952, 
where accounts are doubled up in the "Get Msg" toolbar button.

Comment 23

[(not reading, please use [e-mail] instead)]

Attachment: branch only, since this doesn't seem to happen on the trunk

Comment 24

[Scott MacGregor]

getting on the branch radar for getting this hack into the branch. Fixes another
UI regression in the folder pane.

Comment 25

[Scott MacGregor]

Comment on attachment 51885 [details] [diff] [review]
branch only, since this doesn't seem to happen on the trunk

sr=mscott for this hack on the branch.

Comment 26

[(not reading, please use [e-mail] instead)]

Attachment: patch, includes a similar hack for #100952

Comment 27

[Jaime Rodriguez, Jr.]

pls check it in - PDT+

Comment 28

[(not reading, please use [e-mail] instead)]

this bug and #100952 are fixed on the branch only.

waterson has a fix for #100952 for the trunk, and this bug isn't on the trunk.

marking fixed.

Comment 29

[Chris Waterson]

Comment on attachment 51885 [details] [diff] [review]
branch only, since this doesn't seem to happen on the trunk

r=waterson

Comment 30

[Karen Huang]

Since this bug is not existing on trunk build, I have verified on Branch builds 
as following:
* WinNT 10-04-05-0.9.4:
  migrated profile -> pass
  new profile -> pass
  activating new profile -> pass
* Linux 10-04-04-0.9.4:
  migrated profile -> pass
  new profile -> pass
  activating new profile -> pass
* Mac 10-04-03-0.9.4:
  migrated profile -> pass
  new profile -> pass
  activating new profile -> pass
Marking as verifie.