1193643 - Allow requestBuddyInfo to return some info immediately

Status: RESOLVED FIXED

(Chat Core :: General, defect)

Description

[aleth [:aleth]]

requestBuddyInfo, instead of returning void, could return a prplITooltipInfo with whatever data is available immediately. This would help especially with JS-XMPP, where the vcard request can take quite a long time and we could return the status immediately. It could also improve IRC (we could return cached whois info if we have it and update it when the whois response comes in).

Comment 1

[aleth [:aleth]]

Attachment: Allow requestBuddyInfo to return cached/available data immediately to speed up tooltips

Comment 2

[aleth [:aleth]]

I decided not to change the return type of requestBuddyInfo, but instead to allow requestBuddyInfo to send two (or more) notifications.

Benefits:
- Avoids tooltip flicker if we already have some whois data (IRC)
- Shows the status data immediately for XMPP, which makes the tooltip useful immediately without having to wait for the vcard to come in if that's not wanted.

I'm not 100% sure about the naming changes for IRC, comments, etc.

Comment 3

[Patrick Cloke [:clokep]]

Comment on attachment 8666238 [details] [diff] [review]
Allow requestBuddyInfo to return cached/available data immediately to speed up tooltips

Review of attachment 8666238 [details] [diff] [review]:
-----------------------------------------------------------------

I'm not 100% on the XMPP changes, but they look sane.

Does this mean that we could throw notifications for each WHOIS response instead of waiting for all of them to get back? (Does that help us in anyway?)

::: chat/components/public/imIAccount.idl
@@ +110,3 @@
>     *  - aSubject will be an nsISimpleEnumerator of prplITooltipInfo.
>     *  - aData will be aBuddyName.
> +   * If two user-info-received notifications are sent, the first

I'm unsure I like this part of the comment. This doesn't fit the actual implementation, which can be called many times. I think what you're trying to say: "If multiple user-info-received are sent, subsequent notifications will update any previous data."

Comment 4

[aleth [:aleth]]

Attachment: Allow requestBuddyInfo to return cached/available data immediately to speed up tooltips

Comment 5

[aleth [:aleth]]

(In reply to Patrick Cloke [:clokep] from comment #3)
> I'm not 100% on the XMPP changes, but they look sane.

They are minimalist (we don't currently cache vcard data).

> Does this mean that we could throw notifications for each WHOIS response
> instead of waiting for all of them to get back? (Does that help us in
> anyway?)

Possible in principle, but I suspect it would cause more flicker than it is worth.

Comment 6

[aleth [:aleth]]

https://hg.mozilla.org/comm-central/rev/f1c3d32341ddb64e95b1a5b8e285f97497dfa652
Bug 1193643 - Allow requestBuddyInfo to return cached/available data immediately to speed up tooltips. r=clokep