Closed Bug 269568 Opened 20 years ago Closed 13 years ago

crash when performing a drag and drop in various parts of the ui [@ JS_GetPrivate][@ nsWindow::OnDragMotionEvent]

Categories

(Core :: Widget: Gtk, defect)

Product:
Core
Component:
Widget: Gtk
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: feranick, Assigned: neil)

References

Details

(Keywords: crash, hang, platform)

Crash Data

Attachments

(3 files, 5 obsolete files)

Console output for firefox build with patch 186719
11.91 KB, text/plain
Details
Proposed patch
3.71 KB, patch
bryner
: review+
bryner
: superreview+
asa
: approval1.8b4-
Details | Diff | Splinter Review
wallpaper
1.90 KB, patch
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

Using thunderbird version 0.9 (20041103)

When I try to drag and drop a previously saved extension (any extension) into
the extension manager, Thunderbird freezes. If I try and close it, Thunderbird
crashes. 

Note: The bug is NOT present under WinXP

Firefox is affected by the same bug: 268023

Reproducible: Always
Steps to Reproduce:
1. Download an extension
2. Drag and drop the extension into the extension manager panel
Actual Results:  
Thunderbird freezes. If I try and close it, Thunderbird crashes. 

Expected Results:  
Thunderbird should install the extension.

Talkback ID: TB1615459E
JS_GetPrivate 
[d:/builds/tinderbox/firefox-0.10.1/WINNT_5.0_Clobber/mozilla/js/src/jsapi.c,
line 1999]
nsScriptSecurityManager::GetFramePrincipal 
[d:/builds/tinderbox/firefox-0.10.1/WINNT_5.0_Clobber/mozilla/caps/src/nsScriptSecurityManager.cpp,
line 1825]
nsScriptSecurityManager::GetPrincipalAndFrame 
[d:/builds/tinderbox/firefox-0.10.1/WINNT_5.0_Clobber/mozilla/caps/src/nsScriptSecurityManager.cpp,
line 1849]
nsScriptSecurityManager::GetSubjectPrincipal 
[d:/builds/tinderbox/firefox-0.10.1/WINNT_5.0_Clobber/mozilla/caps/src/nsScriptSecurityManager.cpp,
line 1889]
nsScriptSecurityManager::GetSubjectPrincipal 
[d:/builds/tinderbox/firefox-0.10.1/WINNT_5.0_Clobber/mozilla/caps/src/nsScriptSecurityManager.cpp,
line 1575]
nsContentUtils::IsCallerChrome 
[d:/builds/tinderbox/firefox-0.10.1/WINNT_5.0_Clobber/mozilla/content/base/src/nsContentUtils.cpp,
line 921]
PresShell::HandleEventInternal 
[d:/builds/tinderbox/firefox-0.10.1/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp,
line 6025]
PresShell::HandleEvent 
[d:/builds/tinderbox/firefox-0.10.1/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp,
line 5919]
nsViewManager::HandleEvent 
[d:/builds/tinderbox/firefox-0.10.1/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp,
line 2244]
nsViewManager::DispatchEvent 
[d:/builds/tinderbox/firefox-0.10.1/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp,
line 2030]
HandleEvent 
[d:/builds/tinderbox/firefox-0.10.1/WINNT_5.0_Clobber/mozilla/view/src/nsView.cpp,
line 79]
nsWindow::DispatchEvent 
[d:/builds/tinderbox/firefox-0.10.1/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 1067]
nsWindow::DispatchFocus 
[d:/builds/tinderbox/firefox-0.10.1/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 5451]
nsWindow::ProcessMessage 
[d:/builds/tinderbox/firefox-0.10.1/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 4216]
nsWindow::WindowProc 
[d:/builds/tinderbox/firefox-0.10.1/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 1349]
USER32.dll + 0x8709 (0x77d48709)
USER32.dll + 0x87eb (0x77d487eb)
USER32.dll + 0xb368 (0x77d4b368)
USER32.dll + 0xb3b4 (0x77d4b3b4)
ntdll.dll + 0xeae3 (0x7c90eae3)
USER32.dll + 0x93df (0x77d493df)
PeekKeyAndIMEMessage 
[d:/builds/tinderbox/firefox-0.10.1/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsAppShell.cpp,
line 91]
nsAppShell::GetNativeEvent 
[d:/builds/tinderbox/firefox-0.10.1/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsAppShell.cpp,
line 189]
nsXULWindow::ShowModal 
[d:/builds/tinderbox/firefox-0.10.1/WINNT_5.0_Clobber/mozilla/xpfe/appshell/src/nsXULWindow.cpp,
line 362]
nsContentTreeOwner::ShowAsModal 
[d:/builds/tinderbox/firefox-0.10.1/WINNT_5.0_Clobber/mozilla/xpfe/appshell/src/nsContentTreeOwner.cpp,
line 449]
nsWindowWatcher::OpenWindow 
[d:/builds/tinderbox/firefox-0.10.1/WINNT_5.0_Clobber/mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp,
line 458]
nsProfileMigrator::Migrate 
[d:/builds/tinderbox/firefox-0.10.1/WINNT_5.0_Clobber/mozilla/browser/components/migration/src/nsProfileMigrator.cpp,
line 135]
xre_main 
[d:/builds/tinderbox/firefox-0.10.1/WINNT_5.0_Clobber/mozilla/toolkit/xre/nsAppRunner.cpp,
line 1820]
main 
[d:/builds/tinderbox/firefox-0.10.1/WINNT_5.0_Clobber/mozilla/browser/app/nsBrowserApp.cpp,
line 58]
kernel32.dll + 0x16d4f (0x7c816d4f)
Keywords: crash
Summary: Thunderbird crashes when trying to drag and drop a saved extension into the extension managerc → Thunderbird crashes when trying to drag and drop a saved extension into the extension manager [@ JS_GetPrivate]
->proper component
Firefox and Thunderbird share EM code, so no need to file separate bugs for them.
Assignee: mscott → firefox
Product: Thunderbird → Firefox
QA Contact: general
Summary: Thunderbird crashes when trying to drag and drop a saved extension into the extension manager [@ JS_GetPrivate] → crash when trying to drag and drop a saved extension into the extension manager - Fx and TB [@ JS_GetPrivate]
d'oh
Assignee: firefox → bugs
Component: General → Extension/Theme Manager
QA Contact: general → bugs
*** Bug 268023 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050216 Firefox/1.0+
(clean profile)

