Tooltips stick when switching desktops (Compiz)

[Bernhard]

Reproduce:

1) have firefox in workspace 1
2) go to workspace 3
3) in the workspace switcher, click on firefox in workspace 1 and QUICKLY move pointer to the middle of screen

Result: you have a tooltip saying "Click to start dragging...." on your workspace switcher and it doesn't go away unless you move your pointer over it. This is a new issue since upgrading to Jaunty. Those tooltips are completely superfluous because the dragging doesn't work anyway (see also bug 318855). But that they stick since jaunty is even more annoying.

[Sebastien Bacher (seb128)]

thank you for your bug report, do you use the desktop effects? to send upstream by somebody having the issue that's a tiny cosmetic issue in corner cases situations

[Sebastien Bacher (seb128)]

could be a gtk bug too

[Dmitriy Geels (dmig)]

I confirm this bug. Compiz is running.
Jaunty is up to date for this moment.

[Bernhard (b.a.koenig)]

Architecture: i386
DistroRelease: Ubuntu 9.04
Package: libwnck
ProcEnviron:
 LANG=en_CA.UTF-8
 PATH=(custom, user)
 SHELL=/bin/zsh
Uname: Linux 2.6.28-11-generic i686
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

[Bernhard (b.a.koenig)]

I use the "Normal" Desktop effects and have configured ccsm, but just a tweak. It is indeed a cosmetic issue but pretty annoying because these tooltips are misleading anyway.

Do you want me to send it to the Gnome bug tracker?

[Bernhard (b.a.koenig)]

OK, check link to the upstream bug.

[Sebastien Bacher (seb128)]

Thank you for sending the bug there, I'm not quick enough to trigger the issue the workspace change is too quickly and the tooltip is correctly updated there

[Anonym25712 (anonym25712)]

Why did you open a bug on Gnome's bug tracker?? This is caused by Compiz, its has nothing to do with Gnome nor Metacity (just disable visual effects to be convinced).

And I don't like calling this "a tiny cosmetic issue", this happens to me all the time and the tooltip *NEVER* disappear by itself, I *MUST* move my mouse over it each time. That's pretty funny to hear that the old notification system was disturbing, but that a tooltip that stays over my window forever is just "a tiny cosmetic issue".

I'll remove the triaged flag since the current "upstream" bug is invalid.

[Bernhard (b.a.koenig)]

I wasn't sure if it was metacity issue or not. All I know is that it happened to me ever since I upgraded to Gnome 2.26. It might be a Gnome issue as well though, because these tooltips are completely useless notifications of the gnome panel (the dragging in the switcher has once been abondoned because it was too buggy).

I agree that it's a very annoying bug.

[Anonym25712 (anonym25712)]

Could we get an update on this? I'm not sure I want to see these tooltips stick over my windows until the next Ubuntu release. The workspace switcher applet could at least be patched to completely remove these tooltips (should be quite easy AFAICT) until a solution is found in Compiz.

[Magnus (koma-lysator)]

I too confirm this bug. Compiz is running.
Jaunty is up to date for this moment.

[Chris Roddy (cmr)]

this behavior is particularly annoying due to the fact that the tooltip isn't even true (try it -- try dragging a window!)

[Warlon (sampsa-p)]

I know this is a small issue, but it sure can be annoying. Hope this gets fixed soon.

[Bernhard (b.a.koenig)]

Btw, I added an extra bug to GNOME concerning the misleading tooltip "Click to start dragging....". Please leave your comments: http://bugzilla.gnome.org/show_bug.cgi?id=581870

[Anonym25712 (anonym25712)]

This tooltip is not misleading as dragging a window to another workspace works. It doesn't work when Compiz is enabled because Compiz doesn't support it. Try to disable Compiz and you'll see that it works perfectly fine with Metacity.

[Bernhard (b.a.koenig)]

Oh, you're right. So what's the way to go then? Wait until it gets fixed in compiz or suppress the tooltip when compiz is running?

[deew (dee-wykoff)]

Hi, I also find this bug wildly annoying. It blocks the time display. Gosh. I have to put the pointer over the message to get rid of it so I can find out what time it is. Is there an alternate version of "workspace switcher" that could be used instead?

How the heck do you guys figure that Compiz being enabled is an excuse for this deal? Compiz is enabled by default.

