Using build 2000-05-09 on linux if you drag an email address from the results pane of the Address Book to the Addressing pane of a New Msg you will crash if: 1. After the drop if drop in the wrong place 2. Of if you close the compose window after a sucessful drop 3. Or if you drop a 2nd address. Note: a separate bug has been logged for the drop location being flakey (bug

Linux only

Mass moving M16 to M17 - look for nsbeta2 before anything else.

Adding crash keyword

Putting on [nsbeta2+] radar for beta2 fix. Can you get a stack trace from Talkback?

change priority to P2 as it's a crash

Fixed and checked in

Using build 2000-06-26 this is fixed when you drag and drop a card from the Address Book to the New Msg window addressing pane. However, linux still crashes on the 2nd or 3rd drop and because of a differrent scrolling bug the addresses you drop using win98 and mac are lost during scrolling. Will verify based on original scenrio and open a new bug for the linux crash. Verified

Sorry, I got this one confused with 38716. This is still happening on linux, will reopen and add talkback (13137606) 0x00000000 js_GetProperty() js_Interpret() js_Invoke() js_InternalInvoke() JS_CallFunctionValue() nsJSContext::CallEventHandler() nsJSEventListener::HandleEvent() nsEventListenerManager::HandleEventSubType() nsEventListenerManager::HandleEvent() nsXULElement::HandleDOMEvent() nsXULElement::HandleDOMEvent() nsXULElement::HandleDOMEvent() nsXULElement::HandleDOMEvent() nsXULElement::HandleDOMEvent() nsXULElement::HandleDOMEvent() PresShell::HandleEventInternal() PresShell::HandleEvent() nsView::HandleEvent() nsView::HandleEvent() nsView::HandleEvent() nsViewManager2::DispatchEvent() HandleEvent() nsWidget::DispatchEvent() nsWidget::DispatchWindowEvent() nsWidget::DispatchMouseEvent() nsWindow::OnToplevelDragMotion() nsWindow::ToplevelDragMotionSignal() libgtk-1.2.so.0 + 0x8d7f5 (0x4066d7f5) libgtk-1.2.so.0 + 0xbafdd (0x4069afdd) libgtk-1.2.so.0 + 0xba422 (0x4069a422) libgtk-1.2.so.0 + 0xb8899 (0x40698899) libgtk-1.2.so.0 + 0x5e63f (0x4063e63f) libgtk-1.2.so.0 + 0x5e0d0 (0x4063e0d0) libgtk-1.2.so.0 + 0x5d9cf (0x4063d9cf) libgtk-1.2.so.0 + 0x8c9ea (0x4066c9ea) handle_gdk_event() libgdk-1.2.so.0 + 0x1700b (0x4071700b) libglib-1.2.so.0 + 0xfbe6 (0x40744be6) libglib-1.2.so.0 + 0x101a1 (0x407451a1) libglib-1.2.so.0 + 0x10341 (0x40745341) libgtk-1.2.so.0 + 0x8c209 (0x4066c209) nsAppShell::Run() nsAppShellService::Run() main1() main() libc.so.6 + 0x181eb (0x402451eb)

Seth, could you take a look at this bug for me. Thanks

taking from jfd while I investigate.

adding ducarroz back to the cc list.

removing nsbeta2+ and asking for consideration to cut from beta2. It appears this is only Linux. It also is an action that we don't think is too common (most people don't address by dragging a card from the AB to the compose window). There is definitely possible data loss if someone has composed a message and then drags an ab card. But I don't think that will happen too often.

Putting on [nsbeta2-] radar. Not critical to beta2. Adding "nsbeta3" keyword for consideration of a fix for that milestone.

Adding mail2 triage nomination keyword.

+ per mail triage

second pass: - per mail triage unfortunately

I noticed that blizzard landed a bunch of linux d&d changes recently, so this may be fixed. either way, I'm cc'ing blizzard who is the linux d&d expert.

I can't reproduce any of these problems. It might have been fixed as a result of the rewrite.

I can't reproduce using sept15 commercial build linux rh6.0, NT 4.0 or mac OS 9.0