264605 - crash when dragging a virtual folder into another local folder [@

Status: VERIFIED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[sairuh (rarely reading bugmail)]

found using 2004101505-0.8 on linux fc2. I've got a lot of local folders, so I
was playing around with virtual folders and found that I can crash tbird when
dragging a virtual folder into another local folder.

0. make sure you've got several [regular] folders under Local Folders (I haven't
tried this with the special folders).

1. in one of your regular local folders, enter something in the quicksearch
field that'll yield results.

2. from the quicksearch dropmenu, select "save as virtual folder..."

3. click OK to accept the virtual foldername, observe that it's created under
Local Folders.

4. from the folder pane, drag the virtual folder onto another regular folder
under Local Folders.

results: crash. interestingly, when I restart tbird, the folder was copied (not
moved) to the destination, but its contents are gone. the original virtual
folder remains intact, though.

stack info:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=1331877

nsMsgAccountManager::SaveVirtualFolders()
nsMsgAccountManager::OnItemRemoved()
nsMsgMailSession::OnItemRemoved()
nsMsgDBFolder::NotifyItemDeleted()
nsMsgDBFolder::PropagateDelete()
nsMsgLocalMailFolder::CopyFolderLocal()
nsMsgLocalMailFolder::CopyFolder()
nsMsgFolderDataSource::DoFolderCopyToFolder()
nsMsgFolderDataSource::DoCommand()
CompositeDataSourceImpl::DoCommand()
nsMessenger::DoCommand()
nsMessenger::CopyFolders()
XPTC_InvokeByIndex()
XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)()
XPC_WN_CallMethod()
js_Invoke()
js_Interpret()
js_Invoke()
nsXPCWrappedJSClass::CallMethod()
nsXPCWrappedJS::CallMethod()
PrepareAndDispatch()
nsXULTreeBuilder::Drop()
nsTreeBodyFrame::OnDragDrop()
nsTreeBoxObject::OnDragDrop()
XPTC_InvokeByIndex()
XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)()
XPC_WN_CallMethod()
js_Invoke()
js_Interpret()
js_Invoke()
js_InternalInvoke()
JS_CallFunctionValue()
nsJSContext::CallEventHandler()
nsJSEventListener::HandleEvent()
nsXBLPrototypeHandler::ExecuteHandler()
nsXBLEventHandler::HandleEvent()
nsEventListenerManager::HandleEventSubType()
nsEventListenerManager::HandleEvent()
nsXULElement::HandleDOMEvent()
nsXULElement::HandleDOMEvent()
nsXULElement::HandleDOMEvent()
nsXULElement::HandleDOMEvent()
PresShell::HandleEventInternal()
PresShell::HandleEvent()
nsViewManager::HandleEvent()
nsViewManager::DispatchEvent()
HandleEvent()
nsCommonWidget::DispatchEvent()
nsWindow::OnDragDropEvent()
drag_drop_event_cb()
libgtk-x11-2.0.so.0 + 0x1125b9 (0x04e505b9)
libgobject-2.0.so.0 + 0x9160 (0x0011a160)
libgobject-2.0.so.0 + 0x1d195 (0x0012e195)
libgobject-2.0.so.0 + 0x1bf2e (0x0012cf2e)
libgobject-2.0.so.0 + 0x1c544 (0x0012d544)
libgtk-x11-2.0.so.0 + 0xa4a7d (0x04de2a7d)
libgtk-x11-2.0.so.0 + 0xa3f86 (0x04de1f86)
libgtk-x11-2.0.so.0 + 0xa3fda (0x04de1fda)
libgtk-x11-2.0.so.0 + 0xa365d (0x04de165d)
libgtk-x11-2.0.so.0 + 0x10f41b (0x04e4d41b)
libgdk-x11-2.0.so.0 + 0x3e035 (0x0072a035)
libglib-2.0.so.0 + 0x23e4a (0x0035be4a)
libglib-2.0.so.0 + 0x24f28 (0x0035cf28)
libglib-2.0.so.0 + 0x25260 (0x0035d260)
libglib-2.0.so.0 + 0x258a3 (0x0035d8a3)
libgtk-x11-2.0.so.0 + 0x10ec33 (0x04e4cc33)
nsAppShell::Run()
nsAppShellService::Run()
xre_main()
main()
libc.so.6 + 0x14ad4 (0x00c04ad4)