I did some more testing on it. If you drag the .xpi file on the extension
manager and you quickly release it, FF freezes. If you drag on the ext. manager,
WAIT for a couple of seconds, and then drop it, the installation starts smoothly.

An indication of when to drop is given by the "tail"/shadow left when you move
the xpi over the ext manager. If you drop when you still see the ""tail"", it
freezes. If you wait, the tail disappear and you can install it. 
In a recompiled version of the trunk of mine, I found that the problem could be
fixed in the file:

cvsroot/mozilla/toolkit/mozapps/extensions/content/extensions.js

if line 609:

aDragSession.getData(xfer, i);

is commented. The problem is fixed in my Linux build, without loosing any other
extension functionality. 

Exactly the same stack trace was reported by a person from the german newsgroup.
He tried to click a button on a webpage or a tab within the tab bar. The same 
also happens sometimes by closing a tab. The ID is TB5000359Z. He is using
Windows so we should expand the OS to all if this issue is related to this one. 

JS_GetPrivate 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsapi.c,
line 1999]
nsScriptSecurityManager::GetFramePrincipal 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/caps/src/nsScriptSecurityManager.cpp,
line 1833]
nsScriptSecurityManager::GetPrincipalAndFrame 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/caps/src/nsScriptSecurityManager.cpp,
line 1857]
nsScriptSecurityManager::GetSubjectPrincipal 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/caps/src/nsScriptSecurityManager.cpp,
line 1897]
nsScriptSecurityManager::GetSubjectPrincipal 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/caps/src/nsScriptSecurityManager.cpp,
line 1583]
nsContentUtils::IsCallerChrome 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/base/src/nsContentUtils.cpp,
line 921]


Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050418 Firefox/1.0+
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3 

Still present in the trunk, as well as 1.0.3 (for this last one, see TB5204244X


That last talkback has different stack, top is:
0x00000079
nsWindow::OnDragMotionEvent() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/widget/src/gtk2/nsWindow.cpp,
line 1786]

I got a hang when testing this using 2005051007-1.0.x (branch) bits on fedora
core 3.

1. downloaded tabbrowser extension to desktop.
2. created a new profile, launched it.
3. opened the Extensions dialog.
4. quickly dragged the extension (xpi) file and released onto the Extensions dialog.

results:
-------
Firefox hangs. get a lot of the following in the console:

