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)
Core
DOM: UI Events & Focus Handling
Tracking
()
VERIFIED
FIXED
People
(Reporter: Matti, Assigned: kmcclusk)
References
()
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
Comment 1•24 years ago
|
||
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?
Reporter | ||
Comment 2•24 years ago
|
||
It crashed while I close the new window which isn´t finished loaded
Comment 4•24 years ago
|
||
Crashed in exactly the same way for me on Linux Build ID 2000121421
Comment 5•24 years ago
|
||
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
Comment 7•24 years ago
|
||
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)
Comment 8•24 years ago
|
||
No longer seeing this. Anyone?
Reporter | ||
Comment 9•24 years ago
|
||
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 !
Comment 10•24 years ago
|
||
I canNOT reproduce this on build 2000122904 on windows 98
Reporter | ||
Comment 11•24 years ago
|
||
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
Comment 12•24 years ago
|
||
*** Bug 64410 has been marked as a duplicate of this bug. ***
Comment 13•24 years ago
|
||
There are two Talkback reports from me, TB24433549K and TB24393430M, which
may be the same bug.
Comment 14•24 years ago
|
||
*** Bug 64683 has been marked as a duplicate of this bug. ***
Comment 15•24 years ago
|
||
Is this dependent on bug 52397, or maybe a dupe?
Comment 16•24 years ago
|
||
This one causes tons if crashes if you have a slow net connection; I just had 2
in the last 10 minuttes. Please fix.
Comment 17•24 years ago
|
||
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
Comment 18•24 years ago
|
||
*** Bug 65414 has been marked as a duplicate of this bug. ***
Comment 19•24 years ago
|
||
*** Bug 65460 has been marked as a duplicate of this bug. ***
Comment 20•24 years ago
|
||
I just got another crash which might be this bug.
Talkback TB24654008H, if that helps.
Comment 21•24 years ago
|
||
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
Comment 22•24 years ago
|
||
*** Bug 65756 has been marked as a duplicate of this bug. ***
Comment 23•24 years ago
|
||
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.
Comment 24•24 years ago
|
||
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.
Comment 25•24 years ago
|
||
Is this really joki's? We need to get some eyes on this...
Keywords: nsbeta1
Reporter | ||
Updated•24 years ago
|
Keywords: regression
Comment 26•24 years ago
|
||
*** Bug 66173 has been marked as a duplicate of this bug. ***
Comment 27•24 years ago
|
||
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
Comment 28•24 years ago
|
||
Joki is a black whole, so reassigning to kmcclusk.
Assignee: joki → kmcclusk
Assignee | ||
Comment 29•24 years ago
|
||
This bug should be fixed once the patch in bug 65243 is checked in.
Comment 30•24 years ago
|
||
*** Bug 66273 has been marked as a duplicate of this bug. ***
Comment 31•24 years ago
|
||
*** Bug 65405 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 32•24 years ago
|
||
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
Comment 33•24 years ago
|
||
*** Bug 66125 has been marked as a duplicate of this bug. ***
Comment 34•24 years ago
|
||
*** Bug 66446 has been marked as a duplicate of this bug. ***
Comment 35•24 years ago
|
||
*** Bug 66439 has been marked as a duplicate of this bug. ***
Comment 36•24 years ago
|
||
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 → ---
Reporter | ||
Comment 37•24 years ago
|
||
This seems to be fixed for me.
I can´t produce a crash with closing windows (while loading).
1012304 / win2k
Comment 38•24 years ago
|
||
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
Comment 39•24 years ago
|
||
*** Bug 66838 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 40•24 years ago
|
||
*** Bug 66853 has been marked as a duplicate of this bug. ***
Comment 41•24 years ago
|
||
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
Comment 42•24 years ago
|
||
*** Bug 67019 has been marked as a duplicate of this bug. ***
Comment 43•24 years ago
|
||
I still have this problem with Mozilla0.8 on Linux (buildid 2001011023)
should I reopen or have this been fixed after release?
Comment 44•24 years ago
|
||
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.
Updated•24 years ago
|
Keywords: mozilla0.8
Comment 45•24 years ago
|
||
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.
Updated•6 years ago
|
Component: Event Handling → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•