266139 - Unable to open (and delete) a msg from a virtual folder in a stand alone window

Status: VERIFIED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[Scott MacGregor]

Using yesterday's bits. Also reported on the forums.

Open a virtual folder. Double click on one of the messages. We bring up an empty
stand alone window instead of loading the message into the stand alone window.

Here's the JS error:

Error: uncaught exception: [Exception... "Component returned failure code:
0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIMsgDBView.loadMessageByMsgKey]" 
nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame ::
chrome://messenger/content/messageWindow.js :: OnLoadMessageWindowDelayed ::
line 320"  data: no]

Comment 1

[Scott MacGregor]

apparently this error only happens with cross folder virtual folders

Comment 2

[Scott MacGregor]

Attachment: part 1.....fix a JS error when setting the window title

Every time you clicked on a message in a XVF, we were triggering a JS error
when trying to update the window title because we were passing in a null
folder. That's because m_folder is null for XVFs. I just modified the code to
call GetMsgFolder which does the right thing for a XVF (returning the view
folder).

This doesn't fix the actual error in the bug yet. That appears to be a problem
with the view we are creating for the stand alone message window. It doesn't
have a folder associated with it. And it's just a regular view class, should we
be creating a XVFDBView for the stand alone message window such that
next/previous work?

Comment 3

[David :Bienvenu]

it should be cloning the current view...

Comment 4

[Scott MacGregor]

We need to implement ::CloneView and ::CopyView for nsMsgSearchDBView and
nsMsgXVFolderView to fix this bug so these views support cloning.

Comment 5

[Scott MacGregor]

Attachment: almost complete patch

This patch implements Clone and Copy for a cross virtual folder. I can now open
messages in a stand alone message window. Prev & Next navigation also works.

The remaining issue is deleting the message from the stand alone window. We
fail to load the next message or close the stand alone window.

Comment 6

[Scott MacGregor]

It seems to be generating the correct URI for the  next message to load in
LoadMessageByViewIndex. 

But then the database asserts nsMsgDatabase::GetThreadContainingMsgHdr:

  nsMsgKey threadId = nsMsgKey_None;
  (void)msgHdr->GetThreadId(&threadId);
  if (threadId != nsMsgKey_None)
    *result = GetThreadForThreadId(threadId);
  
  // if we can't find the thread, try using the msg key as the thread id,
  // because the msg hdr might not have the thread id set correctly
  if (!*result) 
  {
    nsMsgKey msgKey;
    NS_ASSERTION(PR_FALSE, "this shouldn't happen");

Stack trace:

nsDebug::Assertion(const char * 0x0213d8d8, const char * 0x0213d8cc, const char
* 0x0213d888, int 3850) line 109
nsMsgDatabase::GetThreadContainingMsgHdr(nsMsgDatabase * const 0x03c68798,
nsIMsgDBHdr * 0x02fac828, nsIMsgThread * * 0x0012e2b4) line 3850 + 35 bytes
nsMsgDatabase::GetThreadForMsgKey(unsigned int 24, nsIMsgThread * * 0x0012e2b4)
line 3866 + 25 bytes
nsMsgDatabase::MarkHdrRead(nsMsgDatabase * const 0x03c68798, nsIMsgDBHdr *
0x02fac828, int 1, nsIDBChangeListener * 0x03e0129c) line 2351 + 42 bytes
nsMsgDatabase::MarkRead(nsMsgDatabase * const 0x03c68798, unsigned int 24, int
1, nsIDBChangeListener * 0x03e0129c) line 2050 + 29 bytes
nsMsgDBView::SetReadByIndex(unsigned int 56, int 1) line 2655 + 74 bytes
nsMsgDBView::ApplyCommandToIndices(int 0, unsigned int * 0x03d69760, int 1) line
2396 + 23 bytes
nsMsgSearchDBView::DoCommand(nsMsgSearchDBView * const 0x03e01298, int 0) line
302 + 46 bytes
nsMsgXFVirtualFolderDBView::DoCommand(nsMsgXFVirtualFolderDBView * const
0x03e01298, int 0) line 228
X

Maybe I'm wrong and we aren't loading the next message at all but the message we
just deleted, hence the assertion. I'll look again.

Comment 7

[Scott MacGregor]

Attachment: the fix

Comment 8

[Scott MacGregor]

Comment on attachment 163625 [details] [diff] [review]
the fix

Makes stand alone message window work and it also fixes the problem with
deleting messages from the stand alone message window (when I cloned the view,
I wasn't registering the new view with each database it should be listening
too).

Comment 9

[Scott MacGregor]

fixed branch and trunk