just kidding - figured this out.  we weren't merging overview info 
correctly to already existing cache entries.  this has been fixed.

I used to get these errors myself . . . until I implemented some code 
a few days ago.  This used to happen when a body structure was the 
first object created for a UID (for example, a new message that comes 
in when you are in the message screen will create the structure cache 
object only in IMP_Contents).  then, when you would go back to the 
mailbox screen, the overview object would not be cached so you would 
get all the undefined errors.



However, I thought this commit fixed this:

http://lists.horde.org/archives/cvs/Week-of-Mon-20051107/050680.html

The logic is as follows - if no mailbox cache exists, $ret_load is 
false and this information must be obtained from the IMAP server.  If 
$ret_load is true, the mailbox cache exists and we loop through the 
message array.  Every message index that does not contain a uid entry 
in the cache (the uid variable only exists if overview info is stored 
in the cache) is flagged for retrieval by the IMAP server.



Long story short, I experienced the same behavior in the same 
conditions as you report (on a reproducible basis).  However, I have 
not seen this a single time since I made the above mentioned change.   
And i can't reproduce it now.

The steps to reproduce this are to _either_ delete multiple messages 
from the message view, or to delete multiple messages in the message 
view where the final message is one that arrived while you were going 
through messages. I think just the former is necessary, butI haven't 
narrowed it down.



Anyway, when these conditions are met, the mailbox view goes unstable, 
throwing a bunch of "access to undefined property standardClass::$uid" 
errors, and the link to the final deleted message doesn't work. Seems 
that the cache for it has been cleared and it's not, in this case, 
being re-read.