Adium

Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#7585 closed defect (fixed)

ToolTip Window Leak/Blank Tool tip windows show up & never fade from the screen.

Reported by: milkandhoneybunny Owned by: Catfish_Man
Milestone: Adium X 1.1.2 Component: Adium Core
Version: Severity: normal
Keywords: Tool Tip, Tool Tip Box, Tool Tip won't, tool tip stuck Cc:
Patch Status:

Description

In the newest version of Adium as of 8-14-07 I have noticed that if you hover over a name in your contacts list a tool tip box will show up but it is blank accept for the users icon pic. After moving your mouse away the box it still there and never fades back into invisibility. I have to restart adium to get rid of it. Since then I have turned off my tool tips and can no longer spy on what my friends are doing (in there away messages) :-(

Attachments (1)

wip05.jpg (278.2 KB) - added by typ0 13 years ago.
in Adium 1.1.2

Download all attachments as: .zip

Change History (19)

comment:1 Changed 13 years ago by Raptor007

I too encounter this bug, now in Adium 1.1.1, where the hover window (that appears when you mouse over a contact in the list) can get stuck on. Sometimes this can cause Adium to crash when it happens.

I've been trying to recreate it with these steps:

  1. Bring the contact list into focus.
  2. Hover over a buddy, then immediately (before/as the hover window appears) click another application's window.

But usually this causes Adium to crash (probably another symptom of the same bug). I haven't found a way to reliably recreate the stuck buddy windows, but it happens often enough on its own to be quite annoying.

comment:2 Changed 13 years ago by David Smith

Milestone: Needs feedback from users

This appears to be caused by the SetAlphaValue hack. Uninstalling it should fix the crash, at least, and possibly the other issue. Please let us know if that works.

http://smartcrashreports.com/dev/crash.php?id=5e7d1cba9a07b958c2e7e130fceca10d95039afb

comment:3 Changed 13 years ago by Evan Schoenberg

This appears to be caused by SetAlphaValue from parrotsoftware. Please uninstall that from /Library/InputManagers or ~/Library/InputManagers or ~/System/Library/InputManagers and see if the problem is resolved.

If so, contact the author of that input manager with the problem. If not, please reopen this ticket.

comment:4 Changed 13 years ago by Evan Schoenberg

pending: 01

comment:5 Changed 13 years ago by Raptor007

Removing SetAlphaValue seems to have solved the crashing. Too soon to tell if this has solved the blank tooltip windows, since I was never able to recreate that bug manually (it just popped up randomly). I'll report back later on that one.

If the original poster milkandhoneybunny is monitoring this, do you also have SetAlphaValue installed?

comment:6 Changed 13 years ago by Ryan Cassidy

I had this same bug (submitted a duplicate ticket, sorry) but SetAlphaValue doesn't need to be uninstalled completely: if you check the box in the SAV window while in Adium that says "Disabled SetAlphaValue for this application" the bugs go away - at least they have for me, all has been perfect since that little checkbox switch.

comment:7 in reply to:  6 ; Changed 13 years ago by Raptor007

My problems did go away by removing SetAlphaValue. I will try ienjoycheese's suggestion of disabling SetAlphaValue for Adium only.

I installed SetAlphaValue not too long before Adium updated to 1.1, so I can't say whether this conflict is new to Adium 1.1.x or if it's always been there. I believe it is new though. If it's new, can we expect a fix from the Adium side? I rather enjoyed the dimming of my chat window when in the background. :¬)

comment:8 in reply to:  7 ; Changed 13 years ago by David Smith

Replying to Raptor007:

I installed SetAlphaValue not too long before Adium updated to 1.1, so I can't say whether this conflict is new to Adium 1.1.x or if it's always been there. I believe it is new though. If it's new, can we expect a fix from the Adium side? I rather enjoyed the dimming of my chat window when in the background. :¬)

No, like most software developers we won't support input managers and other hacks, except in one situation. If someone investigates and determines that Adium has a latent bug that's merely being exposed by SetAlphaValue, we will of course fix the bug like any other.

comment:9 in reply to:  8 Changed 13 years ago by Raptor007

Replying to Catfish_Man:

Replying to Raptor007:

I installed SetAlphaValue not too long before Adium updated to 1.1, so I can't say whether this conflict is new to Adium 1.1.x or if it's always been there. I believe it is new though. If it's new, can we expect a fix from the Adium side? I rather enjoyed the dimming of my chat window when in the background. :¬)

No, like most software developers we won't support input managers and other hacks, except in one situation. If someone investigates and determines that Adium has a latent bug that's merely being exposed by SetAlphaValue, we will of course fix the bug like any other.

Alright, that's a reasonable approach. Thanks for the response.

Guess this ticket can be closed out then.

comment:10 Changed 13 years ago by Keldi Katon

Please do not close this ticket before reading at least the first couple paragraphs of the following novel.

I've actually tracked down the cause of this. Surprisingly enough, it is a problem with Adium. SetAlphaValues simply shows the evidence left behind by the actual issue. I've done some extensive testing, and I can reproduce the issue at will, both with and without SetAlphaValues. The difference is, with SetAlphaValues deleted, the windows don't become visible. The problem is that tooltips are not being deleted in certain common circumstances, resulting in a slow memory leak. (My evidence is below, in the attached copy of War and Peace.)

My apologies in advance for the mass of text, but I figure it's better to include everything relevant so that the devs have all the info they might need.

My first day using Adium, and I've got SetAlphaValues enabled as well. Same problem everyone else is having. I don't know the software too well, so I'm coming at the problem with a clean slate.

Here's the situation that, when running SetAlphaValues, visibly replicates the problem 100% of the time. (Run-on sentences ahead!)

When hovering and displaying a tooltip for a contact, and when then crossing a group seperator to hover over a contact in a new group, once the mouse is not hovering over a contact, the tooltip disappears with a slow fade.

Next, upon changing focus away from Adium, and then returning focus to Adium, the last displayed tooltip appears... with full opacity, on top of all previous frozen tooltips, containing only a user icon, in the location it was located last (or located while fading).

So, interesting things: first, the tooltips only reappear when focus is returned to Adium. That's likely a behavior of SetAlphaValues, which returns "focus"/opacity to a program when selected. However, for the tooltips/windows to be given "focus" again suggests the windows are still existant somewhere.

Other important information, leading to a conclusion:

  • Moving from a contact to outside the contact list causes a "slow fade", during which no new tooltips are generated at all.
  • Moving from one contact to another contact within the same group causes the tooltip to move with the mouse without ever fading.
  • Moving from one contact to another contact across groups causes the first tooltip to start a "slow fade" for a moment, before reappearing at full opacity as it hits the new contact.
  • One tooltip becomes stuck for every completed, cross-group, "slow fade", regardless of the number of groups crossed, and it appears at the site of the completed "slow fade".

The fact that multiple tooltips can be visible without impacting the creation of new tooltips makes me think that Adium uses a pointer-style declaration to create tooltip... and if a tooltip starts to fade (from crossing groups) but is not allowed to finish (due to moving across another contact while remaining within the contact list) the function that makes the tooltip delete itself upon becoming invisible fails to function, and the pointer is reset to blank. Once you hover over a new contact, a new tooltip window is generated, leaving the first one invisible and stranded.

The reason this only shows up with SetAlphaValues is because SAV adjusts the opacity of all the windows upon refocus... including the ones at 0 opacity that are "invisible" and stranded.

Once I suspected that, I turned on a memory monitor and did some tracking. After shutting down all unneccessary programs, I waited until my used memory remained the same for a full minute, with focus on Adium. I performed this test both with SetAlphaValues installed, and with it completely uninstalled and the trash emptied. I did the same memory tracking for each test.

With SetAlphaValues on, my memory started at 712mb free. I intentionally created about 35 of those hover windows. Once I finished, my remaining memory was 707mb.

After removing SetAlphaValues and rebooting, I waited for my free memory to stick at around 710mb free. I then repeated the process that created tooltips before for around 5 minutes repeatedly. As I couldn't see the tooltips, I can't give a number of how many were created. However, after the test, my available memory had dropped from 710mb to 705mb free. Nothing was occuring other than the repeated mouse movements and tooltips.

Conclusion: Interrupting the "slow fade" of tooltips causes duplicate "invisible" tooltips to be created. These tooltips sit around until Adium closes. The reason they are visible to SetAlphaValues users is because they still exist, and are just sitting at 0% opacity until SetAlphaValues changes the opacity of all open Adium windows.

The impact on performance for me was minimal, as I'm using one of the new Macbook Pros, with 2gb of RAM. (My precious first Apple/1.5 months pay...) However, in cases where people have less available RAM, this may become a perfomance issue.

I've also found a pseudo-workaround to make the stranded tooltips stay out of your way, if you use SetAlphaValues. Once a tooltip is generated, open ShowAlphaValues, and click on the first blank space in the Window List. That's a tooltip with no name, AKA, our stranded tooltip. Click and drag the "Opacity" slider to 10, which is as low as you can go without it becoming completely opaque. You'll have barely visible "ghosts" of the stranded tooltips now, instead of completely opaque ones.

However, this workaround doesn't get rid of the stranded tooltips; they still stay in memory and take up space until you exit and restart the program.

Possible band-aids: Temporarily disable the "fade out" functionality on the tooltips, instead having them disappear instantly. That will make it impossible for someone to cross from one group into another before it fades, and will prevent the duplication of tooltips. It's not nearly as pretty, but it stops the leak, assuming a more permanent solution is difficult to reach easily.

Whew! There went 3 hours of my evening; it was certainly fun, though. Please let me know what you think about my conclusions.

comment:11 Changed 13 years ago by Zachary West

Milestone: Needs feedback from usersAdium X 1.1.2

comment:12 Changed 13 years ago by David Smith

Owner: changed from nobody to David Smith
Status: newassigned

Will investigate this evening if I remember. Leaked windows might have non-obvious consequences in terms of resource use.

comment:13 Changed 13 years ago by David Smith

Summary: Adium X 1.1 Blank Tool tip windows show up & never fade from the screen.ToolTip Window Leak/Blank Tool tip windows show up & never fade from the screen.

Peter and I had a look, and I can confirm that WITHOUT SetAlphaValue, you can see tooltip windows being leaked by examining with QuartzDebug.

comment:14 Changed 13 years ago by Peter Hosey

I never fired up Quartz Debug. I used OmniObjectMeter.

comment:15 Changed 13 years ago by Peter Hosey

Bah, misread. Sorry.

comment:16 Changed 13 years ago by Peter Hosey

Resolution: fixed
Status: assignedclosed

(In [20733]) Stopping the animation doesn't lead to animationDidEnd: being called, so our _reallyCloseToolTip method was never called, so the current tooltip was not released if another one was spawned while the current one was fading out. This caused tooltips to be leaked in _closeTooltip, when we replaced the existing animation id with a new one, boldly assuming that one wasn't there already.

To fix this, we must implement animationDidStop: as well as animationDidEnd:. Currently, the implementations are equal. I also added an assertion to _closeTooltip so that conditions like this one are caught in the future.

I believe that this fixes #7585. Committed to both [source:trunk trunk] and the [source:branches/adium-1.1 1.1 branch].

comment:17 Changed 13 years ago by typ0

This bug started to appear to me in Adium 1.1.2, it never happened before. I see the tooltips ok, but when my mouse gets out of any contacts, some tooltips remain visible on top of every applications' window(s).

Changed 13 years ago by typ0

Attachment: wip05.jpg added

in Adium 1.1.2

comment:18 Changed 13 years ago by typ0

Still happens in 1.1.3, i'm using VirtueDesktops and Application Enhancer with the Slider module btw.

Note: See TracTickets for help on using tickets.