Choosing to send a message later does not stay set if message window reopened

Ticket 9051 seems to have the same issue, but it was closed. I can confirm this is a definite bug!

After clicking Send Later, go to the Get Info window and click on the Events tab. Do you see the action for sending a message listed for the "contact is seen" event?

I see the following information: Contact is seen "Send XXXX the message "blah".

When the user comes online, no message is sent, but the event disappears.

I finally have the reproducible steps:

1) Open an IM with an offline contact (ex: UserX) 2) Type message, and choose send later 3) If you check "Events" at this point, it does in fact show up properly 4) Now close the window (not just the tab, but the whole message window 5) Check the "Events" (just by getting info off of contact list)- it still appears properly 6) Open up a new message window with the same contact (UserX). The event is no longer present, and that contact will not receive the message.

For some reason, I have noticed that sometimes you need to repeat steps 4-6 to get the same effect. I am sure there are other ways to reproduce this, as this isn't what the typical person would do when sending a message. This at least proves there is some issue here.

Sorry, I forgot you need spaces after numbered items. Here is the same post again but cleaner:

I finally have the reproducible steps:

1) Open an IM with an offline contact (ex: UserX)

2) Type message, and choose send later

3) If you check "Events" at this point, it does in fact show up properly

4) Now close the window (not just the tab, but the whole message window

5) Check the "Events" (just by getting info off of contact list)- it still appears properly

6) Open up a new message window with the same contact (UserX). The event is no longer present, and that contact will not receive the message.

For some reason, I have noticed that sometimes you need to repeat steps 4-6 to get the same effect. I am sure there are other ways to reproduce this, as this isn't what the typical person would do when sending a message. This at least proves there is some issue here.

Meant to add, those steps to reproduce work for me - though closing the tab at all, then reopening it results in the problem (ie: it doesn't have to be the entire window in my tests).

I just want to add again that these steps are obviously not the typical procedure one would follow when sending a message to a user. This at least proves there's an underlying issue, and hopefully when looking into this bug, it will fix whatever we are actually experiencing.

Setting to higher priority as this can result in lost messages!

This is of decreasing relevance as more and more of our services support true serverside offline queued messaging. As of libpurple 2.4.0, AIM does, too.

Replying to evands:

This is of decreasing relevance as more and more of our services support true serverside offline queued messaging. As of libpurple 2.4.0, AIM does, too.

Suggest that this be changed back to high, as this is resulting in lost messages.

Sunday, March 2, 2008 1:52

Matt Hoppes AIM 1:52 test Could not send because xxxxxxx910 is not available.

Adium does not appear to honor the offline AIM protocol. If it did, this would not be an issue.

That is a good point Evan, though if the primary protocols are AIM, Yahoo and MSN (and maybe ICQ?), then for the moment this feature probably does have a fair amount of use as MSN still doesn't support offline messaging even in 1.2.4 since P14 has yet to be enabled.

matth: the version of Libpurple Evan is referring to is not in Adium 1.2.3 - it will be in 1.2.4 however.

*nod* And the problem almost certainly indicates something wrong at a deeper level with per-contact actions, since that's all the Send Later function does. I haven't been able to reproduce this through a couple iterations of trying jsimon's steps above. If they work for you reliably, I'll commit some debug logging that could shed light on it.

Interesting - I can't reproduce this anymore ... with 1.2.3 or 1.3svn. I've attempted to do so with 3 different contacts and made sure that I closed and re-opened the entire message window at least 5 times for each one.

Based on the date of my comment I would have been using 1.2.1 when I reproduced it. Those of you who have seen this problem, you can reproduce it in 1.2.3?

No need to keep this on 1.2.4 milestone if we can't reproduce it ... waiting for a reply from those who may still be able to, if there isn't one then we can assume this isn't a problem anymore.

I CAN still reproduce this on 1.2.3 on OS X 10.5.1. The above steps still lead to the same result, just repeat the closing and opening of the window a few times. Again, I'll reiterate that this is obviously not realistic and one would never actually do this when choosing the send later option. However, I can't help but feel as though if the issue is still slightly there when repeating the above steps, then it doesn't rule out the possibility that this stored message could be lost just after closing the window once.

Alright... perhaps that debug logging would be handy after all Evan :)

Going to push this back for the following reasons:

1. A limited number of people use this feature (and once 1.2.4 is released all the AIM users will no longer need to)
2. It requires a special order of operations for it to occur (re-opening the message window - and possibly even many times for the problem to occur)
3. It appears we will need more time to debug this; as such the solution may not be found until really close to the release of 1.2.4 - this type of bug should be tested in a beta for a long enough time prior to a release version.

I'd like to suggest this NOT be pushed back for the following reasons:

1. I was able to again duplicate this issue this morning. I opened the window, sent a message, said 'send later' and closed it (did not open it again). The person came online and the message was not sent.

2. I personally find AIMs implimentation of 'off-line messaging' to be a royal pain in the neck. Do I really need to receive TWO IMs when someone sends a message to me and I am offline? (1 has the actual message, which tells me when it was last sent... and the other is from AOL telling me I received a message! What the heck?!)

Just downloaded the newest Adium, which is suppose to have offline support for AIM. Yeah, it doesn't work so much..

Tuesday, April 1, 2008 10:29

Matt Hoppes AIM 10:29 Testing AIM. Please let me know if you get this. Thanks! Could not send the last message because it was too large. 10:29

Someone, please please please fix the offline bug. I prefer to have control of the sending message, anyway, rather than let AOL take control of it.

This is still set to be fixed for 1.2.5 - the next release. I assume this means you can reproduce this with 1.2.4 final still matth?

I have 1.2.4 now. When I try to send a message, and the person is offline, I get the above error from AOL. Is there a way I can get Adium to work the old way... so I can try the offline messaging again?

Replying to jas8522:

This is still set to be fixed for 1.2.5 - the next release. I assume this means you can reproduce this with 1.2.4 final still matth?

The problem matth is describing in the previous comments with serverside AIM offline messaging is unrelated to the problem in this ticket.

matth, please open a new ticket for the error you're receiving with AIM offline messaging.

I can open a new ticket, however, I feel that regardless of the status of AOL's offline messaging working with Adium... Adium's offline should be working. I see it is set to be fixed in 1.2.5, so that's good. I will open another ticket for the issue now being experienced.

Yes, I agree that bugs should be fixed. :)

Also, I'm getting the misleading 'message too large' error only when trying to send an offline message to a contact which doesn't actually exist (an invalid screen name). Sending to people on my list works fine.

Interesting. It is happening to me when I use accounts that are valid.

Matt Hoppes AIM 2:02 testing Could not send the last message because it was too large.

I was experiencing this bug on an MSN account, but since version 1.2.4 I haven't been able to duplicate it.

Opps, I lied. It just happened.