Closed Bug 39204 Opened 25 years ago Closed 24 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: 25 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: 25 years ago24 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.