(Gecko:5506): Gtk-CRITICAL **: file gtkdnd.c: line 643 (gtk_drag_get_data):
assertion `GTK_IS_WIDGET (widget)' failed

5. the titlebar of the Extensions dialog was accessible, so I clicked the 'x'
close widget, then firefox finally crashed. (talkback is backed up, and I didn't
get the incident #, but it'd be listed via my bugzilla email.)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: hang
got talkback up with the incidents:

TB5729420Z
TB5729562Y
TB5729591X
Incident ID: 5729420
Stack Signature	0x00c7d96b 4cba4886
Product ID	Firefox10
Build ID	2005051006
Trigger Time	2005-05-10 13:50:35.0
Platform	LinuxIntel
Operating System	Linux 2.6.11-1.14_FC3
Module	
URL visited	
User Comments	bug 269568, after i closed the extensions dialog (it was hanging
beforehand).
Since Last Crash	1 sec
Total Uptime	1 sec
Trigger Reason	SIGSEGV: Segmentation Fault: (signal 11)
Source File, Line No.	N/A
Stack Trace 	
0x00c7d96b
nsWindow::OnDragMotionEvent() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/widget/src/gtk2/nsWindow.cpp,
line 1786]
nsWindow::FireDragMotionTimer() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/widget/src/gtk2/nsWindow.cpp,
line 3707]
nsWindow::DragMotionTimerCallback() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/widget/src/gtk2/nsWindow.cpp,
line 3734]
libglib-2.0.so.0 + 0x26368 (0x002eb368)
libglib-2.0.so.0 + 0x237bb (0x002e87bb)
libglib-2.0.so.0 + 0x25242 (0x002ea242)
libglib-2.0.so.0 + 0x25728 (0x002ea728)
libgtk-x11-2.0.so.0 + 0x10a67d (0x0081867d)
nsDragService::GetTargetDragData() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/widget/src/gtk2/nsDragService.cpp,
line 798]
nsDragService::GetData() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/widget/src/gtk2/nsDragService.cpp,
line 485]
XPTC_InvokeByIndex()
XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp,
line 2033]
XPC_WN_CallMethod() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1781]
js_Invoke() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/js/src/jsinterp.c,
line 955]
js_Interpret() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/js/src/jsinterp.c,
line 2999]
js_Invoke() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/js/src/jsinterp.c,
line 972]
js_InternalInvoke() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/js/src/jsinterp.c,
line 1050]
JS_CallFunctionValue() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/js/src/jsapi.c,
line 3698]
nsJSContext::CallEventHandler() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/dom/src/base/nsJSEnvironment.cpp,
line 1296]
nsJSEventListener::HandleEvent() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/dom/src/events/nsJSEventListener.cpp,
line 177]
nsEventListenerManager::HandleEventSubType() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1436]
nsEventListenerManager::HandleEvent() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1529]
nsXULElement::HandleDOMEvent() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2841]
nsXULElement::HandleDOMEvent() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp,
line 710]
PresShell::HandleEventInternal() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp,
line 710]
PresShell::HandleEvent() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp,
line 5920]
nsViewManager::HandleEvent() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/view/src/nsViewManager.cpp,
line 710]
nsViewManager::DispatchEvent() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/view/src/nsViewManager.cpp,
line 2066]
HandleEvent() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/view/src/nsView.cpp,
line 243]
nsCommonWidget::DispatchEvent() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/widget/src/gtk2/nsCommonWidget.cpp,
line 215]
nsWindow::OnDragMotionEvent() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/widget/src/gtk2/nsWindow.cpp,
line 1820]
nsWindow::FireDragMotionTimer() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/widget/src/gtk2/nsWindow.cpp,
line 3707]
nsWindow::DragMotionTimerCallback() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/widget/src/gtk2/nsWindow.cpp,
line 3734]
libglib-2.0.so.0 + 0x26368 (0x002eb368)
libglib-2.0.so.0 + 0x237bb (0x002e87bb)
libglib-2.0.so.0 + 0x25242 (0x002ea242)
libglib-2.0.so.0 + 0x25728 (0x002ea728)
libgtk-x11-2.0.so.0 + 0x10a67d (0x0081867d)
nsDragService::GetTargetDragData() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/widget/src/gtk2/nsDragService.cpp,
line 798]
nsDragService::GetData() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/widget/src/gtk2/nsDragService.cpp,
line 453]
XPTC_InvokeByIndex()
XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp,
line 2033]
XPC_WN_CallMethod() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1781]
js_Invoke() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/js/src/jsinterp.c,
line 955]
js_Interpret() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/js/src/jsinterp.c,
line 2999]
js_Invoke() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/js/src/jsinterp.c,
line 972]
js_InternalInvoke() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/js/src/jsinterp.c,
line 1050]
JS_CallFunctionValue() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/js/src/jsapi.c,
line 3698]
nsJSContext::CallEventHandler() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/dom/src/base/nsJSEnvironment.cpp,
line 1296]
nsJSEventListener::HandleEvent() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/dom/src/events/nsJSEventListener.cpp,
line 177]
nsEventListenerManager::HandleEventSubType() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1436]
nsEventListenerManager::HandleEvent() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1529]
nsXULElement::HandleDOMEvent() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2841]
nsXULElement::HandleDOMEvent() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp,
line 710]
PresShell::HandleEventInternal() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp,
line 710]
PresShell::HandleEvent() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp,
line 5920]
nsViewManager::HandleEvent() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/view/src/nsViewManager.cpp,
line 710]
nsViewManager::DispatchEvent() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/view/src/nsViewManager.cpp,
line 2066]
HandleEvent() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/view/src/nsView.cpp,
line 243]
nsCommonWidget::DispatchEvent() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/widget/src/gtk2/nsCommonWidget.cpp,
line 215]
nsWindow::OnDragMotionEvent() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/widget/src/gtk2/nsWindow.cpp,
line 1820]
nsWindow::FireDragMotionTimer() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/widget/src/gtk2/nsWindow.cpp,
line 3707]
nsWindow::DragMotionTimerCallback() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/widget/src/gtk2/nsWindow.cpp,
line 3734]
libglib-2.0.so.0 + 0x26368 (0x002eb368)
libglib-2.0.so.0 + 0x237bb (0x002e87bb)
libglib-2.0.so.0 + 0x25242 (0x002ea242)
libglib-2.0.so.0 + 0x25728 (0x002ea728)
libgtk-x11-2.0.so.0 + 0x10a67d (0x0081867d)
nsDragService::GetTargetDragData() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/widget/src/gtk2/nsDragService.cpp,
line 798]
nsDragService::GetData() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/widget/src/gtk2/nsDragService.cpp,
line 485]
XPTC_InvokeByIndex()
XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp,
line 2033]
XPC_WN_CallMethod() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1781]
js_Invoke() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/js/src/jsinterp.c,
line 955]
js_Interpret() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/js/src/jsinterp.c,
line 2999]
js_Invoke() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/js/src/jsinterp.c,
line 972]
js_InternalInvoke() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/js/src/jsinterp.c,
line 1050]
JS_CallFunctionValue() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/js/src/jsapi.c,
line 3698]
nsJSContext::CallEventHandler() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/dom/src/base/nsJSEnvironment.cpp,
line 1296]
nsJSEventListener::HandleEvent() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/dom/src/events/nsJSEventListener.cpp,
line 177]
nsEventListenerManager::HandleEventSubType() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1436]
nsEventListenerManager::HandleEvent() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1529]
nsXULElement::HandleDOMEvent() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2841]
nsXULElement::HandleDOMEvent() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp,
line 710]
PresShell::HandleEventInternal() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp,
line 710]
PresShell::HandleEvent() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp,
line 5920]
nsViewManager::HandleEvent() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/view/src/nsViewManager.cpp,
line 710]
nsViewManager::DispatchEvent() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/view/src/nsViewManager.cpp,
line 2066]
HandleEvent() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/view/src/nsView.cpp,
line 243]
nsCommonWidget::DispatchEvent() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/widget/src/gtk2/nsCommonWidget.cpp,
line 215]
nsWindow::OnDragMotionEvent() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/widget/src/gtk2/nsWindow.cpp,
line 1820]
nsWindow::FireDragMotionTimer() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/widget/src/gtk2/nsWindow.cpp,
line 3707]
nsWindow::DragMotionTimerCallback() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/widget/src/gtk2/nsWindow.cpp,
line 3734]
libglib-2.0.so.0 + 0x26368 (0x002eb368)
libglib-2.0.so.0 + 0x237bb (0x002e87bb)
libglib-2.0.so.0 + 0x25242 (0x002ea242)
libglib-2.0.so.0 + 0x25728 (0x002ea728)
libgtk-x11-2.0.so.0 + 0x10a67d (0x0081867d)
nsDragService::GetTargetDragData() 
[/builds/tinderbox/Fx-Aviary1.0.1/Linux_2.4.20-28.8_Clobber/mozilla/widget/src/gtk2/nsDragService.cpp,
line 798]
Summary: crash when trying to drag and drop a saved extension into the extension manager - Fx and TB [@ JS_GetPrivate] → crash when trying to drag and drop a saved extension into the extension manager - Fx and TB [@ JS_GetPrivate][@ nsWindow::OnDragMotionEvent]
A workaround is to install either the Install New Theme or Local Install
extensions - the former adds a filepicker to the Fx Theme Manager for installing
theme JARs, while the latter adds the same to the Fx Extension Manager.
nominating for the trunk (at least).
Flags: blocking-aviary1.1?
note to self: this crash occurs in ffox 1.0.
This bug is also in the trunk. See Comment #8.
TB5993059M

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050520 Firefox/1.0+
The checkin of the patch in bug 293663 included a re-write of the drag and drop
code. Is this still a problem with the current trunk?
rewrite of the Extension/Theme Manager drag and drop code that is
The patch suggested in Comment #18 seems NOT to work. If I drag and drop the
extension in the main window it is installed with no problems, no crashes, no
hangs. But if I drag and drop it in the Extension Manager window the problem is
still there intact.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050617 Firefox/1.0+
Talkback: TB6758165H

Same thing using Thunderbird trunk: version 1.0+ 20050617
From looking at the talkback this may have to do with converting file data to
url data in the core drag and drop code when text/x-moz-url is preferred. I
considered reversing the preference in the EM DnD code so that if it is file
data we use it first instead of having the core DnD code coerce it but first
wanted to see if the new optimizations fixed this. I haven't been able to
reproduce this but I will post a patch for someone to try out to see if this
would fix this for the EM.
Attached patch possible patch (obsolete) — — Splinter Review 
If anyone experiencing this bug could try this out and report back I would
appreciate it. All this patch does is make "application/x-moz-file" the
preferred data flavour over "text/x-moz-url". The reason this might fix this in
relation to the EM is that there is platform specific conversion code to
convert the "application/x-moz-file" data flavour to a "text/x-moz-url" data
flavour in the core DnD code. If this does fix it for the EM a new or existing
bug should be used to fix the crash condition in the core DnD code.
I make two bilds from the last trunk, 20050618 with and without the patch. You
can find them out here (along with the .mozdevconf):

http://tinyurl.com/ddgz8

The standard build crashes at times. If it doesn't crash, nothing happens, no
installation begins. The patched crashes badly, without freezing.
By the way there is no difference in behavior with respect to this bug, between
the standard build in comment #23 and the current trunk.
Attached patch test patch (obsolete) — — Splinter Review 
I took a look at the browser's content window DnD code for differences and it
also allows DnD on text/unicode so I added it along with a couple of dumps to
hopefully get a better handle on why this is happening. Taking another look at
the talkback it looks theere is some recursion happening similar to bug 213247.
If you try this out can you provide the console output that starts with "***EM"
Attachment #186609 - Attachment is obsolete: true
New builds available with patch 186719 (comment 25), in folder 20050619:

http://tinyurl.com/93em4

The patched version doesn't crash or hang, but the installation doesn't start.
Robert Strong asks for the console output. Sorry for the question: which console
are you talking about? I can easily produce the output, once I know which one it
is. I am fairly new, so I apologize if I am slow in this.
(In reply to comment #26)
> Sorry for the question: which console are you talking about? I can easily
> produce the output, once I know which one it is. I am fairly new, so I 
> apologize if I am slow in this.

Running firefox.exe -console and setting a pref will let you see the output from
the console.

See http://kb.mozillazine.org/Viewing_dump()_output .
The console output is from the patched build of firefox from comment 26.
dnd on EM in my linux trunk build just plain doesn't work, but dragging to the
content area in the browser works... no crash though.
Flags: blocking-aviary1.1? → blocking1.8b4?
Flags: blocking1.8b4? → blocking1.8b4-
The data returned by DnD for text/x-moz-url is UTF-16LE. I'm able to use
nsIScriptableUnicodeConverter ConvertFromUnicode to get a valid url but if there
is more than one item the xfer data is concatenated for all of the items... so
each items data contains each url from the DnD operation. Also, dropping a file
onto the Bookmarks Manager doesn't work on Linux most likely due to the same
root cause.
Attached patch patch (obsolete) — — Splinter Review 
This adds a #ifndef XP_UNIX so that ondragenter always sets canDrop=true for
UNIX. It turns out that valid DnD XFer data is returned from ondrop but it is a
crapshoot getting valid data from ondragenter and ondragover. I tested DnD with
local files, web page links to an xpi, and links from the browser content area
when viewing the file system.

I also changed ondrop so that if one of the items is not an xpi or jar it will
continue to the next item... this will only affect the UNIX case since canDrop
will be false for all others. With the invalid data I have seen from the other
handlers I feel safer with it this way. The changes should not affect any
platform other than fixing this on the platform where it is broken and I think
this is both safe and appropriate for 1.8b4.
Assignee: bugs → rob_strong
Attachment #186719 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #194298 - Flags: review?(mconnor)
this is bogus. if widget is sending bad data or crashing, then it needs to be 
fixed. wallpapering your component so that the next component in some other 
product suffers isn't acceptable.
Keywords: platform
Or at the least a bug on the real problem should be filed...
Sorry for not stating what I thought was obvious.... The course I plan on taking
if this is approved is to just wallpaper this for 1.8 and to file a bug for the
gtk dnd bug... the need to wallpaper this is not only due to the crash (which I
can easily reproduce) but also due to the inability to install themes on UNIX.
sorry, some of us plan to try to ship products based on 1.8 and we don't need 
more nasty surprises. make sure that the new bug is at least recommended for 
the 1.8 branch.
BTW: when I said gtk dnd bug I'm referring to the mozilla gtk dnd code though I
haven't investigated it thoroughly. Also, this bug has been around for almost a
year and the wallpaper provides one method for anyone shipping a product that
needs to work around this bug.
Comment on attachment 194298 [details] [diff] [review]
patch

Benjamin, comment #31 has the details.
Attachment #194298 - Flags: review?(mconnor) → review?(benjamin)
A custom build with the patch in comment #31 is available:

http://tinyurl.com/93em4

The patch works well, the bug is not present. Using GNOME 2.4, Fedora Core 1.







Note: this patch has been tested successfully on Linux, Win32, and Mac OS X. The
only behavior change was seen on Linux where DnD of extensions and themes now
work... the other platforms continued to work with the same behavior that was
present prior to the patch.
Flags: blocking1.8b4?
Triage team: this issue has been around since before 1.0 for the aviary apps. It
looks like this patch is trying to bandaid a deeper issue in gtk widget code. 
Comment on attachment 194298 [details] [diff] [review]
patch

I am not competent to review this, let's try Neil.
Attachment #194298 - Flags: review?(benjamin) → review?(neil.parkwaycc.co.uk)
Flags: blocking1.8b4? → blocking1.8b4-
Comment on attachment 194298 [details] [diff] [review]
patch

I couldn't drop anything on my linux build at all, so I think gtk is in serious
need of some widget love.
Attachment #194298 - Flags: review?(neil.parkwaycc.co.uk) → review-
Assignee: rob_strong → blizzard
Status: ASSIGNED → NEW
Component: Extension/Theme Manager → Widget: Gtk
Flags: review-
Product: Firefox → Core
QA Contact: bugs → gtk
Version: unspecified → Trunk
Attached patch Proposed patch — — Splinter Review 
This just starts the drag session before telling people about it ;-)

Feel free to r+sr or whatever is appropriate for this module.
Assignee: blizzard → neil.parkwaycc.co.uk
Attachment #194298 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #194462 - Flags: superreview?(bryner)
Comment on attachment 194298 [details] [diff] [review]
patch

WTF, I midaired myself?
Attachment #194298 - Flags: review-
Comment on attachment 194462 [details] [diff] [review]
Proposed patch

This just starts the drag session before telling people about it ;-)

Feel free to r+sr or whatever is appropriate for this module.
Attachment #194462 - Flags: review?(roc)
Comment on attachment 194462 [details] [diff] [review]
Proposed patch

r+sr=me ... without this change:

>@@ -2764,14 +2765,12 @@
>   // code to keep the window from showing before it has been moved or
>   // resized
>   // if we are resized to 1x1 or less, we will hide the window.
>   // Show(TRUE) will be ignored until a larger resize has happened
>   if (aWidth <= 1 || aHeight <= 1)
>   {
>-    aWidth = 1;
>-    aHeight = 1;
>     mIsTooSmall = PR_TRUE;
>   }
>   else
>   {
>     mIsTooSmall = PR_FALSE;
>   }

which looks unrelated.
Attachment #194462 - Flags: superreview?(bryner)
Attachment #194462 - Flags: superreview+
Attachment #194462 - Flags: review?(roc)
Attachment #194462 - Flags: review+
Fix checked in to the trunk.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Comment on attachment 194462 [details] [diff] [review]
Proposed patch

Going by the comments I guess this crash fix should hit the branch too.
Attachment #194462 - Flags: approval1.8b5?
Attachment #194462 - Flags: approval1.8b4?
*** Bug 235838 has been marked as a duplicate of this bug. ***
can we get a trunk verification on this?
The new patch (194462) does not fix the problem. The system crashes exactly as
it did before. The older patch (194298) worked just fines.

Custom builds with both patches are available here:

http://tinyurl.com/93em4

I guess the status of this bug has to be changed, because it is NOT fixed.
I'm not crashing on Linux trunk build 2005-09-01-06-trunk.  But when I drag and
drop an xpi into the EM, it doesn't install the extension and I get the
following in the console:
(Gecko:4627): Gtk-CRITICAL **: file gtkdnd.c: line 643 (gtk_drag_get_data):
assertion `GTK_IS_WIDGET (widget)' failed
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
check that, Tbird *does* crash on close after trying to dnd an xpi to the EM.
Same behavior as before the patch for me with it sometimes crashing and never
installing the extension... crashes usually happen when quickly performing a DnD
or doing a 4 or 5 one after another. There are very few places where the drag
data is verified during a drag motion event in the tree and this is why this
works in the majority of the ui. attachment 194298 [details] [diff] [review] makes the extension ui only
use the drop event for validating the drag data as is used else where in the
tree just for UNIX where this problem exists. One other place that uses the drag
data from a drag motion event is the bookmarks manager which also is broken on
Linux when trying to DnD a local file onto it and it also crashed for me.
Attached patch wallpaper — — Splinter Review 
Neil, the patch didn't fix this so I'm re-requesting review for the wallpaper

