Folder properties dialog should show folder file name. In some cases file name is different from displayed folder name. For example, if a folder is named as "So" on Windows, its file name is 3db4214a. See bug 117385. That's very inconvenient when a user wants to import Mozilla's mail message to an another mail client.

Same enhancement request for Thunderbird is Bug 369393.

> Same enhancement request for Thunderbird is Bug 369393. Not even CLOSE to the same request. This bug (bug 180546) requests the addition of information to properties dialog. That's fine. Bug 369393 requests the removal of a feature from the folder context menu. That change was made to SeaMonkey, taking a way a frequently used feature! I'd call upon the Sherrif to back out the patch for Bug 369393, but such requests have not had useful effects for some time.

(In reply to comment #2) > I'd call upon the Sherrif to back out the patch for Bug 369393 Nelson, thanks for it. (Off-Topic) I hope Bug 358187 won't have relation to Seamonkey...

Required/convenient information in property(especially for problem isolation): (A) Local mail folder (A-1) mailbox: URL, (A-2) file path, (A-3) file size etc. (B) IMAP folder (B-1) imap: URL, (B-2) file path, (B-3) file fize etc. (C) News (C-1) news: URL, (C-2) file path, (C-3) file size etc. (A memo) "Copy Folder Location", which was removed by Bug 369393 recently, is for (A-1), (B-1), (C-1). Note: When Japanese folder name, clip board data for (A-1) becomes different one(looks garbage, probably UTF-16 binary) from escaped internal mailbox: URL in prefs.js or messageFilterRules.dat. This is independent/different problem from this bug. I can accept removal of "Copy Folder Location" in context menu, if property will have all of (A-1)/(B-1)/(C-1), because I rarely use "Copy Folder Location" due to above problem in Japanese folder name, and because I don't use IMAP. But I'm sure that removal can't be accepted for users who already use "Copy Folder Location". (operation after removal) 1. Right click mail folder(or newsgroup) 2. Click "Properties..." 3. Click Genaral(or someting) Tab 4. Click URL field 5. Select URL characters 6. "Copy" in context menu or menu, or CTRL+C(or Command+C)

In reply to comment 3: bug 358187 already HAD caused a regression in SeaMonkey. It has caused the "Copy Folder Location" item to be removed from the folder context menu. If TB wants to drive away its users, that's OK with me, but I'd prefer that SM did not do so. It appears that that change is a regression forced on SM even though it was not desired by SM, and that SM must now do extra work to restore the feature that they removed to fix the regression. Will that work be done in this bug? Or shall I file another bug about the regression?

Sorry, my mistake about the bug number. Bug 369393 already HAS caused ...

(In reply to comment #5) > Will that work be done in this bug? Or shall I file another bug about the regression? I think separate bug for the regression is better to track problem.

I filed bug 394578 about the SM regression. Lots of commenters there mistakenly believe that the "copy folder location" feature merely copied the name of the newsgroup, e.g. "mozilla.test" and that that is equivalent to the display of the newsgroup name now in the folder properties dialog. But "copy folder location" copied the URL for the newsgroup on the server, e.g. "news://news.mozilla.org:119/mozilla.test" and that functionality is now nowhere to be found.

Adjusting summary for what I'm about to attach a patch for.

I guess I see valid usage for the url for imap, news and movemail. I don't for pop and for RSS feed folders it's even confusing. Since bug 369393 it's now only shown in the IMAP sharing tab. This patch makes the folder URL show for IMAP, news and movemail, moves it to the General Information tab.

Here is a screen shot of with the proposed fix in place. (Note folderProps.xul is shared code so this is both tb and sm)

This is WAY less usable than the context menu item. It's way more clicks and keystrokes. The old way was: - right click on folder name - click on "copy folder location". Done! The new way is: - right click on folder name - click Properties (wait for new dialog) - highlight folder URL - type ctrl-C (copy data to clipboard) - close dialog Lots more clicking and dragging.

(In reply to comment #9) > Adjusting summary for what I'm about to attach a patch for. To Magnus Melin: Is there any plan to add field for "file path" (intial request of this bug) in addition to Location: field(URI)? Even though Account Settings/Server Settings/Local directory: points to directory where mail folder files/directory are kept, many many users asked/are asking "where is my mail data file?" repeatedly in forums and BBS'es. And, for general MS Win users, mailbox: URL is very different one from real file path, even if reading "/" as "\" is sufficient. This is the reason why I requested file path in property at Bugzilla Japan(then Koike-san, bug opner of this bug, opened this bug).

(In reply to comment #10) > I don't for pop and for RSS feed folders it's even confusing. To Magnus Melin: Does it mean you will never implement functionality for POP3 and RSS feeds? Or it is applicable to first proposal of your patch only?

WADA: yeah this bug got a bit hijacked... I don't plan on to add anything else in this bug. Feel free to file needed followup RFEs after this is closed. As you point out, Account Settings/Server Settings/Local directory already show you where the mails are, without the actual folder of course, but that parts is usually not hard to figure out.

(In reply to comment #15) > I don't plan on to add anything else in this bug. Is it applicable to property of POP3 folder and RSS feeds? If yes, please backout "remove 'Copy Folder Location' part" ASAP. Problem determination becomes very very hard(nearly imposiible for general users) when problem such as Bug 396149, if you will never implement property information(mailbox: URL) for POP3 mail folder even though you remove "Copy Folder Location".

Comment on attachment 281087 [details] [diff] [review] proposed fix I do quite like the dialog now, just >Index: mailnews/base/resources/content/folderProps.xul >=================================================================== >+ <hbox id="locationBox" align="center" hidable="true" hidefor="pop3,rss,none"> the entire hidefor still makes no sense for me. This is a property dialog for folders and it surely should contain a specific information for _all_ types of folders (where it exists, which is the case here). On unixoid platforms, mailbox: uris translate almost directly into native paths and even under Windows you can use the contained path to open the file in a Mozilla browser... Minussing just for that.

CC-ing to David. David, please backout "remove Copy folder Location" part of bug 369393 ASAP. I believe "removal of Copy folder Location" shouldn't be executed until completion of whole enhancements of this bug, even if removal is really required(see Bug 394578 for buttle on it).

Ok, showing for all types.

Comment on attachment 282011 [details] [diff] [review] proposed additional fix, v2 Many thanks!

Fix had bitrotted.

Checking in mail/base/content/mailContextMenus.js; /cvsroot/mozilla/mail/base/content/mailContextMenus.js,v <-- mailContextMenus.js new revision: 1.27; previous revision: 1.26 done Checking in mailnews/base/resources/content/folderProps.xul; /cvsroot/mozilla/mailnews/base/resources/content/folderProps.xul,v <-- folderProps.xul new revision: 1.29; previous revision: 1.28 done Checking in mailnews/base/resources/content/mailContextMenus.js; /cvsroot/mozilla/mailnews/base/resources/content/mailContextMenus.js,v <-- mailContextMenus.js new revision: 1.64; previous revision: 1.63 done ->FIXED

I've opened Bug 398117 for problem in display of mailbox: URL when mail folder name contains Japanese character. That is same problem as one I mentioned on "Copy Folder Location" in my Comment #4.