[Anonym25712 (anonym25712)]

This bug has been "triaged", so they don't care. The funniest thing being that the upstream bug is not valid. Now, just cross your finger to see this bug magically fixed in the next Ubuntu release.

[Sebastien Bacher (seb128)]

not sure the hundredpapercut tasks should be open to be filed by any user that sort of defeat the purpose of having a list of usuability issues selected by the design team if everybody starts to add his or her bugs there

[Sebastien Bacher (seb128)]

The bug there is a standard issue to tracker down and get fixed not a hundredpapercut design issue

[tankdriver (stoneraider-deactivatedaccount)]

I set hundredpapercuts to "invalid"
Sorry, I read this papercut stuff on the planet and I took it in the wrong way.

[renbag (renbag)]

I confirm this bug in jaunty with compiz enabled. I'm used to frequently switch from one virtual desktop to another and I find this bug extremely annoying. Also disabling panel tooltips in gconf-editor (/apps/panel/global/tooltips_enabled) does not help at all.

[Matthew Paul Thomas (mpt)]

tankdriver, you were doing the right thing. Anyone can nominate a bug for One Hundred Paper Cuts.

[Travis Watkins (amaranth)]

Just to make it clear (sorry for spamming) the dragging in the workspace switcher doesn't work when compiz is enabled because the workspace switcher lacks the code to do it, it has nothing to do with what compiz does or doesn't support. I submitted a patch upstream some time ago, it's all on GNOME now.

[Bernhard (b.a.koenig)]

Travis, could you give a link? There's nothing on the upstream bug linked here.

[Travis Watkins (amaranth)]

Sorry, the patch I submitted was for scrolling on the workspace switcher, not dragging. Either way, the upstream bug makes it clear that is a problem with libwnck.

Back on topic, this particular bug is trickier. The upstream bug was marked as a duplicate of the bug about dragging not working so I'm not sure if they understood what the problem was. Seeing how libwnck-based things are the only ones that seem to have this problem (window list does it too) I'm thinking it's a libwnck problem and not a compiz problem. If a libwnck developer can point to what compiz is doing wrong that makes this happen I'd be glad to see what I can do to fix it though.

[Bartek (tschew)]

To elaborate Travis' point about the window list, here's how that is affected:

1) configure window list to show windows from all workspaces
2) open some window on workspace 1
3) switch to a different workspace
4) click on window list entry for window on workspace 1 ensuring that you DON'T cause the tooltip to appear (ie don't hover long, just click!)
5) move away from the window list, watch the tooltip appear and remain persistent

It doesn't happen 100% of the time but I haven't been able to figure out what causes it exactly. As far as I can tell delaying step 5) slightly actually prevents it.

[deew (dee-wykoff)]

Is that normal to change the status of a bug to invalid without saying why?

[Bernhard (b.a.koenig)]

I think the bot might have done that by mistake, don't know how this "Bug Watch Updater" is programmed.

[Sebastien Bacher (seb128)]

the said bot just update the GNOME task by reflecting the bugzilla.gnome.org bug change, you will notice that the ubuntu task didn't change, the reason is that the GNOME bug is a duplicate

[renbag (renbag)]

This bug is not excusively related to tooltips about drag and drop of windows between viewports, but also to other general type of tooltips.
For example, when I switch from a workspace containing a terminal windows to one containing firefox (with this page open) I get a persistent tooltip on the panel saying:
Bug #356702 in libwnck (Ubuntu). "tooltips
stick when they shouldn't" - Mozilla Firefox

[Jason Day (jason-jlogday)]

Here is a patch to disable all tooltips for the workspace switcher. Sanity has been restored to my desktop, may it help yours as well.

[renbag (renbag)]

The libwnck-notooltip.patch works for me, thanks.
However I get persistent tooltips also when switching applications with the window list applet, so I don't think the issue is related to the workspace switcher only.
The attached patch disables tooltips for the window list applet. I have simply commented the lines of codes in libwnck/tasklist.c related to tooltips, but it works for me in jaunty.

[deew (dee-wykoff)]

Still got it in Karmic (desktop 64bit). Rather surprised by that.

I suspect that this bug is rather well known by now. A funny thing happened when I went to Google to look this up. I started to type in "Ubuntu click to start dragging" and by the time I got to "Ubuntu clic", it had filled in the rest. When Google fills in your search phrase that early, it might mean you are searching for something popular.

