Bug 15793 – [GTK] tooltip position doesn't update when hovering consecutive links

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Salvatore De Paolis]

While loading a picture, if it contains a title tag, this isn't showed in a tooltip.

[Matt Lilek]

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

[Christian Dywan]

Created attachment 17469 [details]
Implement tooltips

[Adam Roben (:aroben)]

Comment on attachment 17469 [details]
Implement tooltips

+    if (toolTip.isEmpty())
+        g_object_set(G_OBJECT(m_webPage), "has-tooltip", FALSE, NULL);
+    else
+        gtk_widget_set_tooltip_text(GTK_WIDGET(m_webPage), toolTip.utf8().data());

Is it a problem that has-tooltip is never set to TRUE?

+    static GtkTooltips* tooltips;
+    if (!tooltips)
+        tooltips = gtk_tooltips_new();

You should be able to do this in one line, since this is C++ code:

static GtkTooltips* tooltips = gtk_tooltips_new();

[Alp Toker]

Comment on attachment 17469 [details]
Implement tooltips

The use of the new API is correct, so r+ for that half.

The implementation for the old tooltip API was incorrect and displayed tooltips at wrong times, eg on the www.google.com search entry.

Please attach an additional fix for this.

Also, remember to include a ChangeLog entry.

Thanks!

[Alp Toker]

First half of the fix landed in r28000.

[Alp Toker]

Christian,

Can you also look into the tooltips that appear on the right side of http://planet.gnome.org/ ?

The tooltip bubble always seems to stay in the same place when you move up and down.

[Jan Alonzo]

Created attachment 17538 [details]
Fix the tooltip being in stuck at one place when hovering on consecutive links

This patch fixes the situation when tooltips get stuck at one location when hovering on links with title attribute consecutively (e.g., planet.gnome.org sidebar feed list).

[Alp Toker]

Do we really need to construct a whole new GtkWindow instance every time the tooltip text changes?

I'm wondering why we can't get the built-in tooltip API to work the way we want and have to resort to creating our own window in the first place.

[Jan Alonzo]

(In reply to comment #8)
> Do we really need to construct a whole new GtkWindow instance every time the
> tooltip text changes?

I tried the single GtkWindow instance but it exhibited the same issue we are having (i.e., same behaviour as current implementation).

> 
> I'm wondering why we can't get the built-in tooltip API to work the way we want
> and have to resort to creating our own window in the first place.

I must admit that my patch is a band-aid as I can't seem to find a better way using the existing (2.12) tooltips API to fix the issue. It seems that the only way to interact with the tooltip properly is to connect to the GtkWidget::query-tooltip signal as per documentation of GtkTooltip. But sending query-tooltip seems to duplicate functionality with ChromeClient::setToolTip (in terms of saying "show me a tooltip"), at least AFAIC.

I hope that clears things a bit.

[Alp Toker]

Comment on attachment 17469 [details]
Implement tooltips

Patch already landed, but the bug report needs to remain open. Removing r+ flag to clear the commit queue.

[Alp Toker]

Comment on attachment 17538 [details]
Fix the tooltip being in stuck at one place when hovering on consecutive links

Kris (author of the new GtkTooltip API) suggested that this workaround shouldn't be necessary. r- based on this, though we might have to re-visit it if we can't find an alternative.

One suggestion was to usegtk_tooltip_set_tip_area() but that requires that we have knowledge of existing tooltip areas, and the area has to be rectangular, neither of which is always true.

The drawing area example in testtooltips might be a source of inspiration apparently.

Jan, could you coordinate this effort with the GTK+ team? If it doesn't work out, we'll have to look at the hacks again.

Thanks!

[Gustavo Noronha (kov)]

Created attachment 28648 [details]
my own proposed work-around

[Gustavo Noronha (kov)]

Created attachment 28694 [details]
my own proposed workaround

Addressed comments by zecke on IRC: basically take the GdkDisplay from the toplevel, if available, and do our thing before emitting the hovering-link signal.

[Holger Freyther]

Comment on attachment 28694 [details]
my own proposed workaround

afterwards in which way? after we disable it and then query again (nitpicking at the language even when not qualified to do so...)? :)

[Gustavo Noronha (kov)]

Landed as r41971 with a fix for the nitpick hehe.