related bugs... bug 122572, bug 161824, and bug 216800. These all appear to fix
the issue in drop but not in enter or over
Attachment #194594 - Flags: review?(neil.parkwaycc.co.uk)
Comment on attachment 194462 [details] [diff] [review]
Proposed patch

minusing since this patch doesn't seem to fix the problem.
Attachment #194462 - Flags: approval1.8b5?
Attachment #194462 - Flags: approval1.8b4?
Attachment #194462 - Flags: approval1.8b4-
Comment on attachment 194594 [details] [diff] [review]
wallpaper

Sorry, but I can't reproduce this any more.
Attachment #194594 - Flags: review?(neil.parkwaycc.co.uk)
Comment on attachment 194594 [details] [diff] [review]
wallpaper

Since the gtk dnd code doesn't work reliably / consistently with the versions
of gtk that are supported this seems appropriate until those issues are worked
out. Another option which I don't like is to not set the feedback correctly as
is done throughout much of the DnD ui code (e.g. on Win32 try DnD My Computer
to the bookmarks toolbar or content area).
Attachment #194594 - Flags: review?(mconnor)
Attachment #194594 - Attachment is obsolete: true
Attachment #194594 - Flags: review?(mconnor)
Attached patch patch (obsolete) — — Splinter Review 
Neil, I didn't spend a lot of time debugging this but this fixes this bug for
me and I am hoping you'd review this even though you are unable to reproduce
the crash. This just removes the 20ms sleep in GetTargetDragData for gtk2...
GetTargetDragData for gtk doesn't sleep in the corresponding while loop which
most likely explains why that doesn't cause a crash.
Attachment #194737 - Flags: review?(neil.parkwaycc.co.uk)
Comment on attachment 194737 [details] [diff] [review]
patch