I would humbly suggest that all tool-tips pertaining to the workplace switcher be disabled by default. Is anyone really going to miss them?

I will try that patch. Thanks in advance Renzo.

[ego-sum-deus (shawnwitham)]

could someone please explain how to apply patches? im trying to use the libwnck-notooltip.patch and don't know exactly how to get everything patched and compiled. so, that would be awesome if someone could say how to do this. thanks

[Jason Day (jason-jlogday)]

ego-sum-deus, I put detailed instructions, and a link to a binary package, on my bog here: http://blog.jlogday.com/2009/08/jaunty-tooltip-annoyance/ . The binary does not include Renzo's patch, but you if you build the package yourself you should be able to apply both patches, one after the other.

HTH,
Jason

[ego-sum-deus (shawnwitham)]

ahhhh its soo nice hahaha thanks jason, it worked amazingly well. can i delete all of the files that were downloaded and the created libwnck directory?

[Jason Day (jason-jlogday)]

Sure, once the package is installed you don't need the build directory any more. Glad you got it working.

[Sebastien Bacher (seb128)]

unsetting the patch status since those are workarounds, disabling tooltips use is not a fix to the bug, could somebody open an upstream bug too?

[Sebastien Bacher (seb128)]

upstream bug hint that the issue is a compiz one

[Paul Smith (psmith-gnu)]

Argh. Can someone please look at this? I guess some people just have a certain speed of moving the mouse that causes this to happen: it happens to me about 80% of the time that I click on the switcher applet. I know it sounds stupid and minor, but it is SO INCREDIBLY ANNOYING!

I can build/install/test patches, etc. Just let me know what I can do to help.

[renbag (renbag)]

Filed a bug in compiz:
http://bugs.opencompositing.org/show_bug.cgi?id=1232

[Vish (vish)]

Thanks for sending it upstream

[Paul Smith (psmith-gnu)]

Are we sure this is really a bug in compiz? It seems too early to determine that and reassign the bug. There are plenty of other tooltips that are used in other applications and I never see those hang up like this using compiz. It seems to only be a combination of libwnk and compiz that shows the problem... which means the problem might be in compiz, but it might also be in libwnk. Just because libwnk doesn't show this issue with metacity and does with compiz doesn't mean it's compiz's fault.

Anyway. Hopefully this doesn't turn into one of those bugs that falls "between the cracks" of different packages, and so is not ever fixed by anyone. It would be great if one package would own the issue long enough to investigate the problem and understand the behavior sufficiently to justify reassigning it, before doing so.

[Travis Watkins (amaranth)]

As a quick guess I'd say libwnck isn't getting mouse events during the viewport change animation so never realizes the mouse left the switcher. That's why the tooltip appears and why moving your mouse over the tooltip or the switcher gets rid of it. I'm not sure what it does differently from other apps because they seem to handle this correctly.

[deew (dee-wykoff)]

I think Paul's point is well made. What if the Compiz guy looks at this and says "The desktop switcher is the only thing that has tooltip problems. Let them eat cake!" what then?

When I right click on the desktop switcher and go to preferences it allows me to set columns and rows, how hard would it be to add a check-box that says "disable tooltips and banish them to the land of wind and ghosts"?

[renbag (renbag)]

