Adium

Opened 14 years ago

Closed 13 years ago

Last modified 12 years ago

#5899 closed defect (fixed)

%_iTunes script erroneously affecting AIM based accounts' status

Reported by: jmpp Owned by: eharris
Milestone: Component: Plugin
Version: Severity: regression
Keywords: %_iTunes, away status, AIM Cc:
Patch Status:

Description

I created a custom status for all of my accounts: Status Menu --> Edit Status Menu... (last entry) --> create new status (plus sign) --> set "State" to Away --> set "Status Message" to the %_music script. For my .Mac and GTalk accounts, this custom status updates my status message (while keeping my Away status intact) with every playing song in iTunes as I have the %_statusMessage script entered in Preferences --> Personal --> Name. This worked flawlessly up until b15, but with b16 (libgaim's oscar back in action) I am experiencing an easily reproduceable error:

  • switch to iTunes and pause the song;
  • all AIM based accounts (my own .Mac and Catfish_man's test AIM account) erronouesly return from away;
  • my GTalk account is not affected;
  • my MSN account, which I purposefully set to not update my display name with the %_music script's value, is not affected either;

Resuming the song will once again set the affected accounts back to Away, as they should always be. Again, Panther system here, which might have some bearing on the issue as eharris and durin42 told me on IRC they couldn't reproduce the issue on Tiger. I'm available for any testing you guys might need.

-jmpp

Change History (13)

comment:1 Changed 14 years ago by Juan Manuel Palacios

Version: 1.0b16

comment:2 Changed 14 years ago by Juan Manuel Palacios

Severity: normalregression

This defect is a regression from previous beta builds, so I'm setting the severity accordingly.

-jmpp

comment:3 Changed 14 years ago by Elliott Harris

This is actually a bug with %_iTunes as confirmed by the reporter. I have been able to reproduce this and I'm working on a fix.

comment:4 Changed 14 years ago by Juan Manuel Palacios

Component: AIMPlug-Ins
Keywords: %_iTunes added; %_music removed
Summary: %_music script erroneously affecting AIM based accounts' status%_iTunes script erroneously affecting AIM based accounts' status

I made a rather significant mistake when I first described this problem: it's not the %_music script that's failing in the way described above, it turns out I've been using %_iTunes and that's what's exhibiting the problem in b16. Upon this correction, eharris told me on IRC he managed quite easily to reproduce the problem.

TIcket has been adapted accordingly (except for the original description, which I don't have access to), sorry for the confusion guys! /me now hides under a rock :-(

-jmpp

comment:5 Changed 14 years ago by Elliott Harris

Owner: changed from nobody to Elliott Harris
Status: newassigned

comment:6 Changed 14 years ago by Evan Schoenberg

Any word on this?

comment:7 Changed 13 years ago by Jordan

Patch Status: None
Resolution: worksforme
Status: assignedclosed

Closing due to inactivity.

comment:8 Changed 13 years ago by Juan Manuel Palacios

Resolution: worksforme
Status: closedreopened
Version: 1.0b161.0.3b3

Sorry for not getting back on this and the resulting inactivity, didn't see any email when Evan pinged for status. I am reopening the ticket since it's still an issue with 1.0.3b3, when %_iTunes is selected as the status and the song is paused, aim based accounts (.Mac in my case) erroneously return from away.

-jmpp

PS: I originally reported this bug from a Panther system, but now I'm on Tiger and I can confirm it's happening here too.

comment:9 Changed 13 years ago by Jordan

Milestone: Needs feedback from users

Can you post any relevant debug logging from the beta release when this happens? You should be able to enable it from the Adium menu -> Debug Window.

comment:10 in reply to:  9 Changed 13 years ago by Juan Manuel Palacios

Replying to jas8522:

Can you post any relevant debug logging from the beta release when this happens? You should be able to enable it from the Adium menu -> Debug Window.

Sure, here it is, as detailed as I can make it:

Going from available to away ("The one who can't be found!" for status message):

21:23:41: Encoded to <HTML>The one who can't be found!</HTML> for no contact
21:23:41: Setting status on 7917c30 (jmpalacios@mac.com): ID away, isActive 1, attributes {message = "<HTML>The one who can't be found!</HTML>"; }
21:23:41: (Libgaim: oscar) Set status to Away
21:23:41: <ESPurpleDotMacAccount:7902180 3>:jmpalacios@mac.com: Updating status for key: StatusState
21:23:41: (Libgaim: blist) Updating buddy status for jmpalacios@mac.com (AIM)
21:23:41: (Libgaim: blist) Updating buddy status for jmpalacios@mac.com (AIM)
21:23:41: (Libgaim: blist) Updating buddy status for jmpalacios@mac.com (AIM)
21:23:41: (Libgaim: blist) Updating buddy status for jmpalacios@mac.com (AIM)

Setting status to away and status message mesage to %_iTunes, no song playing:

21:24:39: Encoded to <HTML></HTML> for no contact
21:24:39: Setting status on 7917c30 (jmpalacios@mac.com): ID away, isActive 1, attributes {message = "<HTML></HTML>"; }
21:24:39: (Libgaim: oscar) Set status to Away
21:24:39: <ESPurpleDotMacAccount:7902180 3>:jmpalacios@mac.com: Updating status for key: StatusState
21:24:39: (Libgaim: blist) Updating buddy status for jmpalacios@mac.com (AIM)
21:24:39: (Libgaim: blist) Updating buddy status for jmpalacios@mac.com (AIM)

At this point, my .Mac account went back to available, at least on the contact list.

Started playing a song (no manual changes to the status nor the status message):

21:26:59: Encoded to <HTML>You Don't Fool Me - Queen</HTML> for no contact
21:26:59: Setting status on 7917c30 (jmpalacios@mac.com): ID away, isActive 1, attributes {message = "<HTML>You Don't Fool Me - Queen</HTML>"; }
21:26:59: (Libgaim: oscar) Set status to Away
21:26:59: <ESPurpleDotMacAccount:7902180 3>:jmpalacios@mac.com: Updating status for key: StatusState
21:26:59: (Libgaim: blist) Updating buddy status for jmpalacios@mac.com (AIM)
21:26:59: (Libgaim: blist) Updating buddy status for jmpalacios@mac.com (AIM)
21:27:00: (Libgaim: blist) Updating buddy status for jmpalacios@mac.com (AIM)
21:27:00: (Libgaim: blist) Updating buddy status for jmpalacios@mac.com (AIM)

Account is back at away now.

Paused the song (again, no manual changes to the status nor status message):

21:27:09: Encoded to <HTML></HTML> for no contact
21:27:09: Setting status on 7917c30 (jmpalacios@mac.com): ID away, isActive 1, attributes {message = "<HTML></HTML>"; }
21:27:09: (Libgaim: oscar) Set status to Away
21:27:09: <ESPurpleDotMacAccount:7902180 3>:jmpalacios@mac.com: Updating status for key: StatusState
21:27:10: (Libgaim: blist) Updating buddy status for jmpalacios@mac.com (AIM)
21:27:10: (Libgaim: blist) Updating buddy status for jmpalacios@mac.com (AIM)

Account is available again.

Anything else you might need? Always glad to provide as much feedback and help as I can, short of a patch since I'm no Cocoa dev and don't know any Adium internals ;-)

-jmpp

PS: As a side note, it'd be good to migrate that logging to "Libpurple"

comment:11 Changed 13 years ago by Evan Schoenberg

Resolution: fixed
Status: reopenedclosed

(In [19551])

  • Setting a null away message on AIM is actually impossible. You must set "Away" or the like to indicate away-with-no-message. Libpurple handles this automatically if we pass a null message.. but "<HTML></HTML>" gets parsed out by the server to be null without passing the null check in libpurple. If an AIM account is asked to encode an attributed string for status purposes, it now returns nil if that string is 0-length, rather than passing it to the HTML encoder.
  • Given the above, it's preferably to use our own translations of away. Removed the restriction that we only reinterpret the status message if it's not a generic away; we now do this for all 0-length away messages regardless of type.

Fixes #5899.

comment:12 Changed 13 years ago by Evan Schoenberg

(In [19552]) Merged [19550]: Prefs migration. Also, fixed debug string to say 'libpurple'.

Merged [19551]:

  • Setting a null away message on AIM is actually impossible. You must set "Away" or the like to indicate away-with-no-message. Libpurple handles this automatically if we pass a null message.. but "<HTML></HTML>" gets parsed out by the server to be null without passing the null check in libpurple. If an AIM account is asked to encode an attributed string for status purposes, it now returns nil if that string is 0-length, rather than passing it to the HTML encoder.
  • Given the above, it's preferably to use our own translations of away. Removed the restriction that we only reinterpret the status message if it's not a generic away; we now do this for all 0-length away messages regardless of type.

Fixes #5899.

comment:13 Changed 12 years ago by Robert

Milestone: Needs feedback from users
Note: See TracTickets for help on using tickets.