Just start apprunner and click on "Channels". It opens a UI-windows which doesn't react in any way.

If you open the channel-window while the browser is maximized, you can neither close nor scroll through it, because the necessary elements are out of display range. If you click on any of the items in this UI-window, apprunner crashes

I crashed while repro'ing this bug. Two different ways: 1. maximize apprunner 2. click 'channels' folder icon on personal toolbar -->crash -or- if you don't crash after (2) restore the window size (popup is not dismissed) and then click 'channels' again -->crash reassigning to XPToolkit here the WinNT stack trace: nsWindow::SetFocus [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 1069] nsEventStateManager::PostHandleEvent [d:\builds\seamonkey\mozilla\layout\events\src\nsEventStateManager.cpp, line 246] PresShell::HandleEvent [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 1886] nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 835] nsViewManager::DispatchEvent [d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1611] HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 67] nsWindow::DispatchEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 502] nsWindow::DispatchWindowEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 523] nsWindow::DispatchMouseEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3273] ChildWindow::DispatchMouseEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3466] nsWindow::ProcessMessage [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 2529] nsWindow::WindowProc [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 572] USER32.dll + 0x1268 (0x77e71268) 0x005703c5

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

actually 11952 is not a dupe, my bad. Let's keep the crashing separate from the UI troubles.

Not our widget. Don?

Steve, is this our bug, or an XPToolkit issue?

I do not get any popups (or crashes) on Win32 or Linux. I will see if I can find a bug related to that.