If this is of interest for developers, I found that in libwnck-2.28.0 (karmic) the persistent tooltips in the window list applet can be avoided by applying a patch to 'tasklist.c' that disables tooltips only in 'wnck_task_update_visible_state'.
In libwnck-2.26.0 (jaunty) it was necessary to disable tooltips also in 'wnck_task_popup_menu' and 'wnck_task_create_widgets' (see comment #33).

[renbag (renbag)]

From the first comments in the bug filed upstream in compiz it seems that they think the window manager is not responsible for the behaviour of tooltips (http://bugs.opencompositing.org/show_bug.cgi?id=1232#c1):

...
Tooltips are override_redirect windows, which means that the window manager doesn't touch them at all and the application is _completely_ responsible for that kind of window, which includes showing, hiding, moving and resizing as well as focus.
...
override_redirect windows (not only tooltips, but also menus etc.) are completely managed by the application; it's neither the WM's job to deal with them nor is the WM allowed to do so.

[gcb (gcb0)]

happens to very regularly with opera and chrome.

don't know what triggers it exactly tough... it's usually a long and screen consuming url on the tooltip.

[hotani (hotani)]

I'm looking at this bug right now in Lucid beta2. :-(

[deew (dee-wykoff)]

I found a method that seems to effectively eradicate tooltips on a Fedora forum:
Create a file in your user directory called ".gtkrc-2.0"
The file should contain the following "gtk-enable-tooltips = 0"

[Johan Tavelin (s-launchpad-tavelin)]

I have investigated this problem and found that the bug is in the tooltip code in gtk. When compiz switches workspace it performs a pointer grab and gtk tooltips don't handle this correctly. The following sequence of events will trigger the bug:

1) While a tooltip is displayed another program performs a pointer grab (e.g. using XGrabPointer).
2) The pointer grab triggers a LeaveNotify event and the tooltip is hidden.
3) The tooltip text is updated by the program and as the pointer still hovers the widget gtk displays the new updated tooltip.
4) The user moves the pointer away from the gtk widget while the pointer grab is still active. As the window has already received a LeaveNotify event it will not receive another one and the tooltip will stay on the screen.

I have modified the gtk tooltip code so that a tooltip is not displayed if the widget window is not the same one as the one gdk thinks is the current window under the pointer. This appears to have solved the problem for me at least.

[jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount)]

Forwarded upstream:

https://bugzilla.gnome.org/show_bug.cgi?id=615451

[renbag (renbag)]

I tried the gtk-fix-sticking-tooltips.patch and it works perfectly for me also. Thank you Johan for investigating and solving this bug! I hope that this patch can be applied in time for lucid release.

[Sebastien Bacher (seb128)]

Thank you for your bug report and for opening an upstream bug, could you add the change and the explanation to bugzilla too though? they usually don't like much having to go to other bug trackers to read details about the bug opened there and having the change not on bugzilla might make them not see listed as something waiting for review

[Vish (vish)]

Johan Tavelin, Could you attach your patch to the upstream bug? : https://bugzilla.gnome.org/show_bug.cgi?id=615451

[Johan Tavelin (s-launchpad-tavelin)]

I have attached the patch now.

[Gary Walker (scuzzpuck)]

How do I apply this patch?

[renbag (renbag)]

I have made gtk+2.0 packages with the gtk-fix-sticking-tooltips.patch made by Johan Tavelin.
They are available in my ppa archive: https://launchpad.net/~renbag/+archive/ppa
(gtk+2.0 - 2.20.1-0ubuntu1renbag2)

[Ivy (blazemore-deactivatedaccount)]

Having this issue with a freshly installed Lucid 64-bit.
Would like to see this fixed for Maverick as part of 100 papercuts - very unprofessional!
IMO tooltips here should be disabled completely as they give no useful information.

[Sebastien Bacher (seb128)]

The change there is not really trivial and upstream has concern about the patch which was suggested

[Jason Day (jason-jlogday)]

For the love of all that's holy, just disable the tooltips! They don't provide any useful information anyway.

[Magnus (koma-lysator)]

I second that. The tooltips of the desktop switcher are not needed at all.

[Cristian Baltatescu (cbaltatescu)]

How exactly do you do that? There is nothing in the Workspace Switcher Prefs
for that.

On Tue, Aug 17, 2010 at 12:05 AM, Magnus <email address hidden> wrote:

> I second that. The tooltips of the desktop switcher are not needed at
> all.
>
> --
> Tooltips stick when switching desktops (Compiz)
> https://bugs.launchpad.net/bugs/356702
> You received this bug notification because you are a direct subscriber
> of a duplicate bug (481494).
>
> Status in Compiz: Unknown
> Status in GTK+ GUI Toolkit: New
> Status in One Hundred Paper Cuts: Triaged
> Status in “gtk+2.0” package in Ubuntu: Triaged
>
> Bug description:
> Reproduce:
>
> 1) have firefox in workspace 1
> 2) go to workspace 3
> 3) in the workspace switcher, click on firefox in workspace 1 and QUICKLY
> move pointer to the middle of screen
>
> Result: you have a tooltip saying "Click to start dragging...." on your
> workspace switcher and it doesn't go away unless you move your pointer over
> it. This is a new issue since upgrading to Jaunty. Those tooltips are
> completely superfluous because the dragging doesn't work anyway (see also
> bug 318855). But that they stick since jaunty is even more annoying.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/compiz/+bug/356702/+subscribe
>

