[Bug 39377] New: TP_CONTACT_FEATURE_LOCATION repeatedly prepared for contacts who have no location

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39377

           Summary: TP_CONTACT_FEATURE_LOCATION repeatedly prepared for
                    contacts who have no location
           Product: Telepathy
           Version: git master
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: tp-glib
        AssignedTo: telepathy-bugs at lists.freedesktop.org
        ReportedBy: will.thompson at collabora.co.uk
         QAContact: telepathy-bugs at lists.freedesktop.org


I noticed that whenever a chat state changes in an Empathy conversation window,
Empathy (well, tp-glib on behalf of Empathy) would re-request Location
attributes. For instance, here's me typing a single character into a
conversation window:

> method call sender=:1.657 -> dest=:1.452 serial=427
>             path=/org/freedesktop/Telepathy/Connection/gabble/jabber/will_40example_2fb756e715/ImChannel11;
>             interface=org.freedesktop.Telepathy.Channel.Interface.ChatState;
>             member=SetChatState
>    uint32 3
> signal sender=:1.452 -> dest=(null destination) serial=10051
>        path=/org/freedesktop/Telepathy/Connection/gabble/jabber/will_40example_2fb756e715/ImChannel11;
>        interface=org.freedesktop.Telepathy.Channel.Interface.ChatState;
>        member=ChatStateChanged
>    uint32 1
>    uint32 3
> method return sender=:1.452 -> dest=:1.657 reply_serial=427
> method call sender=:1.657 -> dest=:1.452 serial=428
>             path=/org/freedesktop/Telepathy/Connection/gabble/jabber/will_40example_2fb756e715;
>             interface=org.freedesktop.Telepathy.Connection.Interface.Contacts;
>             member=GetContactAttributes
>    array [
>       uint32 1
>    ]
>    array [
>       string "org.freedesktop.Telepathy.Connection.Interface.Location"
>    ]
>    boolean true
> method return sender=:1.452 -> dest=:1.657 reply_serial=428
>    array [
>       dict entry(
>          uint32 1
>          array [
>             dict entry(
>                string "org.freedesktop.Telepathy.Connection/contact-id"
>                variant                   string "will at example"
>             )
>          ]
>       )
>    ]

This happens because the internal CONTACT_FEATURE_FLAG_LOCATION flag is only
set on a TpContact when a location is discovered for them (specifically, by
contact_maybe_set_location(), which is called from the LocationUpdated signal
and from the GetContactAttributes return callback. (And, indirectly, from the
inexplicable GetLocations() fallback path, but we'll ignore that.)

contact_maybe_set_location() looks like this:

  static void
  contact_maybe_set_location (TpContact *self,
      GHashTable *location)
  {
    if (self == NULL || location == NULL)
      return;

    if (self->priv->location != NULL)
      g_hash_table_unref (self->priv->location);

    self->priv->has_features |= CONTACT_FEATURE_FLAG_LOCATION;
    self->priv->location = g_hash_table_ref (location);
    g_object_notify ((GObject *) self, "location");
  }

But the ".../location" attribute is defined to be omitted entirely if the
contact has no location.
<http://telepathy.freedesktop.org/spec/Connection_Interface_Location.html#Contact-Attribute:location>

TpContact should be able to tell that it requested location information, and
hence that the absence of the attribute indicates that the contact has no
published location information.

(Relatedly, I noticed that Empathy will crash if ::notify(location) is emitted
by TpContact and tp_contact_get_location() subsequently returns NULL. So I
guess we have to represent “I know this contact has no published location
information” by an empty hash table. Joy!)

Some other features may have similar issues. I haven't really checked. This is
the one that bothers me whenever I look at dbus-monitor. :)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.