XMPP priority changes not obeyed for pre-existing conversation windows

[rafi]

Pidgin is not properly following shifts in user priorities once conversation windows are open. It is quite easy to reproduce and I tested the behavior of two other XMPP clients (Psi & Gajim) to verify that this is in fact an issue specifically with Pidgin.

1. Login with ClientA/home, priority 10 and ClientA/work, priority 5 concurrently.

2. Login with ClientB/home.

3. Open a conversation from ClientB to ClientA and send a message. ClientA/home properly receives the message, because it has the highest priority.

4. Keep the aforementioned conversation window open and change priority on ClientA/home to 1.

5. Send a message from ClientB to ClientA again. ClientA/home again receives the message. It should have gone to ClientA/work because it now has a higher priority.

Basically, it appears Pidgin is routing messages directly to a particular resource, making the determination at the time the conversation window is created. I am not sure routing directly to a resource (user@domain/resource) is even correct. If messages are sent to the JID itself (user@domain), the server should route messages to the highest priority client. Sending messages specifically to a resource is typically an additional option in other XMPP clients, not the default behavior.

If the intention is to continue routing to specific resources, then Pidgin should verify the resource in question is still has the highest priority before continuing to send messages to it. If not, switch the destination resource to the one which has the highest.

[darkrain42]

Automatically always picking the most available resource would mean that there's no way to have a conversation with a resource that *isn't* the highest priority, which is bad because there's always the possibility that there are multiple "most available" resources (i.e. multiple clients with the same priority).

Pidgin's current behavior, as I understand it, is this:

• Initial messages are sent to the bare JID. Messages are sent to a bare JID until a response message is received.
• Once a response is received from a specific resource (this includes typing notifications, I believe), further messages are sent to that specific resource.
• If that specific resource goes offline, the next message is sent to the bare JID.
• If we receive a message from a specific resource, further messages go to that resource.

The obvious deficiency in this is that there's no easy way to send a message to a specific resource (which is something we know about and want to fix, but don't have a good solution for at the moment. My personal goal is to manage to get them added to the "Send To" window in the same way multiple buddies are selectable in a metacontact). One way to work around this to close the conversation tab, ensure you have Tools->Preferences->"Close IMs immediately when the tab is closed" checked, and enter a full JID in the Buddies->New Instant Message dialog. The message will then be directed to that resource initially.

Routing messages directly to a specific resource is indeed valid behavior, and I'm not sure we can always rely on the remote server to route to the "right" resource (ignoring the use case where one is conversing with a not-highest resource) in the situation where there are two resources with the same highest priority, as the server is free to pick the "wrong" resource in that case (the XMPP specs leave it up to the implementation to decide which resource to route the message to (or all)).

I do think the situation you describe where another resource becomes more available but messages are still routed to the now-less-available resource is valid, but I'm unsure how to address it without adversely impacting other use-cases.

[rafi]

The problem is, as it stands, priorities basically do not work. I suspect the use case I am concerned with is rather common. A user is logged in from 2 locations during the day: one desktop and another mobile. When the user steps away from their desk, they prefer messages be routed to their mobile, then back to the desk once they return.

Clients with support for dynamic priorities (Psi, Gajim and eventually Pidgin) "do the right thing" and support flipping back and forth between the destination with the highest priority. With Pidgin, this is only possible if ClientB (from my previous example) is constantly closing and reopening the conversation window with ClientA, which does not happen. I think people tend to keep conversation windows open throughout the day.

If I understand the spec correctly, in the case of equal priorities, the server will route to the most recently established/connected resource. I did not see anything about the client having to make these decisions. Either way, I really hope to see the current behavior of Pidgin changed. The message recipient is specifically setting priorities to decide where his messages should go and Pidgin is ignoring this. I think the use cases for the sender to be able to address a specific resource are much less likely than following the priorities set by the recipient.

Ideally I think Pidgin should always send to the highest priority resource. If the resource with the highest priority shifts during a conversation, perhaps prompt the sender about it (i.e. Recipient's highest priority resource has changed, stay with the existing resource?) and make the prompt configurable.

[deryni]

Ticket #10062 has been marked as a duplicate of this ticket.

[hildjj]

The best practice is to unlock from the locked resource with ANY presence change from the bare JID (user@domain). This allows the receiving server to decide where the most available resource is at the time that the next message is sent.

For example, if the resource that is locked was priority 10, then goes auto-away with priority 0, messages should now be delivered to the user's cell phone, which has priority 5.

Also, see Message Mine-ing (XEP 259: http://xmpp.org/extensions/xep-0259.html) for a longer-term approach.

[jaymzh]

Is there an update on this bug? This explains a lot of weird behavior I see with pidgin directing IMs to odd places. Since it's been 3 months since the last reply, I thought I'd follow up.

[cfb]

I just ran into this problem with a friend who was using pidgin and trying to IM me. Would love to see a fix for this at some point.

[darkrain42@…]

(In [080a4ba95022e5c7613fdab2833eee2085b65b46]):
jabber: Unbind/Unlock from a specific resource on presences.

Closes #9874.

[darkrain42@…]

(In [649a416b7338f1cf5c4f622cbdca4401225982ee]):
Changelog that (hopefully this is clear to laymen; I'll check again tomorrow morning).

Refs #9874.