23298 - Crash when dragging bookmarks

Status: VERIFIED WORKSFORME

(SeaMonkey :: Bookmarks & History, defect, P3)

Description

[Richard Zach]

After dragging a bookmark once or twice a segfault occurs.

1. Manage bookmarks
2. Drag a bookmark to a folder
3. Repeat

Result: Segfault
Expected result: bookmark would be filed in folder

Console output:

->>>>>>>>>>>>>> Write Clipboard to memory
nsDragService::InvokeDragSession
nsDragService::RegisterDragItemsAndFlavors
nsDragService::StartDragSession()
->>>>>>>>>>>>>> Write Clipboard to memory
nsDragService::InvokeDragSession
nsDragService::RegisterDragItemsAndFlavors
nsDragService::StartDragSession()
->>>>>>>>>>>>>> Write Clipboard to memory
nsDragService::InvokeDragSession
nsDragService::RegisterDragItemsAndFlavors
nsDragService::StartDragSession()

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1411]

Program received signal SIGSEGV, Segmentation fault.
0x406dcd69 in gtk_drag_begin ()

Linux build 2000.01.06.08
May be related to bug 22419

BTW: How do I get a bookmark into a folder? Drag&drop doesnt work, neither does
cut and past.

Comment 1

[Claudius Gayle]

by my estimation you can use cut and paste to move bookmarks into folders.
the only problem is you can't do it with a new or unpopulated folder.

Comment 2

[Claudius Gayle]

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

Comment 3

[Steve Lamm]

Dragging is going to be taken out of the tree for the short term, so I am
pushing this out to M15 for now.

Comment 4

[Claudius Gayle]

housekeeping: D&D is turned off for now so this bug won't be applicable for M13 candidates

Comment 5

[leger]

Adding "crash" keyword to all known open crasher bugs.

Comment 6

[Jim Bray]

 Probably related: crash (Sigsegv, current GNU-Linux) when deleting element from
bookmark-editing-screen using popup window and mouse. Will attempt to duplicate
with debugging build if requested.

Comment 7

[Claudius Gayle]

I don't see any problems on my 0320 build. a fix jsut went in for bug 30710 that may have helped. You may want to check this 
out with a new build yourself.

Comment 8

[Jim Bray]

OK, as of cvs-build 10am edt 3/21, I'm not seeing a crash. The

bookmark-manager window is still troubled: it takes about 30 seconds of 100%

k6-2/350 cpu to do anything: drag, create, delete. These same operations

complete in say 5 sec of cpu when done in the bookmark sidebar. Assuming that

the same code is doing the actual bookmark ops, and given the marked difference

between time in the sidebar and in the manager window, I suspect there is

the equivalent of a nearly-infinite loop in the rendering code for the manager

window.

Comment 9

[Claudius Gayle]

okay. that should be a new bug. this one should be resolved.

Comment 10

[don]

OK, has the new bug been openned?

Comment 11

[Claudius Gayle]

VERIFIED WFM. I opened bug 35022 to track the other issue.