User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 ( .NET CLR 3.5.30729; .NET4.0C) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 From time to time I do a cleaning "party" of the big messages : I sort them by size, go to one of them and, according the content, delete the message, detach the attachment(s) or suppress it/them one by one or all at the same time : It is very annoying to see the message, on which I am working, disappear from the list and the content parts of the screen and to have to chase it far away in the whole list till I have finished to process it. Reproducible: Always Steps to Reproduce: 1. Have or create a list of big messages with more elements that your list part of the screen can show. I have obtained this list by creating a first message with 2 pictures (.jpg 0.5 M. Octets each) attached and 1 kO. of text from the clipboard and "test 1" in the subject line then I have sent it to myself using an address given by my ISP to have rapid reception. Then I have transferred the last sent message to myself adding the clipboard in the new text area and incrementing the figure after "test" in the subject. I have repeated this action until I have 9 big messages because my list part of the screen can show only 7. Now I have 2 mailbox to process "sent" and "inbox". 2. sort by size e.g. by increasing size and go to the bottom of the list (with decreasing size sorting you have to go to the top of the list) 3. select the top of the list message (i.e the smallest of the screen) and detach a picture. Actual Results: The current message become smaller that the first hidden one that was previously just smaller than it. The list is sorted. The current message disappear from the seen part of the list, is replaced by the just smaller one, the message just after the old current (bigger) one is now selected and shown. Expected Results: I think that there are 2 acceptable solutions for the user : 1) suppress the sorting after detaching/suppressing an attachment and keep all in place (correcting only the size information) and selected. Drawback : the processed message is not in good order in the list but it may be sorted again when I select a new message. 2) keep the sorting after detaching/suppressing an attachment and move the list part to show the processed message, still selected and shown in the content part, in the middle of the list part of the screen. This should be done according the new size information. Drawback : when I have finished to process the current message I have to go to the big side of the list (which remains in good order). Windows XP SP3

this sounds a lot like bug 557400

(In reply to comment #1) > this sounds a lot like bug 557400 Yes and no ! 557400 says "It should not impact the order of the messages in the thread." here it is "the order of the messages in the list part of the screen" or "move the list part to show the processed message" : this is similar and may have the same solution. Following the bugs referenced, I have found several of them with a difference as regard the parameter used to sort. There are "good" values e.g. "date" column that means the date sent header that is never (?) changed. It remains a synchronization problem between clocks in various PC but new versions of Windows allow to synchronize each one on some astronomical clocks. There are "bad" values e.g. "Order Received" that means the order in mailbox that is changed by detach, suppress and may be other actions. By the way I was not aware of this option that is not a default one. "Size" is also a bad choice because it is also changed by detach, suppress and may be other actions unfortunately I don't think it can be avoided when detaching. I think that : -users should be warned that there are "bad sort parameters" that may be changed by some actions and produce non permanent results. Advice being to avoid them. -all this bugs should be grouped, an architecture document produced to choose the best common solution, then be corrected.

(In reply to comment #1) > this sounds a lot like bug 557400 and even that should probably be a dup of bug 383985. or perhaps something else because I am sure there are more reports. don't have time to investigate myself

(In reply to comment #3) > (In reply to comment #1) > > this sounds a lot like bug 557400 > > and even that should probably be a dup of bug 383985. or perhaps something > else because I am sure there are more reports. don't have time to investigate > myself No : bug 383985 is about threads sorted by "date sent", "date received" or "Order Received" in fact order in the mailbox. Mine is about sort by size. Yes : there is a whole family of similar bugs that have a similar origin. At the beginning the messages or threads have been sorted according a particular parameter, an action is done by the user on a message and this change the value of the particular parameter used to sort again at the end of the action, so the order is changed : the user is unhappy and there is the risk of a wrong next action and lost of data... From a bug to an other in the family the parameter used to sort and/or the action change.

Jean-maries does https://wiki.mozilla.org/MailNews:Message_Threading#Preferences_Controlling_Threading contains anything that might help solve your issue ?

I have taken a look at the reference but I am too much a newbie ! Where is "mailnews/db/msgdb/src/nsMsgDatabase.cpp" ? I have searched my profiles and Thunderbird without success. Then I have asked my file manager to find "nsMsgDatabase.cpp" in the previous directories, then in my whole disk : nothing found ! No more results with "mail.strict_threading" as text in the directory. Please give instructions to find the values of the parameters described in this part of the wiki..

Sorry for the previous comment 6. I may have found something : pref("mail.thread_without_re", false); // if false, only thread by subject if Re: pref("mail.strict_threading", true); // if true, don't thread by subject at all pref("mail.correct_threading", true); // if true, makes sure threading works correctly always (see bug 181446) it is located in the thunderbird directory in \defaults\pref\mailnews.js When I found the bug I have not asked to sort by thread but only by size (using a click in the size column that I have added to my display).