--
Numai bine,
Cristian
http://www.cristianbaltatescu.com

[Nils Toedtmann (m-launchpad-net-mail-nils-toedtmann-net)]

James Holland wrote on 2010-06-23:
> IMO tooltips here should be disabled completely as they give no useful information.

+1

[Vish (vish)]

Marking Papercut invalid as per Sebastien's comment.
Don't worry though, this bug has been marked as "Invalid" only in the papercuts project.

Regarding the tooltip removal, it doesnt help adding "+1" or "me too" to this bug report. It would be better if a separate bug was filed regarding the removing of tooltips.

[Stuart Bishop (stub)]

I can reliably (and constantly) reproduce this under Lucid and current Maverick.

1) Move the mouse over an icon in a different workspace in the workspace switcher.
2) Wait for the tool tip to appear.
3) Click
4) Move the mouse outside of the workspace switcher before the transition effect is complete.

If you have difficulty triggering, install compizconfig-settings-manager, go to Desktop Wall in the CompizConfig Settings manager, select the Viewport Switching tab, and increase the Wall Sliding Duration from the default of 0.3 to 2.0. You should now have plenty of time to trigger the race condition.

[Sam Spilsbury (smspillaz)]

This is not a bug - EWMH requires that tooltip windows are marked
sticky iirc [1]

[1] http://standards.freedesktop.org/wm-spec/wm-spec-1.4.html#id2551529

On Tue, Sep 28, 2010 at 10:37 AM, Stuart Bishop
<email address hidden> wrote:
> I can reliably (and constantly) reproduce this under Lucid and current
> Maverick.
>
> 1) Move the mouse over an icon in a different workspace in the workspace switcher.
> 2) Wait for the tool tip to appear.
> 3) Click
> 4) Move the mouse outside of the workspace switcher before the transition effect is complete.
>
> If you have difficulty triggering, install compizconfig-settings-
> manager, go to Desktop Wall in the CompizConfig Settings manager, select
> the Viewport Switching tab, and increase the Wall Sliding Duration from
> the default of 0.3 to 2.0. You should now have plenty of time to trigger
> the race condition.
>
> --
> Tooltips stick when switching desktops (Compiz)
> https://bugs.launchpad.net/bugs/356702
> You received this bug notification because you are a member of compiz
> packagers, which is a direct subscriber.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~compiz
> Post to     : <email address hidden>
> Unsubscribe : https://launchpad.net/~compiz
> More help   : https://help.launchpad.net/ListHelp
>

--
Sam Spilsbury

[Stuart Bishop (stub)]

I've just realized the most common way I trigger this bug. I move my mouse to the workspace switcher, click, and move my mouse back to my work area - all *before* the tooltip delay passes. The tooltip will then pop up despite my mouse being nowhere near. It seems that the event for the cursor leaving the workspace switcher is lost or ignored during the transition and the applet still thinks it is inside its region.

[Paul Smith (psmith-gnu)]

Re: Sam Spilsbury:

This absolutely is a bug. Regardless of whether tooltips are marked sticky or not, they are obviously supposed to be transient. This bug says that in some fairly common circumstances, the tooltip shows up for the workspace switcher and then it NEVER GOES AWAY (unless you switch to another workspace again).

I've never seen a tooltip that didn't go away after a short time, and any such tooltip is obviously buggy.

I don't know where the problem lies exactly: maybe an event is missed, maybe something else, but this is unquestionably a bug.

[renbag (renbag)]

There is already an explanation of the bug and a patch to solve it (comment #52).
There are also packages for lucid on a PPA (comment #59) which work well for me and for others.
I'm using these packages since months and did not find particular problems.
However it seem that upstream developers do not like the patch...

[Daniel van Vugt (vanvugt)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. This particular bug has already been reported and is a duplicate of bug 145704, so it is being marked as such. Please look at the other bug report to see if there is any missing information that you can provide, or to see if there is a workaround for the bug. Additionally, any further discussion regarding the bug should occur in the other report. Feel free to continue to report any other bugs you may find.