I am going to just leave this open to anyone willing to review it.

BTW: this also fixes the crash when dnd'ng a file to the bookmarks manager.
Attachment #194737 - Flags: superreview?
Attachment #194737 - Flags: review?(neil.parkwaycc.co.uk)
Attachment #194737 - Flags: review?
Rob, you could try bryner, as he already reviewed my patch.
Comment on attachment 194737 [details] [diff] [review]
patch

turns out this just lessens the problem but doesn't fix it... I hate timers
like these.
Attachment #194737 - Flags: superreview?
Attachment #194737 - Flags: review?
Blocks: 297636
The DnD code for gtk is just fearful. The gtk_timeout_add is not reset some of
the time and will continue firing drag motion events when a drop doesn't occur.
Getting the number of dropped items returns one even when the data for the drop
is no valid. gtk_drag_get_data ends up being called when the widget used is null
which is usually the cause of the crash. This code is not happy.
OnDragMotionEvent gtk_timeout_add calls DragMotionTimerCallback in 100 ms which
calls FireDragMotionTimer which calls OnDragMotionEvent (e.g. gtk_timeout_add
again) and it fires the appropriate drag events. When dragging over without
performing a drop (e.g. canDrop is false as in this instance since the data
returned was invalid) OnDragLeaveEvent is not consistently called so the timer
keeps being re-added. Also, there is the drag_motion_event_cb callback which
returns OnDragMotionEvent as well... I haven't a clue why the timeout is needed
along with this since when I removed the timout it continued to work fine for
me. Anyways, this patch protects against the crash caused when asking for drag
data by checking mTargetWidget and mDoingDrag in GetTargetDragData. It also
removes the 20 ms sleep because by the time I had one call to GetTargetDragData
finish I would often find there were as many as 4 additional calls. With
GetTargetDragData waiting for the async return of the call to gtk_drag_get_data
which sets the value of mTargetDragData the additional calls would often end up
with data for a different flavor or no data for a flavor that exists... I am
pretty sure this is why I was seeing invalid data being returned in js. Take a
look at attachment #186835 [details] for an example.

