RE: Linux build (1999-05-25-16-m6] 1. prefs50.js consists of 1 pop 1 Imap and 1 news server 2. Open Messenger from the Task menu 3. Select the Imap account, select a message from the INbox folder 4. Select Message|Move Message, it shows the mail server, which is nsmail-5 5. Click on nsmail-5, the drop down menu only shows the default folders, it does show folders that I created. This does not occur in windows. Have not tested Mac yet This may not be in the M6 feature. If you think I should not write a bug on this, please let me know.

Reassign to putterman, cc alecf

I am indeed seeing this on NT4.0 using 1999052517, but it is not consistent in its display. Sometimes in place of the folders other than default is garbage characters. Sometimes there are duplicate Inbox entries in the submenu although messenger's folder pane listing is fine. I would imagine this would also happen on mac, although there is a bug #6862 on mac which prevents seeing folders other than (IMAP) inbox. Therefore I'm removing the [PP] from summary.

reassigning to jefft. The problem is in nsImapMailFolder's GetName. The first time through dbFolderInfo->GetMailboxName returns an empty string. After that, because of the flag you set, it always gets the name from the uri. Therefore the first Move Menu is wrong, but the second move menu and the folder tree are correct. This is only happening on Linux. I think there might be two things wrong here. One is that GetName uses the name from the dbFolderInfo the first time, but uses the uri to get the name every time afterwards. The second is that GetMailboxName is returning an incorrect value. Laurel, are you only seeing this on Imap?

Scott P., when do we build the Move/Copy message menu item list? It seems that we are building it when we start up the 3-pane message window. This won't work for imap. I think we need to be able to dynamic building the menu item when we discover new mail folders from the server. Any ideas how? David, the database seems not saving the database name. The funny thing is Inbox.msf does have the database name saved but the others not. Do we need to set the database explicitly when we discovered new mail folders?

Adding hyatt and saari for their advice. These menus are RDF menus and appear to be getting built when mailshell.xul is built. At one point I think they used to get built when you selected the menu, but not anymore. First, in response to Jeff: A problem I see is that you must be telling GetTargets that you have subfolders, otherwise it wouldn't be asking for their names. If you really have to discover the folders before their names can be displayed in the menu, then I think you should be returning that there are no subfolders. A question for hyatt or saari: Are RDF enabled menus set up as observers on the datasource I specified? If we don't add items when the menu gets built up originally, but then add items later on through folder discovery, will these changes be reflected in the menus?

Right now? No. We aren't handling "streaming" menus yet. Is that what you're running into? i.e., your kids aren't immediately available so you stream them in one by one?

Right now we aren't running into it for this case, but I think Jeff's suggesting that the fix for this bug might be to do that. We also have the case where a user creates a new folder. We'd need that to show up in the menu as well. I imagine the browser has the same case for bookmarks.

We ARE handling the case where dynamic insertion happens, but we don't handle this while the menu is visible (i.e., if you try to open the menu and then need to wait a while for the children to trickle in). If you don't have the menu visible at all, then on GTK and WINDOWS only, it will pick up the new content. Let me ask a question. Are you nesting builders inside builders? If so, in the current code, that would cause the nested builder not to be able to show anything... e.g., if you have one datasources tag on a menu node that is a child of another menu node that also has a datasources tag. If you have that situation, then the "outer" builder is going to usurp control from the "inner" builder.

Yes, we need to set the mailbox name explicitly when we discover new mail folders.

I don't think we have the nested builders problem. I think having the menu change while not visible is sufficient for our needs. Someone correct me if I'm wrong. Are you planning on making it update while the menu is open? Does What's Related take advantage of that?

Yes. What's Related is a perfect example of a streaming menu. We have several menus that are like that...

No, we're not planning on having updates to visible menus, streaming as hyatt called it. That would be... difficult to say the least. Not to mention the user experience of things literally changing under you. Not cool.

We aren't? We have several menus that worked that way in MozillaClassic, and some of the RDF data depends on being able to stream. I thought streaming was a requirement.

Worst case I suppose we could just say 'Retrieving data...' the first time the user hits the menu and then if the user comes back to it later, it could show the real contents. What's Related in 4.x, however, updates dynamically once the children are ready.

You didn't have this on MacOS, that is for sure. I still maintain that this is bad UI, but I suppose it can be done if we really have to.

yes, it's pretty strange from a UI perspective, but the alternative is having stuff in the bookmarks tree that can't be viewed in the bookmarks menu. Maybe that's ok.

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

M9 ...

Aug 3 builds Linux (1999-08-03-08 m9) and Win_nt (1999-08-03-13 M9) The same problem happens to Copy Message. modify summary to read: [PP]Drop-down menu does not show folder when selecting Move Message and Copy Message

This is a dup of some other bug I don't know the number of. RDF menus stopped working when XP Menus were added over the weekend.

I just saw that bug: it's http://bugzilla.mozilla.org/show_bug.cgi?id=11187. Will let the developers decide which one to mark as a duplicate.

Hmm. These _were_ working before, right? (I saw them with my own eyes...) If so, let's close out this old bug and just track through 11187, which has to do with the XPMenu/RDF bustage.

Mark it as duplicate of bug 11187. *** This bug has been marked as a duplicate of 11187 ***

Yes. As far as I know this bug was fixed. The original problem in this bug isn't the problem we are seeing now.

Will mark as verified duplicate.