User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3a) Gecko/20021208 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3a) Gecko/20021208 I had the mouse cursor lingering over a link (not sure if it had a tooltip on the link itself), when the browser simply crashed. Every attempt at reproducing failed. Mozilla trunk 2002120803, Mac OS X 10.2.2. Reproducible: Couldn't Reproduce Steps to Reproduce: 1. Unknown Actual Results: Browser crashed Expected Results: Browser no crash

Okay, this is now reproducible; was looking in the wrong area completely, considering how I reproduced it: 1. Start Mozilla, load a page with several links 2. Load (at least) three links in new tabs, for a total of four tabs 3. Save the original page (using keyboard shortcut, not menu) 4. Close original tab (again, with the keyboard shortcut) 5. Wait a couple seconds 6. Close the next tab (with kbd shortcut) 7. Go to 5 It usually crashed just after I closed the third tab, but sometimes after the second. The interesting thing is no tooltips were ever shown...

Hmm, can't reproduce with win32 trunk build (debug). I looked in talkback and there are only two crashes with that signature in the database, both with a 1.x branch build (actually, with Netscape 7.0).

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

crash log in bug 185020 looks different, but the symptoms are similar. any connection? -matt

If Mozilla OS X had Talkback, this bug would be shooting up the charts rapidly. My copy of 20021213 trunk just had 3 of these crashes today.

Has there been any progress? If Mozilla OSX had Talkback, this would easily be OSX top crasher.

In case it's useful, I'm able to still reproduce this on Fizilla/CFM 2003010208 as well as a personally-built Fizilla/Mach-O from CVS around 20030102; however, doing a debug build with the same code from CVS, I can't seem to get it to crash.

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

If there isn't progress on this bug soon, I'll have to give up using nightly builds. It's impossible to get any work done when my browser crashes every 10 minutes. Also, is this related to why tooltips (such as title tags) now linger for a full 5 seconds after I mouse out of the link? It's quite annoying, but not nearly as much as crashing all the time.

Changing summary, as most crash logs don't go beyond the DestroyTooltip line. Mach-O build 2003-01-05-07 still gave me a bunch of those crashes, with the exact same trace as in attachment 110595 [details]; it's basically unusable until I turn of the tooltips. I think bug 185020 should be marked a dupe -- hence also by transitivity bug 185440, which shows the same problem on BeOS.

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

Is this being reported only against FizzillaMach builds, or both Mach-O and CFM?

I first noticed it on CFM, but as I mention in comment 8 I can also crash the Mach-O (non-debug) version.