This doesn't fix the runaway timeout... without knowing its purpose I'm
hesitant to remove it or attempt to fix it but from what I could tell it isn't
needed. The timeout was also not reset when dragging over the content window
but since the content window doesn't check the data until the drop occurs it
wouldn't cause a crash.
Attachment #194737 - Attachment is obsolete: true
Attachment #194903 - Flags: review?(bryner)
Comment on attachment 194462 [details] [diff] [review]
Proposed patch

Even though it doesn't fix the advertised bug I'd still like to see this on the
branch because there are other places in the code that expect the session to be
started before the drag enter fires, thus fixing at least one assertion.
Attachment #194462 - Flags: approval1.8b5?
hey guys, which patch is the one we want? 
Asa, as I see it changing GTK's DnD behavior however slight is a risky move for
1.8. I'd prefer going with just the simple null check to prevent the crash
without the removal of PR_Sleep as in attachment 194903 [details] [diff] [review] along with the wallpaper
in attachment 194594 [details] [diff] [review] so extensions and themes can be installed using DnD on
Linux. This would be IMO safe while preventing at least the crash condition I
found and allow DnD installation.
btw: comment #67 was not in relation to Neil's patch. When I looked it over it
does seem to be the right thing to do though it doesn't fix this bug for me.
Comment on attachment 194594 [details] [diff] [review]
wallpaper

