Closed Bug 39204 Opened 24 years ago Closed 23 years ago

ChatZilla (sometimes) crashes if you click on a link

Categories

(Other Applications :: ChatZilla, defect, P3)

x86
All
defect

Tracking

(Not tracked)

VERIFIED WORKSFORME

People

(Reporter: u12623, Assigned: rginda)

Details

(Keywords: crash)

Steps to reproduce:

1. Open chatzilla (chrome://chatzilla/content/)
2. Log into a network (/attach moznet)
3. Join a channel (/join #mozilla)
4. Post a URL
5. Click on this URL

Result: Mozilla crashes.
Expected result: Mozilla opens a new page with the URL loaded
Keywords: crash
2000052320 linux
Tasks->IRC Chat
/attach moznet
/join #mozillazine
http://www.mozilla.org
click
a new window with that url loads [asside from unrelated already bugged 
sidebar issues].
however the window scrolls up a bit.  I think this deserves a separate bug.
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
2000052408 NT

confirm WORKSFORME

:)
verified worksforme on linux i686 2000053019
Status: RESOLVED → VERIFIED
This bug currently occurs again on build 2000111404 for win32 on win2k I was
able to do this several times over the course of an afternoon.
[ 2000111408-Mtrunk linux-2.4.0-test10 i686 SMP ]

although middle/right-click doesn't work, left-click on the link opens a new
browser window and displays the page just fine.

adam: can you plase try this again with a more recent build & let us know if it
works?
This works sometimes, but you're guaranteed to crash eventually if you click on
enough links.  I'd guess on the order of 20, usually less.  I usually run
chatzilla from my release bits, so I don't yet have a stack trace.

Reopening because I'm sure there is still a problem here.
Status: VERIFIED → UNCONFIRMED
Resolution: WORKSFORME → ---
Summary: ChatZilla crashes if you click on a link → ChatZilla (sometimes) crashes if you click on a link
reproduced with linux debug build (Nov. 16 bits).  Stack trace:

#0  0x0 in ?? ()
#1  0x40e03800 in nsDocShell::Destroy (this=0x867f0a0) at nsDocShell.cpp:1691
#2  0x40e1fa0d in nsWebShell::Destroy (this=0x867f0a0) at nsWebShell.cpp:1395
#3  0x40e16dab in nsWebShell::~nsWebShell (this=0x867f0a0, __in_chrg=3)
    at nsWebShell.cpp:179
#4  0x40df8d2a in nsDocShell::Release (this=0x867f0a0) at nsDocShell.cpp:165
#5  0x40e17540 in nsWebShell::Release (this=0x867f0a0) at nsWebShell.cpp:273
#6  0x40e52a8b in nsURILoader::OpenURIVia (this=0x8145bd0, aChannel=0x8914ce8,
    aCommand=7, aWindowTarget=0xbffff554 "_content",
aOriginalWindowContext=0x8785c68,
    aLocalIP=0) at ../../dist/include/nsCOMPtr.h:699
#7  0x40e4fee9 in nsURILoader::OpenURI (this=0x8145bd0, aChannel=0x8914ce8,
aCommand=7,
    aWindowTarget=0xbffff554 "_content", aWindowContext=0x8785c68) at
nsURILoader.cpp:521
#8  0x40e0f340 in nsDocShell::DoChannelLoad (this=0x8785c68, aChannel=0x8914ce8,
    aLoadCmd=7, aWindowTarget=0xbffff554 "_content", aURILoader=0x8145bd0)
    at nsDocShell.cpp:3459
#9  0x40e0eab4 in nsDocShell::DoURILoad (this=0x8785c68, aURI=0x88e0a10,
    aReferrerURI=0x86197e8, aOwner=0x0, aInheritOwner=1, aLoadCmd=7,
    aWindowTarget=0xbffff554 "_content", aPostData=0x0, aHeadersData=0x0)
    at nsDocShell.cpp:3238
#10 0x40e0bf17 in nsDocShell::InternalLoad (this=0x8785c68, aURI=0x88e0a10,
    aReferrer=0x86197e8, aOwner=0x0, aInheritOwner=1, aStopActiveDoc=0,
    aWindowTarget=0xbffff554 "_content", aPostData=0x0, aHeadersData=0x0,
    aLoadType=2097153, aSHEntry=0x0) at nsDocShell.cpp:3002
#11 0x40e1aacd in nsWebShell::HandleLinkClickEvent (this=0x8785c68,
aContent=0x890cc90,
    aVerb=eLinkVerb_Replace, aURLSpec=0x8505880, aTargetSpec=0x89105a8,
    aPostDataStream=0x0, aHeadersDataStream=0x0) at nsWebShell.cpp:833
#12 0x40e1a0e0 in HandlePLEvent (aEvent=0x89643d8) at nsWebShell.cpp:691
#13 0x400f0f5e in PL_HandleEvent (self=0x89643d8) at plevent.c:576
#14 0x400f0df9 in PL_ProcessPendingEvents (self=0x80a5d68) at plevent.c:509
#15 0x400f2a50 in nsEventQueueImpl::ProcessPendingEvents (this=0x80a5d40)
    at nsEventQueue.cpp:356
#16 0x406b4daf in event_processor_callback (data=0x80a5d40, source=8,
    condition=GDK_INPUT_READ) at nsAppShell.cpp:158
#17 0x406b4a6d in our_gdk_io_invoke (source=0x81c60d0, condition=G_IO_IN,
data=0x81f5428)
#18 0x4086eaca in g_io_unix_dispatch () from /usr/lib/libglib-1.2.so.0
#19 0x40870186 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0
#20 0x40870751 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
#21 0x408708f1 in g_main_run () from /usr/lib/libglib-1.2.so.0
#22 0x40798c69 in gtk_main () from /usr/lib/libgtk-1.2.so.0
#23 0x406b5984 in nsAppShell::Run (this=0x80af1f8) at nsAppShell.cpp:335
#24 0x405d4fb5 in nsAppShellService::Run (this=0x80ac700) at
nsAppShellService.cpp:407
#25 0x80523fb in main1 (argc=1, argv=0xbffff8c4, nativeApp=0x0) at
nsAppRunner.cpp:1015
#26 0x8052d26 in main (argc=1, argv=0xbffff8c4) at nsAppRunner.cpp:1255
#27 0x403009cb in __libc_start_main (main=0x8052ba0 <main>, argc=1,
argv=0xbffff8c4,
    init=0x804c244 <_init>, fini=0x805edcc <_fini>, rtld_fini=0x4000ae60
<_dl_fini>,
    stack_end=0xbffff8bc) at ../sysdeps/generic/libc-start.c:92
Marking as NEW based on recent comments, and due to the fact this just happened
to me on Linux build 2000111921.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Arrgh, it happened to me two more times; CC'ing self.
I think this is fixed in the new chatzilla.  Is anyone still getting this?
I haven't heard any more reports of this, so marking worksforme.
Status: NEW → RESOLVED
Closed: 24 years ago23 years ago
Resolution: --- → WORKSFORME
Product: Core → Other Applications
If anyone's having this problem by now, it's unlikely that it's the same bug...
WFM also -> VERIFIED
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.