User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 When a new mail alert comes up and I click on it to open the message, the message opens in the preview pane as normal, but the message list it's in is not the smart inbox as I would expect. Instead, the specific inbox of the account it arrived in is opened (as a subfolder of the smart inbox), and as an apparent consequence, the inbox's parent account is expanded in the tree. Reproducible: Always Steps to Reproduce: 1. Ensure that you're in Smart Folders View, 3-pane. 2. Collapse all folders in the folder pane. 3. Email a test message to yourself; check for new messages if necessary. 4. When the mail alert comes up, click on it to open the email. Actual Results: Email is selected in preview pane, with its containing inbox selected in the folder pane and its account expanded in the folder pane tree. Expected Results: Email to be selected in preview pane, with Smart Inbox selected in the folder pane and folder pane tree state unchanged.

Setting correct TB version. Discovered something else: actually, does not expand Smart Inbox to select containing inbox if it's collapsed. However, it does expand containing account, which is ugly and undesirable.

Oops, sorry, not a duplicate.

Marking new based on dulicates.

symptoms aren't an exact match to bug 527731, but you don't think the underlying cause is the same?

I'm not sure; I have no particular idea what the code looks like in that place, but the bugs do sound similar at least (so much so that I got confused earlier and marked them duplicate). It's good to link the bugs, I guess, but on the chance that they're different, I figured it'd be best to keep them separate. The main difference between them seems to be that this bug is about altering the expanded state of the folder tree, and bug 527731 is about altering the selected folder pane view. Both, of course, are triggered by the same event: clicking on a new mail alert. I should also add, though, that there are actually a few other cases that I've seen that will repro this bug. One is using the N shortcut key in a different folder to jump into the smart inbox; this likewise expands the parent account of whatever message is then selected in the inbox. Offhand I can't remember the others (though presumably the P key works similarly), but all have the common thread of selecting a message in the smart inbox by something other than direct mouse or keyboard selection within the smart inbox. I don't know if these other cases can be seen to repro bug 527731.

No, bug 527731 is in all probability different. This really needs special-casing for the smart inbox it seems.

However, bug 536042 should fix both.

This is on top of the patch in bug 536042. Bryan, could you confirm that we want this to happen? It does make sense for smart folders to have the smart inbox selected instead of the actual inbox they're in.

Comment on attachment 419300 [details] [diff] [review] patch + mozmill tests, v1 I can only make the nittiest of complaints :-) a) and b) reads a bit better. a. a + * non-null folder is returned, and that b. the folder that is returned + * actually does contains the message header. + // The message itself doesn't really matter, as long as there's at least one + // in the inbox period at the end of the comment sentence.

Comment on attachment 419300 [details] [diff] [review] patch + mozmill tests, v1 looks correct to me, thanks sid!

(In reply to comment #8) > No, bug 527731 is in all probability different. This really needs > special-casing for the smart inbox it seems. See https://bugzilla.mozilla.org/show_bug.cgi?id=539392 that describes what goes wrong when a Folder is selected that is hidden under a collapsed Smart Folder.