Using mar6 commercial trunk build Something happened recently and you can no longer select the account level when using acct/folder hierarchy dropdowns such as with New Folder or Search Messages. The "choose this folder" line is no longer displayed, however if you do select the (nonexistent) selection it will work. 1. From mail window, Search|Search MailNews Messages. 2. Try to select another account at the account level, i.e. account level for Local Folders. Result: "choose this folder" or substitute for it is missing. Expected: an easily identifiable selection for account level to be offered and selectable. Note: seen with New Folder and Search Messages dialogs. Does not apply to Move/File/Copy messages. Can't think off-hand if there'd be another applicable dialog.

Doh. Of course it would apply when moving messages to a folder with subfolders, to choose the parent folder.

*** Bug 71104 has been marked as a duplicate of this bug. ***

I see this too. It makes it so it's very hard to move/copy messages. marking nsbeta1+ and moving to mozilla0.8.1. Reassigning to racham. cc'ing naving. Can one of you guys look into why all of our folder menus are messed up?

*** Bug 71311 has been marked as a duplicate of this bug. ***

This is a regression (most probably indirect) introduced sometime between 3/5 and 3/6. Mailnews seems to be the only app affected by this. Looking at all possible cases. Working ont it. Will update status as I find things.

Tried backing out couple of suspicious changes. But still didn't option in the menupopup to select the main folder. Will look at couple of more things. We need hyatt's help here. Adding him to the cc list.

Adding hewitt to the cc list.

We have a solution now. Thanks to hyatt & hewitt. Today, we have menuitem resources under the template builder as uri="..." and that caused it to always have a menupopup child. It has been like that all along. Then on 5th, hyatt made xbl rules more strict and did not allow any children under menuitem. So, that caused this regression. So, all references to resources (uri="...") for menuitems in these cases have to be removed. I will post a patch with these changes covering all broken mailnews cases. As there is a big merging effort going on with tip (perf branch with tip) rightnow, it will be better to land this patch on the 0.8.1 branch when it is cut.

patch coming up...

racham, this bug is exactly the same as your File Here bug. You have an incorrect uri="..." on static objects inside the template that causes the template builder to place a <menupopup> underneath a <menuitem>. Now that the <menuitem> binding has been properly tightened up to disallow this, the anonymous content is not going to be built. JUst patch your code to remove the uri="..." so the template builder will not build a <menupopup> underneath a <menuitem>.

testing all cases now..

Discovered some problems with Move and Copy routines which take event.target as input param. Removing the resource reference (uri="...") made event.target useless as there will be no resource id to be associated with the selection we make on the menus presented. Spoke to hyatt about this. The current template structure allows us to depend on the grandparent (a menu) here to pass the right target (i.e., event.target.parentNode.parentNode) to the MsgMoveMessage and MsgCopyMessage functions to obtain the correct RDF resource. So, I am changing all instances that need to be changed accordingly. Changing the Summary to 'working on patch'. I will list out all test cases, once I am done with this patch.

*** Bug 72568 has been marked as a duplicate of this bug. ***

*** Bug 72594 has been marked as a duplicate of this bug. ***

Gayatri, Seth and Hyatt, please review/super-review the patch (will send a separate mail). thanks.

looks good, sr=sspitzer

The diffs look good. Aorry about the delayed review. I guess you are using 0.8.1 build and it is fine, but in the latest builds, you would have to change all menuitem value= to menuitem label= to make this a valid patch. r= gayatrib

Updating the status whiteboard to reflect the finished reviews and the testing I did on mailnews menus with this patch. I just spoke to Asa. He is in the process of final round testing for 081 bits. So, if he finds some regression/problem that must be fixed, then this bug has a chance to get in. thanks to Asa for the info. Also, there is another bug (72242) where one of the hewitt's modern skin changes got onto the trunk and missed 081 branch. It is very simple I would like to get that one also in, if we have a chance. Anyway, Asa already added relnote 0.8.1 update to the status whiteboard here. Will do the same for bug 72242 also.

*** Bug 73454 has been marked as a duplicate of this bug. ***

*** This bug has been marked as a duplicate of 72498 ***

Marking verified as duplicate.

*** Bug 72594 has been marked as a duplicate of this bug. ***