Closed Bug 62643 Opened 24 years ago Closed 24 years ago

crash closing window (most frequent while image is loading)

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: Matti, Assigned: kmcclusk)

References

(
URL
)

Details

(Keywords: crash, regression)

This crash is 100% reproduceable on my system. Using build 2000120920 / Win2k / fresh Profile Load the Url. Click on one of the "Screenshot" Images in the right section. A new window will opend. Close this window if the image in the new window is loading -=> crash. Talkback: TB22813684H
Doesn't affect Linux 2000120808... I tried closing the new window and the existing window with no ill-effects Reporter: can you clarify which window closure causes the crash, the new window (with screenshot) or the existing webpage window?
It crashed while I close the new window which isn´t finished loaded
Is this bug related to bug 62643 ?
Crashed in exactly the same way for me on Linux Build ID 2000121421
Depends on: 62738
TalkBack report's this stacktrace. 0x17e63842 PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 577] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 513] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 1055] nsAppShellService::Run [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp, line 408] main1 [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1023] main [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1263] WinMain [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1281] WinMainCRTStartup() KERNEL32.DLL + 0x192a6 (0x77e892a6)
Assignee: asa → scc
Status: UNCONFIRMED → NEW
Component: Browser-General → XPCOM
Ever confirmed: true
QA Contact: doronr → kandrot
*** Bug 62738 has been marked as a duplicate of this bug. ***
No longer depends on: 62738
All/ALL Changed summary because it is not restricted to particular condition.
Severity: normal → critical
Keywords: crash
OS: Windows 2000 → All
Hardware: PC → All
Summary: crash closing window while image is loading → crash closing window (most frequent while image is loading)
No longer seeing this. Anyone?
yes, I see this. But not at the posted URL. New URL: http://mitglied.tripod.de/UncleEiwi/index800x600.html close the little popop windows. Close the main page while loading. A new window (onexit) will opend. Close this window before finished loading. I have a crash there. I don´t know if this is another bug !
I canNOT reproduce this on build 2000122904 on windows 98
I see the crash at the posted URL with build 2001010310 / win2k. (http://www.counter-strike.de/hlinside/cross.shtml) You must close the new window very fast, after the screenshot begin to load
*** Bug 64410 has been marked as a duplicate of this bug. ***
There are two Talkback reports from me, TB24433549K and TB24393430M, which may be the same bug.
*** Bug 64683 has been marked as a duplicate of this bug. ***
Is this dependent on bug 52397, or maybe a dupe?
This one causes tons if crashes if you have a slow net connection; I just had 2 in the last 10 minuttes. Please fix.
Nominating for mozilla0.8, this is causing a lot of our recent crashes (not that it crashes often, but this one is reported often)
Keywords: mozilla0.8
*** Bug 65414 has been marked as a duplicate of this bug. ***
*** Bug 65460 has been marked as a duplicate of this bug. ***
I just got another crash which might be this bug. Talkback TB24654008H, if that helps.
This has nothing to do with XPCOM as far as I can see. Reassigning to Event Handling which is showing up on the stack trace.
Assignee: scc → joki
Component: XPCOM → Event Handling
QA Contact: kandrot → lorca
*** Bug 65756 has been marked as a duplicate of this bug. ***
A good very test case is http://www.fortify.net. Closing the "A word from our sponsors" window before the animated graphic fully loads is a sure Mozilla killer. This is the first occurence of the bug I've seen some months ago. It's still with us. Tested with 2002011120 Win32 Installer build.
I can hit this bug reliably on www.cnn.com. I'm using Mozilla built with PSM from a CVS pull on 2001/01/18 @ ~11:00 am AST. I'm using it on an SS20 w/ Sol8, which, being a comparatively slow machine, can take a bit when opening new windows. CNN pops open a window asking you to choose your "edition". If I close this window before the content has a chance to render, Mozilla crashes. I can also cause this if I close a "You need this plugin" window before it fills in. I get the following stack trace (which seems to agree with the talkback below...): #0 0xed0c0034 in FrameManager::HandlePLEvent () from /usr/local/tmp/mozilla/mozilla/dist/bin/components/libgklayout.so #1 0xef611ffc in PL_HandleEvent () from /usr/local/tmp/mozilla/mozilla/dist/bin/./libxpcom.so#2 0xef611f30 in PL_ProcessPendingEvents () from /usr/local/tmp/mozilla/mozilla/dist/bin/./libxpcom.so #3 0xef612d68 in nsEventQueueImpl::ProcessPendingEvents () from /usr/local/tmp/mozilla/mozilla/dist/bin/./libxpcom.so #4 0xee3a47ec in nsAppShell::SetDispatchListener () from /usr/local/tmp/mozilla/mozilla/dist/bin/components/libwidget_gtk.so #5 0xee3a44fc in keysym2ucs () from /usr/local/tmp/mozilla/mozilla/dist/bin/components/libwidget_gtk.so #6 0xedf60570 in g_io_unix_dispatch () from /opt/sfw/lib/libglib-1.2.so.0 #7 0xedf645dc in g_main_dispatch () from /opt/sfw/lib/libglib-1.2.so.0 #8 0xedf653d0 in g_main_iterate () from /opt/sfw/lib/libglib-1.2.so.0 #9 0xedf6576c in g_main_run () from /opt/sfw/lib/libglib-1.2.so.0 #10 0xee1a4eb4 in gtk_main () from /opt/sfw/lib/libgtk-1.2.so.0 #11 0xee3a4dd4 in nsAppShell::Run () from /usr/local/tmp/mozilla/mozilla/dist/bin/components/libwidget_gtk.so #12 0xee4dc964 in nsAppShellService::Run () from /usr/local/tmp/mozilla/mozilla/dist/bin/components/libnsappshell.so #13 0x16744 in NS_CreateNativeAppSupport () #14 0x17108 in main () Sorry I don't have line numbers, getting a stack trace from gdb with all the debugging symbols in Mozilla really is not a trivial operation VM-wise.
Is this really joki's? We need to get some eyes on this...
Keywords: nsbeta1
Keywords: regression
*** Bug 66173 has been marked as a duplicate of this bug. ***
This is getting lots of dups, adding mostfreq keyword. Is this related to bug 53704, as jg@jmkg.net suggested in bug 66125?
Keywords: mostfreq
Joki is a black whole, so reassigning to kmcclusk.
Assignee: joki → kmcclusk
This bug should be fixed once the patch in bug 65243 is checked in.
*** Bug 66273 has been marked as a duplicate of this bug. ***
*** Bug 65405 has been marked as a duplicate of this bug. ***
I can't reproduce this bug in the current build. Looks like the patch for 65243 fixed it. Marking it fixed.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
*** Bug 66125 has been marked as a duplicate of this bug. ***
*** Bug 66446 has been marked as a duplicate of this bug. ***
*** Bug 66439 has been marked as a duplicate of this bug. ***
Uh, it is still crashing in 2001012413 Mac Build. The stacktrace is the same as before. Reopening. Please close if the build is wrong.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This seems to be fixed for me. I can´t produce a crash with closing windows (while loading). 1012304 / win2k
It looks like bug 58728 had something to do with closing windows, too. Now I do not get crash on closing child windows while loading. Marking fixed in 2001012510 build.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
*** Bug 66838 has been marked as a duplicate of this bug. ***
*** Bug 66853 has been marked as a duplicate of this bug. ***
Reassigning QA Contact for all open and unverified bugs previously under Lorca's care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
*** Bug 67019 has been marked as a duplicate of this bug. ***
I still have this problem with Mozilla0.8 on Linux (buildid 2001011023) should I reopen or have this been fixed after release?
I haven't seen this problem in 0.8 at all. Are you sure this is the same crash? A stack trace would help identify it as such.
Keywords: mozilla0.8
I've just reproduced a close varient of this bug. First, go to the preferences menu, and select section Advanced -> images. Enable option "Alert me before downloading an image." Load any page that contains an image. Instead of answering yes or no to the alert box, close the browser window instead. Once the browser window is closed, answer the question posed by ths dialogue box. Guarenteed crash, as reported in talkback TB26863162Z.
verified fixed
Status: RESOLVED → VERIFIED
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.