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.

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.

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.

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.

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 `/'...

adding mail3 keyword

changing priorities

marking nsbeta1-

wfm me now.