180546 - Folder properties dialog should show folder URI (where usable)

Status: RESOLVED FIXED

(SeaMonkey :: MailNews: Message Display, enhancement)

Description

[Koike Kazuhiko]

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.

Comment 1

[WADA:World Anti-bad-Duping Agency]

Same enhancement request for Thunderbird is Bug 369393.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

> 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.

Comment 3

[WADA:World Anti-bad-Duping Agency]

(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...

Comment 4

[WADA:World Anti-bad-Duping Agency]

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)  

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

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?

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

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

Comment 7

[WADA:World Anti-bad-Duping Agency]

(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.

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 9

[Magnus Melin [:mkmelin]]

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

Comment 10

[Magnus Melin [:mkmelin]]

Attachment: proposed fix

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.

Comment 11

[Magnus Melin [:mkmelin]]

Attachment: screenshot with the proposed fix in place

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)

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 13

[WADA:World Anti-bad-Duping Agency]

(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).

Comment 14

[WADA:World Anti-bad-Duping Agency]

(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? 

Comment 15

[Magnus Melin [:mkmelin]]

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.

Comment 16

[WADA:World Anti-bad-Duping Agency]

(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 17

[Karsten Düsterloh]

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.

Comment 18

[WADA:World Anti-bad-Duping Agency]

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).

Comment 19

[Magnus Melin [:mkmelin]]

Attachment: proposed additional fix, v2

Ok, showing for all types.

Comment 20

[Karsten Düsterloh]

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

Many thanks!

Comment 21

[Magnus Melin [:mkmelin]]

Attachment: proposed fix, v2 (updated for checkin)

Fix had bitrotted.

Comment 22

[Magnus Melin [:mkmelin]]

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

Comment 23

[WADA:World Anti-bad-Duping Agency]

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.