Closed Bug 7147 Opened 25 years ago Closed 25 years ago

[PP]Drop-down menu does not show folder when selecting Move and Copy Message

Categories

(MailNews Core :: Backend, defect, P2)

Product:
MailNews Core
Component:
Backend
Platform:
Other
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 11187

People

(Reporter: fenella, Assigned: jefft)

References

Details

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.
Assignee: phil → putterman
Priority: P3 → P2
Reassign to putterman, cc alecf
Summary: [PP]Drop-down menu does not show folder when selecting Move Message → Drop-down menu does not show folder when selecting Move Message
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.
Assignee: putterman → jefft
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?
Status: NEW → ASSIGNED
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.
QA Contact: lchiang → nbaca
Summary: Drop-down menu does not show folder when selecting Move Message → [PP]Drop-down menu does not show folder when selecting Move Message
*** Bug 8062 has been marked as a duplicate of this bug. ***
Target Milestone: M9
M9 ...
Summary: [PP]Drop-down menu does not show folder when selecting Move Message → [PP]Drop-down menu does not show folder when selecting Move and Copy Message
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.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
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.
Status: RESOLVED → VERIFIED
Will mark as verified duplicate.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.