assuming bug 185020 (the one I'm seeing) is correctly a dup of this bug, I'm seeing this in trunk build 2003010503 on MacOS X 10.5.1 (and also 10.2.2). I've only seen it when closing individual forground tabs. If I close an entire window, I never crash. The number of tabs in the window is not relevant. If I right-click a tab and "close all other tabs", I never crash, regardless of the number of tabs. If I close just the foreground tab (right click close tab, or clicking the [x] or using accel-w), I crash frequently enough that I've stopped trying to close forground tabs except after I've just downloaded a build (to see if the bug is gone yet). I've got oodles of crash logs like http://bugzilla.mozilla.org/attachment.cgi?id=109123&action=view (from the bug dupped against this one)

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

All/all on basis of last dupe.

Bug 186882 is not a duplicate of this bug (or at least not the win32 aspect of that bug).

According to the stacktrace in bug 187329 (via bug 185020), this also happens on Mac OS 9.2.2. I see it several times a day, especially on Bugzilla. It has been my topcrash for over a month.

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

crash backtrace from Linux, current CVS build. OS should be changed: this is not a mac-bug only. I started seeing this stack - crashed some 15-20 times since yesterday. Usually when wheel scrolling around in bugs in bugzilla.

Setting All/All per comment 21, and bug 185020, comment 2.

I've seen this crash a couple of times today, both when I was using a mouse wheel to scroll.

blocking 1.3b.

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

I'm still seeing this and it's always when using the mouse wheel.

I haven't had this crash since I stopped using tabs a few days ago!! The crashes reported by me in Bug 189747 are all identical to the symptoms described here by "m_mozilla" in Comment 15 However, I also don't have a mousewheel on this machine, so I'm not saying there aren't 2 different aren't that can cause this crash.

I've seen this on two machines. One has a scroll wheel (Kensington TurboRing, USB) but I've never been using the scroll wheel when I crash. I think the scroll wheel concern is either a separate bug, or a different way of manifesting the same bug. Tab closing is certainly the critical step for me. -matt

I currently can't reproduce this with the steps given in comment 2. Suggestions?

I also tried the steps in bug 189747 comment 1. Where is your mouse cursor when you do these things?

Open a bugzilla window and command-click on a link. Close the tab before it's completely loaded. I haven't found a real pattern like in comment 2, but my odds are normally 2 or 3 in 10 that I'll crash about 3 seconds later. Sometimes much faster (tabbed browsing becomes impossible), sometimes I don't see it for hours. I noticed that I'm safe to close a tab, when I wait until a tab is completely loaded and I wait a few extra seconds (about 3). It feels like the auto-hide timeout for the tooltip that fires after a tab is closed. Could this be a regression from bug 183604 ? As fire as I remember, I started noticing these crashes around the same time that bug 183604 was checked in. I could be a coupel of weeks wrong though.

my mouse cursor is in the page content rendering area. No pages need to be loading for this crash to happen for me. MacOS X build 2003012213 Just open a bunch of tabs, click on the right-most tab, start reading pages and hitting accel-W to close tabs as I finish reading each page. A few tabs close, but then I crash. If it would help, I can post an ordered list of URLs for the tabs and use the latest nightly. -matt

on linux, i didn't see this crash till after the fix for bug 185965 / bug 185889 was checked in.

i can reproduce this 100% reliably like this: -Open "View Bugs Already Reported Today" link at http://bugzilla.mozilla.org -From that page, open any bug in a tab -Select the new tab -Mouse over it so the tooltip appears -Move mouse down AWAY from the tooltip, and then back up again BEFORE the tooltip vanishes -Now close the tab (i middle mouse click) and immediately wheel-scroll down in the main bugpage crash

using steps-to-reproduce in comment 34, I was able to crash a binary .mozilla.org build, but a debug build worked fine. However, a few times, it gave this javascript exception when I closed the tab sometimes: * Call to xpconnect wrapped JSObject produced this error: * [Exception... "'[JavaScript Error: "event.originalTarget has no properties" {file: "chrome://navigator/content/navigator.js" line: 243}]' when calling method: [nsIDOMEventListener::handleEvent]" nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)" location: "JS frame :: chrome://global/content/bindings/tabbrowser.xml#tabbrowser.removeTab() :: removeTab :: line 62" data: yes]

produced with the steps-to-reproduce from comment 34

This is showing up as the main topcrash on Linux now that we have some talkback data again. (Although I can only get one stack per signature, the example stacks for both of the "random numbers" that showed up prominently point to this bug.)

Next time someone catches this in the debugger it might be good to note on the bug exactly what's at the line where it's crashing and (if it's clear) what would cause it to crash at that line. However, here's a wild guess. This changes nsRootBoxFrame::mDefaultTooltip into an owning pointer. It also does a little bit of cleanup. If someone can reproduce the bug reliably, it might be interesting to try this (although I only guessed what the problem is based on line numbers that might be off).

got this using y'day's linux build (2003.01.28.05). iirc, i've been seeing this quite frequently with the mach-o (commercial) builds, too (via crash reporter), especially while closing tabs (but not all the time). nominating.

Built with the patch in attachment 112979 [details] [diff] [review] - no change really. Still crashes easily, with the steps in comment 34. (stack looks longer than my comment 21, but i saw that same "longer" stack when getting this crash yesterday.)

> it might be good to note on the bug exactly what's at the line where it's > crashing and (if it's clear) what would cause it to crash at that line. see attachment 112947 [details]. the last frame is garbage, but the frame before that is at http://lxr.mozilla.org/mozilla/source/layout/xul/base/src/nsXULTooltipListener.cpp#651 (nsXULTooltipListener::DestroyTooltip() calling KillTooltipTimer()) gdb said that |mTooltipTimer| was non-null and |mTargetNode| was null. is there any way to tell if |mTooltipTimer| is pointing at garbage?

I'm trying to reproduce this on my linux build, no luck yet. it seems like a possibly related by how tooltip on linux don't dismiss themselves as agressively as they do on win32.

Adding testcase keyword since we have steps to reproduce this in comment #34 and making this a topcrash+ bug.

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

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

Patch http://bugzilla.mozilla.org/attachment.cgi?id=112979&action=view don't help. Crash on wheel-scroll fcff8628 ee17dba5 nsXULTooltipListener::DestroyTooltip(void) + 000002bd fcff8680 ee17d021 nsXULTooltipListener::HideTooltip(void) + 00000115 fcff86c0 ee17ba7d nsXULTooltipListener::HandleEvent(nsIDOMEvent *) + 00000135 fcff8788 ee1cdd36 nsEventListenerManager::HandleEventSubType(nsListenerStruct *, nsIDOMEvent *, nsIDOMEventTarget *, unsigned int, unsigned int) + 00000356

Too wide event scope for scroll-wheel or for tooltips listener. At least in BeOS port. Crash of Mozilla happened for me when i scrolled another app, which partially overlapped background mozilla window.

Adding 0x00000000 stack signature to summary...this crash is showing up under that also.

So, what do we know about when this bug started? It was clearly before the bug was filed, but is it possible to figure out (roughly, even) the latest build in which this bug was not present?

From talking to Asa it sounds like this bug only recently got exposed on Linux. Before then it was confined to Mac OS X builds, though there is an August 2002 build crash in talkback with the same signature.

Well, I'll have to admit that my change to nsXULTooltipListener on Dec 3 and this bug's filing on Dec 8 don't leave me with a comfortable feeling. But, this bug was absolutely limited to OS/X (and BeOS) prior to jkeiser's change to fix tooltips not going away onmouseout (bug 185889, bug 185965). Does backing out my change avoid the crash?

I could reproduce it almost every time (maybe needed 2 tries) with the steps in comment 34, both in recent nightly and my own build. After I backed out http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&branch=&branchtype=match&dir=&file=&filetype=match&who=jrgm%25netscape.com&whotype=match&hours=2&date=explicit&mindate=12%2F03%2F2002&maxdate=12%2F04%2F2002&cvsroot=%2Fcvsroot I could not reproduce it anymore.

Would it be reasonable to back that patch out for 1.3b? Or do we know of a fix?

Restoring KillTooltipTimer in summary, since comments 1, 41, and 52 clearly point at it.

Can we get a little more confirmation that backing out rev 1.19 of nsXULTooltipListener.cpp cures this crash (especially that it does so on Mac OS/X).

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

I wonder if the patch just filed in bug 156764 might help here?

This is some analysis of some talkback info jag sent me. From reading the disassembly and the stack dump it should be possible to figure out the values of local variables, etc., if you want them. But I haven't bothered since it seems like the cause is known by now.

Oh, I forgot the dissassembly of KillTooltipTimer itself (objdump -d on libgklayout.so is really slow to scroll through, so I'm putting it here in case we want it): 2e3408: 55 push %ebp 2e3409: 89 e5 mov %esp,%ebp 2e340b: 56 push %esi 2e340c: 53 push %ebx 2e340d: e8 00 00 00 00 call 0x2e3412 2e3412: 5b pop %ebx 2e3413: 81 c3 96 da 36 00 add $0x36da96,%ebx if (mTooltipTimer) { 2e3419: 8b 75 08 mov 0x8(%ebp),%esi 2e341c: 8b 56 28 mov 0x28(%esi),%edx 2e341f: 85 d2 test %edx,%edx 2e3421: 74 16 je 0x2e3439 mTooltipTimer->Cancel(); 2e3423: 8b 02 mov (%edx),%eax 2e3425: 52 push %edx 2e3426: 8b 40 20 mov 0x20(%eax),%eax 2e3429: ff d0 call *%eax mTargetNode = nsnull; 2e342b: 8d 46 20 lea 0x20(%esi),%eax 2e342e: 83 c4 04 add $0x4,%esp 2e3431: 6a 00 push $0x0 2e3433: 50 push %eax 2e3434: e8 13 63 ee ff call 0x1c974c ; restore stack pointer and return 2e3439: 8d 65 f8 lea 0xfffffff8(%ebp),%esp 2e343c: 5b pop %ebx 2e343d: 5e pop %esi 2e343e: c9 leave 2e343f: c3 ret

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

backout the nsXULTooltipListener.cpp checkin also fixed it for me (linux), but tooltips now hide properly due to bug 190767 (see bug 185965), so the crash is no longer reproducible. is this still a problem for OS X?

macos x trunk build 2003020103 tested it a bit and the bug seems to be gone happy day :) -matt

On m_mozilla's note I grabbed the 2003020103 nightly (OS X MachO) but I've had this crash already during routine use (did not try to break it): http://placenamehere.com/Mozilla/tooltipcrash.20030201.txt (quite to opposite of happy day... for entirely different reasons)

Ain't fixed for me either. (Nor do I see why it should be, from the patch in bug 190767.) Went to news.google.com, opened a few tabs, started reading them from the right; about 2'' after I closed the second one down, mozilla-mac-MachO.dmg.gz (2002-02-01-03) crashed with the usual stack trace.

Unable to test the latest MacOS X build until the launch crash bug 191533 is fixed so I don't know how anyone can claim the Mac build is fixed if the application fails to launch.

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

Since that patch hasn't been backed out yet, it's quite expected that you're still crashing in today's build.

I backed out the tooltip timer changes. Please update if this completely solves whatever remains of this crash on os/x and beos.

Mach-O 2003-02-04-03 looks good so far... Tab-closing routines that crashed the browser before, no longer seem to.

also trunk Mach-O 2003-02-04-03 not able to reproduce bug with the usual browsing habits (and I tested more extensively than with my earlier false negative report) -matt

4-5 hrs of intentionally heavy tab usage and no crashes with MachO 1003020403... With previuos builds and light tab usage I would have crashed inside half hour... think you isolated it.

I'm not seeing this on linux anymore either. Talkback has zero incidents today (we were getting 20-50 a day just a few days ago). I think this one is fixed. Pulling off of the blocking1.3beta radar.

Might the wondrous absence of Linux crash incidents during the last few days be connected to bug 191565? That one was about the absence of the real talkback.xpi in Linux builds during the first three days of February.

I too have been unable to reproduce this bug in 2003020403, either by my original method of crashing it, or the one in comment 34, which was able to crash a personal build from CVS a couple days ago.

Andreas: looks like the crashes on linux and windows are gone for real, and now with jrgm's backout the mac crashes seem gone too. Marking this WFM, since we're gonna deal with getting jrgm's patch back in (without the crashes) in bug 181961.

No more crashes on BeOS. Built from 12.Jan.2003 sources

sorry. Must be 12.Feb.2003 in http://bugzilla.mozilla.org/show_bug.cgi?id=184363#c76

Of particular note: - mTooltipTimer {...} + mRawPtr 0xcdcdcdcd if (mTooltipTimer) { mTooltipTimer->Cancel(); //crashed here

Chris, can you reproduce reliably? Can you see whether the destructor is being entered twice or something?

(In reply to comment #80) > Chris, can you reproduce reliably? Can you see whether the destructor is being > entered twice or something? I crashed again. I still don't know how to reproduce it, but I added a printf to the destructor per your suggestion. Hopefully that sheds some light on this.

was mousing over a bugzilla query-result-page link when the disk suddenly acted up, worked a lot, and Mozilla crashed: TB4001198K

requesting blocking 1.8b5 since this is the #1 crasher now for 1.5branch, deer park alpha 2 and 1.0.x releases.

Kurt: Do you have any evidence to support your claim that this is the #1 crasher? I don't see too many incidents with that function in the stacksignature: http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=nsXULTooltipListener&vendor=All&product=All&platform=All&buildid=&sdate=&stime=&edate=&etime=&sortby=bbid Most of those crashes are in Firefox 1.0.6 (which is off the Aviary 1.0.1 branch, on which we don't plan on fixing any non-security related bugs going forward). There definitely isn't enough Talkback data to suggest this is a topcrasher on the current Trunk or Deer Park/Firefox 1.5 branch. With that said, unless anyone can consistently reproduce this with the latest nightlies, this one might not be looked at for a while.

minusing per Jay's comments about this not showing up as a top crash report. We can reconsider if it shows up more after beta 1.

kurt: i hope you don't think that all 0x00000000 crashers are this.

I managed to crash here twice today. Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20051008 Firefox/1.4.1

too late to block on non-topcrashers that aren't zero or near-zero risk.

This is the 14th top crasher according to Talkback.

I see it at number 77 in beta2 reports and number 138 in beta1 which is probably more accurate at this point since we have so many more total reports there. It's at number 91 in the branch nightly builds.

It seems TB12892934 is related to this? (It's not mine, but I found it when looking for ChatZilla-related crashes). Hope this helps.

I had this crash yesterday: TB14825125Z Seems to be related...

talkback is showing very few nsXULTooltipListener::KillTooltipTimer related crashes on 1.5.x releases, but nsXULTooltipListener::DestroyTooltip() still exist in pretty good numbers. Comments for the crashes seem to point actions around open/closing tabs and windows with tooltips visible. Maybe with some hard work we could build a reproducable test case out of these actions combined with content from the sites listed and other comments. I appears like it might be slightly easier to see the crash on Mac, but there plenty of evidence of this on all platforms Here a dump of what people think they were doing when hitting crashes that look like c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/layout/xul/base/src/nsXULTooltipListener.cpp, line 646 Stack Trace nsXULTooltipListener::DestroyTooltip [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/layout/xul/base/src/nsXULTooltipListener.cpp, line 646] nsXULTooltipListener::HideTooltip [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/layout/xul/base/src/nsXULTooltipListener.cpp, line 539] nsTimerImpl::Fire [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/xpcom/threads/nsTimerImpl.cpp, line 394] nsAppStartup::Run [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/toolkit/components/startup/src/nsAppStartup.cpp, line 151] main [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/browser/app/nsBrowserApp.cpp, line 61] KERNEL32.DLL + 0x87f5 (0x7c4e87f5) Actions: hovering over links, other content, and UI elements that generate tool tips plus clicking on links to load new pages closing multiple tabs changing tabs scrolling down a webpage with mouse hit Alt-W multiple times in rapid succession to close multiple tabs Trying to close a tab in a window with lots of tabs. Going to close Firefox Build IDs and Content MozillaOrgFirefox15Win322006011112 using Gmail http://www.digg.com Using the digg tool bar to browse stories http://apple.com http://www.jeep4x4center.com http://aol.com http://space.com http://www.advertising.com http://www.dig.com http://alpha.uhasselt.be http://www.yahoo.com browsing through delicious feeds htttp://www.radiorock.it MozillaOrgFirefox15MacOSX2006011112 http://flickr.com - Closing a tab. Browsed pictures on flickr.com MozillaOrgFirefox15LinuxIntel2005111116 During file-upload via fire-ftp-plugin I hoveredover a link to test the title-attribute. http://kde-look.org downloading icon theme MozillaOrgFirefox15MacOSX2006011112 moving a toolbar link around MozillaOrgFirefox15LinuxIntel2006012415 I have FlashGot activated (with Downloader for X (nt)) and download of a zip archive caused the crash after confirmation of the app to be used MozillaOrgFirefox15MacOSX2006011112 http://www.vintage-radio.net/forum/ http://stylistes-ongulaires.forumactif.com/viewtopic.forum?p=12571#12571 Opening a new tab http://forums.flightinfo.com/ Had closed a tab, and started to scroll down to open another link. Spinning wheel, then the app quit. downloading a pdf file opening a pdf I was closing a tab for a pdf file after saving the file https://secure.eff.org/site/PremiumSelector?CAMPAIGN_ID=1102&JServSessionIdr010=pnpmv4j7n4.app2a I pressed the "4th amendment shipping tape" link (don't remember if I opened in a new tab or not) and when I went back to the URL presented above (or if I closed the overlaying tab) firefox crashed. Not a very good report, but I don't know if you can tell I was bookmarking a page by dragging the url into the viable book mark area. using weather plugin forecastfox de.wikipedia.org Loading several pages in new tabs and clicking somewhere within the active tab crash closing other tabs okay to closing multiple tabs dialog closing window http://www.cnet.com browsing the net - tried to close the window, then firefox quit the download window - redownloading things in the download window http://www.apc.fr - Browsing the site. http://www.wikipedia.org/Zodak Switching between tabs. browsing with multiple tabs http://www.crystalweb.org the link bottom left to verein http://www.polygon.at made FF crash http://www.garageband.com/artist/loren_schulte/podcast/newsletter Closing window using command w opening a fourth tab as a link from within my email Logging out of an email account http://www.cloudynights.com - Browsing multiple threaded discussion forums using tabs. Crashed shortly after closing one tab and displaying next. http://www.writely.com http://www.deviantart.com Browsing the Deviant Arts site In Firefox I have noticed the page up and page down keys no longer function even though they work fine in all my other apps. Is there a way to save my important data and clean any damaged files and do a fresh intall of http://browse.deviantart.com/?startts=1142150422&endts=1142236822&view=2&order=9&type=browse&offset=600 http://www.macys.com - looking at the website. http://patagonia.com reading articles in the New York Times http://www.nytimes.com i just wanted to open a new URI boston globe website http://www.cs.haverford.edu/curriculum/courses/cmsc101/lab2.template.html using google http://rangefinderforum.com/modules.php?name=Active_Topics Reading a message thread. No action had been initiated at the moment of the discontinuity. Pehaps delayed response to opening a message thread... http://www.sxsw.com Clicking on the Bookmark menu to select another site http://movabletype.org/support Reading an online Movable Type forum new art sales site: http://store.itsartmag.com/ http://www.cnn.com clicking on a link http://cbhomesale.com - closing a window http://forum.rpg.net Browsing forum.rpg.net

A "Stack (top 5 frames)" Talkback search shows hundreds of nsXULTooltipListener::DestroyTooltip crashes in a two-day period. It is a topcrash for Firefox 1.5.0.x -- it would be one of the top 30 crashes if bogus-address-on-top crashes were counted correctly (bug 304769). Some examples: TB17632637 TB17615360 TB17615175 - this one looks like bug 334177 and might be unrelated TB17631650 Btw, I see a "kungFuDeathGrip(this)" in nsXULTooltipListener::DestroyTooltip :( Bug 329937 explains why that makes me sad.

The kungFuDeathGrip was added in bug 265962.

Will consider a patch.

Some incidents, such as syskin's TB18387903, contain nsXULTooltipListener::HideTooltip but not nsXULTooltipListener::DestroyTooltip. I'm guessing it's the same crash.

This has been nominated for the 1.8.0 branch, is a patch realistic for that branch?

This has been around for a long time and we are still seeing a good number of crashes coming in... so let's try to whip up a patch.

I've spent quite a bit a time investigating this bug, but haven't yet found a way to reproduce it.

Not going to block 1.8.1 for this since we've shipped with this crash before and it does not appear to show up with very high frequency in the talkback reports for 1.5.0.x. Of course, if someone comes up with a patch, we'd be happy to consider it.

Darin, this does appear with high frequency if you do the right search. See comment 94.

Until we get a better handle on comment #100 (reproducibility) we can't block on this. We should continue to investigate and would love a fix.

This helps on trunk, but branches have still other tooltip related crashes.

Adding another kungFuDeathGrip(this) makes me sad :( See comment 94.

(In reply to comment #107) > Adding another kungFuDeathGrip(this) makes me sad :( See comment 94. > IMHO, kungFuDeathGrips aren't always bad. Just usually ;)

though, in this case kungFuDeathGrip can be also in nsXULTooltipListener::sAutoHideCallback

We _could_ addref the callback object we pass to the timer before doing so and release it here... That would keep the object from going away while the timer is live, though, so may not be desirable.

Comment on attachment 230873 [details] [diff] [review] kungFuDeathGrip to nsXULTooltipListener::sAutoHideCallback This fixes the crash now also in 1.8.

Comment on attachment 230873 [details] [diff] [review] kungFuDeathGrip to nsXULTooltipListener::sAutoHideCallback Please request approval once this is reviewed and landed as appropriate.

Comment on attachment 230873 [details] [diff] [review] kungFuDeathGrip to nsXULTooltipListener::sAutoHideCallback Checked in to trunk, asking approval for 1.8.1.

Comment on attachment 230873 [details] [diff] [review] kungFuDeathGrip to nsXULTooltipListener::sAutoHideCallback a=dbaron on behalf of drivers. Please land on MOZILLA_1_8_BRANCH and add the fixed1.8.1 keyword once you have done so.

Comment on attachment 230873 [details] [diff] [review] kungFuDeathGrip to nsXULTooltipListener::sAutoHideCallback approved for 1.8.0 branch, a=dveditz for drivers

Marking fixed. I'll look at TB to see whether there are still other crashes related to tooltips.

v.fixed on 1.8.1 and 1.8.0 branches with latest nightlies, no crash with testcase.