58636 - Cannot display headers in IMAP "c\d" folder

Status: RESOLVED WORKSFORME

(MailNews Core :: Backend, defect, P2)

Description

[Karen Huang]

Problem found when verifying bug 29890

Used 10-30-09-MN6 build

Follow-up problem from bug 29890

There is no same copied message displaying in folder "c<d & "c\d",
Munging .msf file names currently are in unique names now.

But it seems that there is problem for copying the messages from Inbox to "c\d" 
folder. I check that there are unique names for the .msf files for c<d (c_d.msf) 
& c\d (c_d-1.msf). But, for some reason, it just doesn't display the message 
at all when I copying the messages to "c\d"...........

Additional Info: Copying messages to "c<d" is successful.

Comment 1

[Karen Huang]

Since this is follow-up issue from bug 29890, I am reassign this bug to David.
Please reassign to other developer if I was wrong.

Comment 2

[David :Bienvenu]

I looked into this some - as near as I can tell, the imap code is doing all the
right things, but at some point RDF (or some other layer) turns the folder uri
that ends "c\d" into one that ends "c/d" and no longer corresponds to the
correct imap folder/db. Any idea where this could be happening? Basically, the
mailnews js code gets the Folderloaded notification, but something goes wrong
between the point where it reroots the tree, and we try to build up the message
view.

Comment 3

[David :Bienvenu]

In OnFolderLoaded for imap://bienvenu@nsmail-1/c\d
at this point in the process,

the parent resource is imap://bienvenu@nsmail-2/c/d

nsMessageView::GetMessages(nsMessageView * const 0x046abe50, nsIRDFResource *
0x02abdcb0, nsIMsgWindow * 0x0469e6d0, nsISimpleEnumerator * * 0x04403618) line 88
nsMsgMessageDataSource::GetTargets(nsMsgMessageDataSource * const 0x04704be0,
nsIRDFResource * 0x02abdcb0, nsIRDFResource * 0x046d2b40, int 0x00000001,
nsISimpleEnumerator * * 0x04403618) line 446 + 43 bytes
CompositeAssertionEnumeratorImpl::GetEnumerator(nsIRDFDataSource * 0x04704be0,
nsISimpleEnumerator * * 0x04403618) line 496 + 37 bytes
CompositeEnumeratorImpl::HasMoreElements(CompositeEnumeratorImpl * const
0x04403608, int * 0x0012dec4) line 226 + 22 bytes
RDFContainerMemberTestNode::FilterInstantiations(InstantiationSet & {...}, void
* 0x0012e084) line 3559 + 42 bytes
TestNode::Propogate(const InstantiationSet & {...}, void * 0x0012e084) line 870
+ 19 bytes
TestNode::Propogate(const InstantiationSet & {...}, void * 0x0012e084) line 876
+ 30 bytes
RootNode::Propogate(const InstantiationSet & {...}, void * 0x0012e084) line 595
+ 30 bytes
nsXULTemplateBuilder::CreateContainerContents(nsIContent * 0x0255b490,
nsIRDFResource * 0x02abdcb0, int 0x00000000, nsIContent * * 0x0012e214, int *
0x0012e218) line 6256 + 48 bytes
nsXULTemplateBuilder::CreateTemplateAndContainerContents(nsIContent *
0x0255b490, nsIContent * * 0x0012e214, int * 0x0012e218) line 6178 + 34 bytes
nsXULTemplateBuilder::RebuildContainerInternal(nsIContent * 0x0255b490, int
0x00000000) line 4506 + 40 bytes
nsXULTemplateBuilder::RebuildContainer(nsXULTemplateBuilder * const 0x04403da4,
nsIContent * 0x0255b490) line 4463 + 17 bytes
nsXULDocument::RebuildWidgetItem(nsIContent * 0x0255b490) line 4475 + 22 bytes
nsXULDocument::AttributeChanged(nsXULDocument * const 0x02a2ac60, nsIContent *
0x0255b490, int 0x00000000, nsIAtom * 0x01675940, int 0xffffffff) line 1661
nsXULElement::SetAttribute(nsXULElement * const 0x0255b490, nsINodeInfo *
0x04199d60, const basic_nsAReadableString<unsigned short> & {...}, int
0x00000001) line 2778
nsXULElement::SetAttribute(nsXULElement * const 0x0255b494, const
basic_nsAReadableString<unsigned short> & {...}, const
basic_nsAReadableString<unsigned short> & {...}) line 1252 + 31 bytes
nsXULTreeElement::SetAttribute(nsXULTreeElement * const 0x046d1168, const
basic_nsAReadableString<unsigned short> & {...}, const
basic_nsAReadableString<unsigned short> & {...}) line 54 + 29 bytes
ElementSetAttribute(JSContext * 0x024b2a30, JSObject * 0x00ecaaa8, unsigned int
0x00000002, long * 0x075a3634, long * 0x0012e944) line 249 + 26 bytes


digging a little deeper, in

nsXULTemplateBuilder::CreateTemplateAndContainerContents(nsIContent* aElement,
                                                         nsIContent** aContainer,
                                                         PRInt32*
aNewIndexInContainer)

    rv = gXULUtils->GetElementRefResource(aElement, getter_AddRefs(resource));
    if (NS_SUCCEEDED(rv)) {
        // The element has a resource; that means that it corresponds
        // to something in the graph, so we need to go to the graph to
        // create its contents.
        rv = CreateContainerContents(aElement, resource, PR_FALSE, aContainer,
aNewIndexInContainer);

the resource here is the bogus uri imap://bienvenu@nsmail-2/c/d

So somewhere between the folder loaded notification, the tree re-rooting code
and here, we get a bogus uri.

Comment 4

[Chris Waterson]

Sounds like some of the URI canonicalization stuff in Necko is kicking in here. 
I can't recall any RDF-specific code that would replace `\' with `/'...

Comment 5

[David :Bienvenu]

adding mail3 keyword

Comment 6

[David :Bienvenu]

changing priorities

Comment 7

[scottputterman]

marking nsbeta1-

Comment 8

[David :Bienvenu]

wfm me now.