I'm not sure if there is any kind of regular usage for the Copy Folder Location feature. I personally have no need for it -- hardly anything support mailbox or imap URLs. The news: URL might have some use, but it's limited. Even if there's a usage I'm unfamiliar with, I daresay it's not one that's known or understood by the Thunderbird target user. In order to clean up the context menus on the folders a bit, I suggest removing the menu item, and replacing the feature by adding a copy-able text field to the Properties dialog for each folder.

Seems it was added for use with shared folders, in bug 112105. Given it's use case, maybe the url field should be under the Sharing tab.

Same enhancement request as App Suite Bug 180546.

Here is a screenshot of what it could look like under the sharing tab.

Removes the "Copy Folder Location" from the context menu, and adds it under the Sharing tab of the folder properties as shown in the screenshot of attachment 274364 [details]. (The field is disabled, though my theme doesn't seem to support showing it as such:( )

Err, meant readonly. As for bug 180546, I'm not sure this helps much for that...

Comment on attachment 274367 [details] [diff] [review] proposed fix awesome!

Checking in mail/base/content/mailContextMenus.js; /cvsroot/mozilla/mail/base/content/mailContextMenus.js,v <-- mailContextMenus.js new revision: 1.25; previous revision: 1.24 done Checking in mail/base/content/mailWindowOverlay.xul; /cvsroot/mozilla/mail/base/content/mailWindowOverlay.xul,v <-- mailWindowOverlay.xul new revision: 1.216; previous revision: 1.215 done Checking in mail/locales/en-US/chrome/messenger/folderProps.dtd; /cvsroot/mozilla/mail/locales/en-US/chrome/messenger/folderProps.dtd,v <-- folderProps.dtd new revision: 1.7; previous revision: 1.6 done Checking in mail/locales/en-US/chrome/messenger/messenger.dtd; /cvsroot/mozilla/mail/locales/en-US/chrome/messenger/messenger.dtd,v <-- messenger.dtd new revision: 1.65; previous revision: 1.64 done Checking in mailnews/base/resources/content/folderProps.js; /cvsroot/mozilla/mailnews/base/resources/content/folderProps.js,v <-- folderProps.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.27; previous revision: 1.26 done Checking in mailnews/base/resources/content/mailContextMenus.js; /cvsroot/mozilla/mailnews/base/resources/content/mailContextMenus.js,v <-- mailContextMenus.js new revision: 1.62; previous revision: 1.61 done Checking in mailnews/base/resources/content/mailWindowOverlay.xul; /cvsroot/mozilla/mailnews/base/resources/content/mailWindowOverlay.xul,v <-- mailWindowOverlay.xul new revision: 1.333; previous revision: 1.332 done Checking in suite/locales/en-US/chrome/mailnews/folderProps.dtd; /cvsroot/mozilla/suite/locales/en-US/chrome/mailnews/folderProps.dtd,v <-- folderProps.dtd new revision: 1.16; previous revision: 1.15 done Checking in suite/locales/en-US/chrome/mailnews/messenger.dtd; /cvsroot/mozilla/suite/locales/en-US/chrome/mailnews/messenger.dtd,v <-- messenger.dtd new revision: 1.217; previous revision: 1.216 done

Magnus: It's no friendly behaviour to change SeaMonkey UI without any reviews of any SM person. :-(

This patch affects POP3 users, as there is no sharing tab in folder properties, so no way to see the folder location. (In reply to comment #5) > As for bug 180546, I'm not sure this helps much for that... Adding a field with the folder location below name in properties' General Information tab would fix that bug and give POP3 users the possibility to see the location of the selected folder.

Magnus: I quite like dropping the menu item, this functionality is too obscure to be in such a prominent place. But showing this info for IMAP only now is not okay. For SM, I'd like to see the Location box on the "General Information" tab, below the Name box, for all kinds of folders. (This would fix bug 180546, too, so you might want to take that. ;-).

Sorry about that Karsten, I'll keep it in mind next time! We can take it in bug 180546... (The url only reveals the real file name for pop, it's not the same for imap.)

I actually tried to put it under name at first, but that's some scary information to show to users who would nearly never care. Scott, speak up if you would like it in General Information (under Name) too.

Doh, folderProps.xul is shared code, so changing it for SeaMonkey only would be hacky:( How about maybe leaving it as it is, and going for bug 158023 if I can figure it out?

I'm not convinced that these two li'l files are worth sharing, we probably should disentangle such minor UI parts - I filed bug 390262 on that. We could "get away" with ifdefing the relevant parts here, but that'd be truly hacky indeed. The thing is just that the path information is not necessarily "scary" for the usual SM audience and it's not shown prominently enough to "scare" more "basic" users - you rarely open that dialog anyway. Furthermore, the path information is useful for non-IMAP (like pop3 or movemail) as well, especially on unixoid systems where the path almost directly relates to a real path on disk. So if TB doesn't like to have that information on the general page, it's probably best to fork this small dialog.

Re-opening. Test result with Tb trunk 2007/7/31 build and 2007/8/01 build(MS Win-XP). 1. "Show file locaition" doesn't exist in context menu of local mail folder 2. No file name related information in property of local mail folder Apparently change for 'Remove "Copy Folder Location" from menu' part only. No change for "put the data in Properties dialog" part. Why FIXED even though this status? "put the data in Properties dialog" part is handled by other bug? If so, why no pointer to the bug for it?

WADA: I never said this would fix bug 180546. What was checked in removed it from the context menu, and put the info under the Sharing tab (see the screenshot) in the folder properties. Indeed, that info is not accessible for non-imap folders now since they do not have the sharing tab. Didn't think anyone would care for that info other than for IMAP folder sharing (not counting debugging as a normal use activity).

(In reply to comment #16) > WADA: I never said this would fix bug 180546. Bug 180546 is for App Suite, and this bug is for Thunderbird, because UI is involved. And, although Bug 180546 refers to file name of local mail folders only, our expectation is common solution(enhancement) for local mail folders and IMAP mail folders and newsgroup, and common solution(enhancement) among all mailers of Mozilla family. Further, there are two kind of information related to a folder - (1) file path, (2) internal mail folder path(used in message filter etc.) when local mail folder. These are not required in daily use, but required when trouble shooting(not debugging). Magnus, should we open 1(remove "copy folder location") + 3(local folder, IMAP, news)x2(file path, internal URL)x2(Tb, App Suite) bugs separately?

Shouldn't be necessary. Fixing the file name stuff would be a side effect, depending on the implementation. And currently the other stuff is not fixable for one app only as the UI code for it is shared.

Damn! I use "Copy Folder Location" daily, or I did until it was removed! This is a regression, first class! We've got to stop taking away features because one or two people don't use them!

The stuff now in folder properties is NOT equivalent to "Copy Folder Location". I need a way to get a string like "news://news.mozilla.org/mozilla.dev.apps.thunderbird" I used to be able to do it with two clicks and two mouse movements. Now, it's not available at all.

(In reply to comment #19) > Damn! I use "Copy Folder Location" daily, or I did until it was removed! > This is a regression, first class! If you are talking about Seamonkey's trunk, see bug 180546. We did't/don't request removal of "Copy Folder Location" in see bug 180546. We requested new "URI or file path in property" only for Seamonkey.

That fact that bug 180546 did not request the removal of "Copy Folder Location" from the menu is irrelevant to this regression. THIS bug (bug 369393) clearly DID request and DID remove it!

The patch for this bug evidently affected core code, common to TB and SM. In introduced a regression into SM. I think it is the duty of people who patch common code, for the purpose of changing one of the two products (TB or SM) to ensure that it does not cause regressions for the other product, by patching the other product if necessary, to avoid regressing that product.

Nelson, I was involved as you can see in comment #14. Let's take this into your new bug 394578.

Marking FIXED again... adjustments in bug 180546.