Closed
Bug 7147
Opened 26 years ago
Closed 26 years ago
[PP]Drop-down menu does not show folder when selecting Move and Copy Message
Categories
(MailNews Core :: Backend, defect, P2)
Tracking
(Not tracked)
M9
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.
Updated•26 years ago
|
Assignee: phil → putterman
Priority: P3 → P2
Comment 1•26 years ago
|
||
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.
Updated•26 years ago
|
Assignee: putterman → jefft
Comment 3•26 years ago
|
||
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?
Comment 5•26 years ago
|
||
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?
Comment 6•26 years ago
|
||
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?
Comment 7•26 years ago
|
||
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.
Comment 8•26 years ago
|
||
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.
Comment 9•26 years ago
|
||
Yes, we need to set the mailbox name explicitly when we discover new mail
folders.
Comment 10•26 years ago
|
||
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?
Comment 11•26 years ago
|
||
Yes. What's Related is a perfect example of a streaming menu. We have
several menus that are like that...
Comment 12•26 years ago
|
||
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.
Comment 13•26 years ago
|
||
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.
Comment 14•26 years ago
|
||
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.
Comment 15•26 years ago
|
||
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.
Comment 16•26 years ago
|
||
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.
Summary: Drop-down menu does not show folder when selecting Move Message → [PP]Drop-down menu does not show folder when selecting Move Message
Comment 17•26 years ago
|
||
*** Bug 8062 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 18•26 years ago
|
||
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
Reporter | ||
Comment 19•26 years ago
|
||
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
Comment 20•26 years ago
|
||
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.
Comment 21•26 years ago
|
||
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.
Comment 22•26 years ago
|
||
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: 26 years ago
Resolution: --- → DUPLICATE
Assignee | ||
Comment 23•26 years ago
|
||
Comment 24•26 years ago
|
||
Yes. As far as I know this bug was fixed. The original problem in this bug
isn't the problem we are seeing now.
Comment 25•26 years ago
|
||
Will mark as verified duplicate.
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•