clean profile - Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081121 Shredder/3.0b1pre 1. move a message to a different folder 2. folder name (if there is one) in context menu or message menu doesn't change the "recent" menu seems to be OK I tried 11/19 with same results

prefer to have working again on trunk - not nice usage regression - range 11-10, 11-13 potential dataloss of sorts, since you can send a messages to a folder and not realize it went to the wrong folder

this WFM - I just tried a few different local folders. Are you using the menu or the keyboard accelerator? Are you moving with the menu?

Seems WFM on linux/trunk too. Or is something missing from the STR?

fails hourly build Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081113 Shredder/3.0b1pre ID:20081113023817 works Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081112 Shredder/3.0b1pre ID:20081112031406 so non-RDF folder pane is still prime suspect. but don't know why fails for me and works for others. http://hg.mozilla.org/comm-central/pushloghtml?startdate=11%2F12%2F2008+03%3A14&enddate=11%2F13%2F2008+02%3A38 to clarify what happens with 20081113023817... ctrl+shift+M move/copy again does move a message, and recent menu for copy and move is updated, HOWEVER, the folder name associated with ctrl+shift+M is not updated, it points to the folder last used with build 20081112031406 Steps: 1. using 11-12 build, copy a message from fold A to folder B 2. using 11-13 build, copy a message from fold A to folder C 3. select a message in any folder and ctrl+shift+M Result: message is copied to folder B, not folder C - but C was the last folder copied/moved to

Yes, I can reproduce with the STR given.

sorry, forgot to include build ID: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081123 Shredder/3.0b1pre. This is my own build (opt), not a nightly.

add datatloss keyword - you might go hours/days without realizing that your messages are not going to the expected folders (as I did) bonus points for also providing a solution to bug 456444

I'm going to mark blocking b1 for dataloss, and try some more to reproduce this.

we were just setting the wrong prefs...

jminta points out this would work as well.

Comment on attachment 350029 [details] [diff] [review] proposed fix, v2 Yet another reason to get rid of global variables. A whole bug caused by having such a variable defined with an unnoticeable name...

Joey, is anything already proposed to replace global variables? Just wanna look into this if there anything.

fix checked in.

(In reply to comment #12) > Joey, is anything already proposed to replace global variables? Local ones (where it makes sense).

Just in case a big long explanation will forestall confusion somewhere down the line: This bug occurred because the code wanted to use a local, |let prefBranch = Cc["@mozilla.org/preferences-service;1"]...|, but because there is a global named pref, the typo of using |pref.setCharPref| rather than |prefBranch.setCharPref| wasn't immediately caught with a "pref.setCharPref is not a function" error - pref.setCharPref() is a function, just a function that sets "last_msg_movecopy_target_uri" rather than the "mail.last_msg_movecopy_target_uri" that prefBranch.setCharPref() would have. That's one of the reasons globals are a bad thing: every single function inherits hundreds of variables and functions that will mask typos by doing other, unexpected things rather than producing errors.