Comment 1

[Marcia Knous [:marcia]]

Confirming. I crashed using today's Mac build follow Sarah's steps. I submitted
a Talkback report as well -
http://talkback-reports.mozilla.org/talkback/quicksearch.jsp?search=2&type=iid&id=1332169

Comment 2

[sairuh (rarely reading bugmail)]

nominating, as it's easy to reproduce this crash.

Comment 3

[Scott MacGregor]

we don't need to use the flag on bugs triaged for 0.9

Comment 4

[David :Bienvenu]

Attachment: fix for one crash

I encountered a different, probably related, crash - this fixes that crash.

Comment 5

[Scott MacGregor]

David should we support dragging virtual folders around and dropping them into
other accounts like local Folders which is what Sairuh did for this bug.

Or should we just disable dragging virtual folders into other folders / accounts? 

Comment 6

[David :Bienvenu]

I'm not sure that Sairuh was dragging a virtual folder across accounts - it
looks like it was all within Local Folders...or maybe between pop3 server and
local folders?

We probably do want to disable drag drop across accounts because it doesn't seem
to work correctly in my test case. I dragged a pop3 vf to a local folders
account, and it copied the folder, but seemed to forget that it was a virtual
folder.

Comment 7

[Marcia Knous [:marcia]]

I get the same behavior when I try to drag and drop an IMAP VF to a local folder
- the folder is moved but it lost is virtual folder properties.

(In reply to comment #6)
> I'm not sure that Sairuh was dragging a virtual folder across accounts - it
> looks like it was all within Local Folders...or maybe between pop3 server and
> local folders?
> 
> We probably do want to disable drag drop across accounts because it doesn't seem
> to work correctly in my test case. I dragged a pop3 vf to a local folders
> account, and it copied the folder, but seemed to forget that it was a virtual
> folder.

Comment 8

[sairuh (rarely reading bugmail)]

(In reply to comment #6)
> I'm not sure that Sairuh was dragging a virtual folder across accounts - it
> looks like it was all within Local Folders...or maybe between pop3 server and
> local folders?

to clarify, the Local Folders I had were not from a POP account --just a bunch
of local folders I created for filing messages.

I tend to agree that we should disable d'n'd virtual folders across accounts.

Comment 9

[Scott MacGregor]

I can help out with this bug if you want David. Are we in agreement that we
should ban virtual folder dragging and dropping outside of the account it lives
in? Any other drag and drop restrictions we want to apply as well?

Comment 10

[David :Bienvenu]

I have not been able to reproduce the crash. But disabling drag drop outside of
accounts is a reasonable thing to do...especially drag drop across protocols, if
that makes sense (dragging a local folder virtual folder to another pop3 account
should be ok...)

Comment 11

[Marcia Knous [:marcia]]

just adding my .02 - I agree that we should prohibit virtual folder dragging and
dropping outside of the account that the VF lives in.

Comment 12

[David :Bienvenu]

Attachment: proposed fix

check for null dbFolderInfo (which would be caused by an error opening the db)

Comment 13

[David :Bienvenu]

Comment on attachment 164097 [details] [diff] [review]
proposed fix

I think this will actually fix the crash.

Comment 14

[Scott MacGregor]

Attachment: additional fix to prevent dragging a VF outside of its account

Comment 15

[Scott MacGregor]

Comment on attachment 164219 [details] [diff] [review]
additional fix to prevent dragging a VF outside of its account

David, this implements the idea we talked about earlier in this bug. It blocks
drag and drop of a VF outside of the account it lives under. We could make this
smarter and allow it if neither server type is imap....

Comment 16

[David :Bienvenu]

marking fixed - can anyone reproduce this with today's build?

Comment 17

[sairuh (rarely reading bugmail)]

I can no longer repro this using recent trunk tbird builds --vrfy'd fixed with
2005060606-trunk on OS X 10.4.1.