This is turning out to be the top vote getter on talkback reports from M9 win32. I wonder if it was fixed post m9. Many reports on win32 for M9. Looks like stephendonner@earthlink.net has found a reproducible crash in m9, and has reproduced it many times.. ;-) who should own this? chris h. call stack looks like: Incident ID 12934867 nsWindow::SetFocus [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 1069] nsEventStateManager::PostHandleEvent [d:\builds\seamonkey\mozilla\layout\events\src\nsEventStateManager.cpp, line 246] PresShell::HandleEvent [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 1886] nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 835] nsViewManager::DispatchEvent [d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1611] HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 67] nsWindow::DispatchEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 502] nsWindow::DispatchWindowEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 523] nsWindow::DispatchMouseEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3273] ChildWindow::DispatchMouseEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3466] nsWindow::ProcessMessage [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 2529] nsWindow::WindowProc [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 572] KERNEL32.DLL + 0x363b (0xbff7363b) KERNEL32.DLL + 0x242e7 (0xbff942e7) 0x00638bfe line numbers have shifted around in the current source, but I think we are in here somewhere.... 939 rods 3.79 NS_METHOD nsWindow::SetFocus(void) 940 kipp 1.1 { 941 // 942 // Switch to the "main gui thread" if necessary... This method must 943 // be executed on the "gui thread"... 944 // 945 kmcclusk 3.77 nsToolkit* toolkit = (nsToolkit *)mToolkit; 946 if (!toolkit->IsGuiThread()) { 947 kipp 1.1 MethodInfo info(this, nsWindow::SET_FOCUS); 948 kmcclusk 3.77 toolkit->CallMethod(&info); 949 rods 3.79 return NS_ERROR_FAILURE; 950 kipp 1.1 } 951 952 if (mWnd) { 953 ::SetFocus(mWnd); 954 } 955 rods 3.79 return NS_OK; 956 kipp 1.1 }

This is turning out to be the top vote getter on talkback reports from M9 win32. I wonder if it was fixed post m9. Many reports on win32 for M9. Looks like stephendonner@earthlink.net has found a reproducible crash in m9, and has reproduced it many times.. ;-) who should own this? chris h. call stack looks like: Incident ID 12934867 nsWindow::SetFocus [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 1069] nsEventStateManager::PostHandleEvent [d:\builds\seamonkey\mozilla\layout\events\src\nsEventStateManager.cpp, line 246] PresShell::HandleEvent [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 1886] nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 835] nsViewManager::DispatchEvent [d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1611] HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 67] nsWindow::DispatchEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 502] nsWindow::DispatchWindowEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 523] nsWindow::DispatchMouseEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3273] ChildWindow::DispatchMouseEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3466] nsWindow::ProcessMessage [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 2529] nsWindow::WindowProc [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 572] KERNEL32.DLL + 0x363b (0xbff7363b) KERNEL32.DLL + 0x242e7 (0xbff942e7) 0x00638bfe line numbers have shifted around in the current source, but I think we are in here somewhere.... 939 rods 3.79 NS_METHOD nsWindow::SetFocus(void) 940 kipp 1.1 { 941 // 942 // Switch to the "main gui thread" if necessary... This method must 943 // be executed on the "gui thread"... 944 // 945 kmcclusk 3.77 nsToolkit* toolkit = (nsToolkit *)mToolkit; 946 if (!toolkit->IsGuiThread()) { 947 kipp 1.1 MethodInfo info(this, nsWindow::SET_FOCUS); 948 kmcclusk 3.77 toolkit->CallMethod(&info); 949 rods 3.79 return NS_ERROR_FAILURE; 950 kipp 1.1 } 951 952 if (mWnd) { 953 ::SetFocus(mWnd); 954 } 955 rods 3.79 return NS_OK; 956 kipp 1.1 }

This is turning out to be the top vote getter on talkback reports from M9 win32. I wonder if it was fixed post m9. Many reports on win32 for M9. Looks like stephendonner@earthlink.net has found a reproducible crash in m9, and has reproduced it many times.. ;-) who should own this? chris h. call stack looks like: Incident ID 12934867 nsWindow::SetFocus [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 1069] nsEventStateManager::PostHandleEvent [d:\builds\seamonkey\mozilla\layout\events\src\nsEventStateManager.cpp, line 246] PresShell::HandleEvent [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 1886] nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 835] nsViewManager::DispatchEvent [d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1611] HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 67] nsWindow::DispatchEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 502] nsWindow::DispatchWindowEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 523] nsWindow::DispatchMouseEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3273] ChildWindow::DispatchMouseEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3466] nsWindow::ProcessMessage [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 2529] nsWindow::WindowProc [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 572] KERNEL32.DLL + 0x363b (0xbff7363b) KERNEL32.DLL + 0x242e7 (0xbff942e7) 0x00638bfe line numbers have shifted around in the current source, but I think we are in here somewhere.... 939 rods 3.79 NS_METHOD nsWindow::SetFocus(void) 940 kipp 1.1 { 941 // 942 // Switch to the "main gui thread" if necessary... This method must 943 // be executed on the "gui thread"... 944 // 945 kmcclusk 3.77 nsToolkit* toolkit = (nsToolkit *)mToolkit; 946 if (!toolkit->IsGuiThread()) { 947 kipp 1.1 MethodInfo info(this, nsWindow::SET_FOCUS); 948 kmcclusk 3.77 toolkit->CallMethod(&info); 949 rods 3.79 return NS_ERROR_FAILURE; 950 kipp 1.1 } 951 952 if (mWnd) { 953 ::SetFocus(mWnd); 954 } 955 rods 3.79 return NS_OK; 956 kipp 1.1 }

It looks like something got lost inbetween this bug and bug 11952. That bug was supposed to be the crasher and I was going to track the UI issue here. This bug has received all the crash attention though. So, i'm going to dupe 11952 and we can just watch this one. When popups come back and don't crash then we can look into the UI troubles. cc'ing owner and reporter from 11952 because maybe hyatt should own this one?

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

upping severity. this went away before but is now back on all platforms as of the 19990921 builds. I'll choose a stack trace and post it in if it's any different from the previous ones (which i suspect). *To Repro - Click 'Channels' on Personal Toolbar -->CRASH.

so this works just about perfectly on all platforms now as of the 1999100110 builds. marking FIXED and VERIFIED

marking VERIFIED