Adium

Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#9082 closed defect (fixed)

Custom Status dialog does not pre-populate with previous message

Reported by: markbach Owned by: evands
Milestone: Adium 1.2.2 Component: Adium Core
Version: Severity: regression
Keywords: status, status message, custom status, away, away message Cc:
Patch Status:

Description

Prior to version 1.2.1, the "Custom Status" dialog box was pre-populated with the previous custom status. In 1.2.1, that no longer happens.

Steps to Reproduce:

  • Open the Custom Status dialog, either by command-y or Status Menu -> Custom....
  • Populate the Status Message field with some text.
  • Check the Auto-reply and Appear Idle Immediately boxes, as shown in Figure 1
  • Click the OK button to set the Away status.
  • Wait a short period of time (say, 30 seconds).
  • Return from Away status by command-y or clicking the Return button on the Current Status window.
  • Wait at least 60 seconds. The bug does not seem to manifest if you do not remain Available for at least a minute.
  • Open the Custom Status dialog, either by command-y or Status Menu -> Custom....
    • In 1.2.0 and previous, the Custom Status dialog would be pre-populated with your previous status message and the appropriate boxes checked.
    • In 1.2.1, the Custom Status dialog is blank and the checkboxes are returned to defaults.

I have confirmed this occurs on the following:

  • Mac G5 (PowerPC) running 10.4.11
  • MacBook Pro (Intel) running 10.4.11

IRC user greatcaffeine was able to reproduce this on

  • Macbook Pro (Intel) running 10.5.1

Attachments (1)

Figure 1.png (33.4 KB) - added by Mark 12 years ago.
Figure 1: An example of how the Custom Status dialog should look

Download all attachments as: .zip

Change History (6)

Changed 12 years ago by Mark

Attachment: Figure 1.png added

Figure 1: An example of how the Custom Status dialog should look

comment:1 Changed 12 years ago by Jordan

Milestone: Adium X 1.2.2
Severity: normalregression

I can confirm... I didn't use that feature often enough before 1.2.1, but I *thought* that was there... it seems so cumbersome to set my status again now.

comment:2 Changed 12 years ago by Evan Schoenberg

Owner: changed from nobody to Evan Schoenberg
Status: newassigned

comment:3 Changed 12 years ago by Evan Schoenberg

Turns out this is actually ancient bad behavior... when the preference controller kept everything in memory all the time (1.2 and before), we didn't properly save this across sessions. Now that we dump our in-memory cache after 60 seconds of non-use, the bug appears within a single session. Fantastic reporting, thanks!

comment:4 Changed 12 years ago by Evan Schoenberg

Resolution: fixed
Status: assignedclosed

(In [22539]) Don't use an NSNumber key in a dictionary which will be saved as a preference, as this prevents the entire preference group from saving; you must use an NSString. We now have logging which points the problem out.

Fixes #9082 (Custom status pre-population with previous message. Fixes #225 (yes, a ticket from 3 years ago!) which was previously very, very mysterious - the preference in question is in the same group as the last-status preference, which is why it wouldn't save.

comment:5 Changed 12 years ago by Evan Schoenberg

(In [22540]) Merged [22539]: Don't use an NSNumber key in a dictionary which will be saved as a preference, as this prevents the entire preference group from saving; you must use an NSString. We now have logging which points the problem out.

Fixes #9082 (Custom status pre-population with previous message. Fixes #225 (yes, a ticket from 3 years ago!) which was previously very, very mysterious - the preference in question is in the same group as the last-status preference, which is why it wouldn't save.

Note: See TracTickets for help on using tickets.