Bug 15793 - [GTK] tooltip position doesn't update when hovering consecutive links
Summary: [GTK] tooltip position doesn't update when hovering consecutive links
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: 523.x (Safari 3)
Hardware: PC Linux
: P2 Enhancement
Assignee: Nobody
URL:
Keywords: Gtk
: 15794 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-11-02 07:38 PDT by Salvatore De Paolis
Modified: 2009-03-25 07:32 PDT (History)
7 users (show)

See Also:


Attachments
Implement tooltips (957 bytes, patch)
2007-11-23 12:40 PST, Christian Dywan
no flags Details | Formatted Diff | Diff
Fix the tooltip being in stuck at one place when hovering on consecutive links (2.67 KB, patch)
2007-11-26 14:24 PST, Jan Alonzo
alp: review-
Details | Formatted Diff | Diff
my own proposed work-around (2.28 KB, patch)
2009-03-16 09:10 PDT, Gustavo Noronha (kov)
no flags Details | Formatted Diff | Diff
my own proposed workaround (2.53 KB, patch)
2009-03-17 11:20 PDT, Gustavo Noronha (kov)
zecke: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Salvatore De Paolis 2007-11-02 07:38:14 PDT
While loading a picture, if it contains a title tag, this isn't showed in a tooltip.
Comment 1 Matt Lilek 2007-11-02 08:04:21 PDT
*** Bug 15794 has been marked as a duplicate of this bug. ***
Comment 2 Christian Dywan 2007-11-23 12:40:02 PST
Created attachment 17469 [details]
Implement tooltips
Comment 3 Adam Roben (:aroben) 2007-11-23 12:53:22 PST
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();
Comment 4 Alp Toker 2007-11-24 13:50:47 PST
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!
Comment 5 Alp Toker 2007-11-24 13:52:51 PST
First half of the fix landed in r28000.
Comment 6 Alp Toker 2007-11-24 14:10:34 PST
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.
Comment 7 Jan Alonzo 2007-11-26 14:24:21 PST
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).
Comment 8 Alp Toker 2007-11-26 15:36:24 PST
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.
Comment 9 Jan Alonzo 2007-11-26 19:32:54 PST
(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.

Comment 10 Alp Toker 2007-11-27 22:10:31 PST
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.
Comment 11 Alp Toker 2007-12-04 09:48:43 PST
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!
Comment 12 Gustavo Noronha (kov) 2009-03-16 09:10:41 PDT
Created attachment 28648 [details]
my own proposed work-around
Comment 13 Gustavo Noronha (kov) 2009-03-17 11:20:11 PDT
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.
Comment 14 Holger Freyther 2009-03-25 00:11:24 PDT
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...)? :)
Comment 15 Gustavo Noronha (kov) 2009-03-25 07:32:12 PDT
Landed as r41971 with a fix for the nitpick hehe.