mconnor - this is the wallpaper that covers the problem when DnD'ng on the EM
for Linux... it doesn't touch the GTK code which I think is going to need more
attention than can be given before 1.5
Attachment #194594 - Attachment is obsolete: false
Attachment #194594 - Flags: review?(mconnor)
Comment on attachment 194462 [details] [diff] [review]
Proposed patch

unsetting request on this patch. please request approval for the other patches
when they're reviewed
Attachment #194462 - Flags: approval1.8b5?
Attachment #194903 - Attachment is obsolete: true
Attachment #194903 - Flags: review?(bryner)
This bug also happens for me with my Thunderbird version 1.5 Beta 1 (20050908).
At some point the message pane isn't updated anymore and I closed Thunderbird.
Then the following not reproducable crash occurs:

TB: TB10421879X

Stack Signature	 0x00000209 5cf44a2a
Product ID	Thunderbird15
Build ID	2005090807
Trigger Time	2005-10-09 04:29:09.0
Platform	LinuxIntel
Operating System	Linux 2.6.13-kanotix-8
Module	
URL visited	
User Comments	
Since Last Crash	18 sec
Total Uptime	33 sec
Trigger Reason	SIGSEGV: Segmentation Fault: (signal 11)
Source File, Line No.	N/A
Stack Trace 	
0x00000209
nsWindow::OnDragMotionEvent() 
[/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/widget/src/gtk2/nsWindow.cpp,
line 1968]
nsWindow::FireDragMotionTimer() 
[/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/widget/src/gtk2/nsWindow.cpp,
line 4122]
nsWindow::DragMotionTimerCallback() 
[/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/widget/src/gtk2/nsWindow.cpp,
line 4146]
libglib-2.0.so.0 + 0x271d4 (0xb78d81d4)
libglib-2.0.so.0 + 0x25421 (0xb78d6421)
libglib-2.0.so.0 + 0x28687 (0xb78d9687)
libglib-2.0.so.0 + 0x28bd8 (0xb78d9bd8)
libgtk-x11-2.0.so.0 + 0x111989 (0xb7b76989)
nsAppShell::Run() 
[/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/widget/src/gtk2/nsAppShell.cpp,
line 141]
nsAppStartup::Run() 
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/toolkit/components/startup/src/nsAppStartup.cpp,
line 146]
XRE_main() 
[/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/toolkit/xre/nsAppRunner.cpp,
line 848]
main() 
[/builds/tinderbox/Tb-Mozilla1.8/Linux_2.4.18-14_Depend/mozilla/mail/app/nsMailApp.cpp,
line 63]
libc.so.6 + 0x14ec0 (0xb7412ec0)
Flags: blocking1.8.1?
changing summary - see the bugs this blocks for specific instances
Summary: crash when trying to drag and drop a saved extension into the extension manager - Fx and TB [@ JS_GetPrivate][@ nsWindow::OnDragMotionEvent] → crash when performing a drag and drop a saved in various parts of the ui [@ JS_GetPrivate][@ nsWindow::OnDragMotionEvent]
(In reply to comment #72)
> changing summary - see the bugs this blocks for specific instances
> 

"crash when performing a drag and drop a saved in various parts of the ui [@ JS_GetPrivate][@ nsWindow::OnDragMotionEvent]"

Maybe it was just a typo but I think the words "with" and "extension" should be added like this:

"a drag and drop with a saved extension in various parts"
(In reply to comment #73)
> Maybe it was just a typo but I think the words "with" and "extension" should be
> added like this:
> 
> "a drag and drop with a saved extension in various parts"
bug 309306 should have wallpapered this bug for the Extension Manager ui and the reporter of this bug confirmed that it did fix it for him.

This is a core bug with the gtk drag and drop code that can be see in various parts of the user interface. For example, bug 309298 is for the Bookmarks Manager where this same bug can also be seen.

If you are experiencing this bug with Firefox 1.5 or Thunderbird 1.5 in the Extension Manager please file a new bug with the Product Firefox and component Extension/Theme Manager and include steps to reproduce and the output from your console.
Summary: crash when performing a drag and drop a saved in various parts of the ui [@ JS_GetPrivate][@ nsWindow::OnDragMotionEvent] → crash when performing a drag and drop in various parts of the ui [@ JS_GetPrivate][@ nsWindow::OnDragMotionEvent]
Not going to block 1.8.1 for this bug, but we'll happily consider a baked-on-trunk patch.
Flags: blocking1.8.1? → blocking1.8.1-
*** Bug 355857 has been marked as a duplicate of this bug. ***
Testing with: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061003 Firefox/2.0 (clean profile)

It seems the problem has been somehow solved. I can drag and drop extensions in the add-ons manager, and the system performs perfectly. No hanging, no crashes.

Please reconfirm.
Nicola, I wallpapered the add-ons manager in bug 309306 until this bug is fixed.
I realized sometimes when by mistake drag something in browser to browser , on firefox 2 and seamonkey 1.1 on linux , browser crash and die.
Not always I can't reproduce the problem easily.
But is about drag somethings.
Depends on: 495343
Attachment 194462 [details] [diff] landed in comment 47.
The crashes with stacks in comment 12 and comment 71 are resolved in bug 495343.
Status: REOPENED → RESOLVED
Closed: 19 years ago → 13 years ago
Resolution: --- → FIXED
Crash Signature: [@ JS_GetPrivate] [@ nsWindow::OnDragMotionEvent]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: