Created attachment 349421 [details]
Simple testcase with two tooltips

Testcase:
glade-previewer --filename icon-tooltip.ui

Expected: "Overall tooltip" for the whole GtkEntry and "Icon tooltip" for the icon

I can also confirm this bug. Using GJS I can confirm that properties, functions and constructors work, in that the properties can be set and retrieved, but the tooltip just doesn't show.

The tooltip works for me on X11. Chances are this is a Wayland-specific problem.

A quick test indicates that the allocation that is checked against in get_icon_at_pos() has a y-position that is lower (larger) than query_tooltip is passing in, so get_icon_as_pos() always fails to return a matching icon.

^ but again, that only occurs on Wayland. So there must be some problem with allocations on Wayland. I've not been able to build GTK+ 4 yet (huge Debian update needed first) to see whether or not this is specific to GtkCssGadget.

side note: GTK+ 4 uses widgets for the icons, so shouldn't it just set the tooltip text/markup directly on those? The query_tooltip routine seems redundant.

(In reply to Daniel Boles from comment #5)
> ^ but again, that only occurs on Wayland. So there must be some problem with
> allocations on Wayland. I've not been able to build GTK+ 4 yet (huge Debian
> update needed first) to see whether or not this is specific to GtkCssGadget.

I'll be in a position to check this later. I didn't yet find any other bugs indicating issues with allocation positions on Wayland, nor can I think of a reason why the backend would make a difference, so it's a confusing one.


> side note: GTK+ 4 uses widgets for the icons, so shouldn't it just set the
> tooltip text/markup directly on those? The query_tooltip routine seems
> redundant.

I see now that this is wrong: because Entry is (still) not a subclass of Container, it needs to implement its own logic for showing the tooltips of children, regardless of whether they are widgets. Maybe it's still worth moving the tooltips to the widgets and then using ::query-tooltip to get them; that would avoid e.g. having to Pango-parse the markup as GtkWidget would handle that for us.

Additional data point: While the example here works for me on Windows, one of my own applications with an added tooltip does not. I'm currently trying to figure out what the difference between them is that causes the different behaviour. But suffice it to say that this may not be a Wayland-only problem, though it may have multiple different causes.

Created attachment 356631 [details]
test case showing broken tooltip when window has headerbar

This test case shows that, at least on Windows

* having an Entry in a normal Window works; the icon's tooltip is shown

* having an Entry in a window with a HeaderBar as its titlebar breaks the icon tooltip

so I guess the allocation is offset somewhere along the way, therefore breaking gtk_entry_get_icon_at_pos(x, y)

I've not got access to Wayland/X11 right now to check this there

Created attachment 356637 [details] [review]
entry: Make get_icon_at_pos() work properly

get_icon_area() shows that the icon allocation obtained from gtk_css_gadget_get_border_allocation() needs to be adjusted relative to the allocation of the entry.

Moreover get_icon_at_pos() is explicitly documented as expecting this kind of relative allocation

So, we can just implement get_icon_at_pos() in terms of get_icon_area(), thus getting the correct allocation for each icon to compare against the tooltip coords - while also simplifying the implementation considerably.


N.B. - this is untested, but it seems to make perfect sense to me, and it's hard to imagine it not working when I test it later tonight :-)

Review of attachment 356637 [details] [review]:

::: gtk/gtkentry.c
@@ +9007,2 @@
+      if (x >= rectangle.x && x < rectangle.x + rectangle.width &&
+          y >= rectangle.y && y < rectangle.y + rectangle.height)

If an equivalent fix proves to be needed for GTK+ 4, this could use its new gdk_rectangle_contains_point() to simplify further.

Created attachment 356673 [details] [review]
Entry: Fix get_icon_at_pos()

This was comparing the input position, which is documented as being
relative to the top-left of the Entry allocation, to icon allocations
that were not adjusted accordingly. This could result in tooltips for
icons not being shown in various conditions, since the ::query-tooltip
handler uses get_icon_at_pos() to check whether to show an icon tooltip.

The fix is to compare to the icon border box, not border allocation, as
CssGadget::get_border_box() adjusts relative to the widget. Better yet:
we can just make CssGadget::border_box_contains_point() compare for us.

Delegating to Entry::get_icon_area(), which manually reimplements
CssGadget::get_border_box(), would also work, but this is simpler.


  This seems simpler for GTK+ 3.
  GTK+ 2 and 4 seem to work OK as-is.

tested and pushed the above