Executing test 7750. 1. make sure mail.operate_on_msgs_in_collapsed_threads is set to true 2. Select one thread and some messages 3. Select the thread from the summary view The thread then changes from collapsed to un-collapsed. Maybe the test is incorrect as the results I noted are that the thread should not change from collapsed state.

The patch in bug 494811 landed after this was filed; it's worth re-testing, I suspect.

(In reply to comment #1) > The patch in bug 494811 landed after this was filed; it's worth re-testing, I > suspect. Behaviour is still present in Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 (Build1)

https://litmus.mozilla.org/single_result.cgi?id=260408 filed a bug report. which would make bug 567641 a duplicate of this sbug.

davida, Can you confirm the desired behavior for https://litmus.mozilla.org/show_test.cgi?id=7750 i.e. at step 2 the thread stays collapsed or expanded depending on the original state? Currently, that is not happening.

Hmm. Indeed. I'm seeing that when I select a thread heading in the summary page, the thread gets expanded. I would say it's likely a real bug, and likely a regression. I don't know that it's very serious, however. It's most likely a problem for really long threads.

I tried to find the regression range but on Windows 7 TB crash using release 200901xx or 200903xx :-( http://crash-stats.mozilla.com/report/index/bp-e46cb1a8-2d48-4cb1-b8c4-5e2742100526

bp-e46cb1a8-2d48-4cb1-b8c4-5e2742100526 is thunderbird.exe@0x63d947 which doesn't match up to anything useful, and I suppose we can ignore if it cant be reproduced in current nightly builds. 0 thunderbird.exe thunderbird.exe@0x63d947 1 thunderbird.exe thunderbird.exe@0x63ff54 2 thunderbird.exe thunderbird.exe@0x581a37 3 thunderbird.exe thunderbird.exe@0x583353 4 ntdll.dll RtlpLowFragHeapAllocFromContext 5 urlmon.dll urlmon.dll@0xf67b5 6 ntdll.dll RtlpLowFragHeapAllocFromContext