User-Agent: Opera/9.80 (Windows NT 5.1; U; en) Presto/2.2.15 Version/10.10 Build Identifier: 3.0 Beta 4 This is a big problem for users with a lot of folders and sub-folders. They can't to determine the right folder of search message because Search doesn't show full location in "Location" column. And when you try to click "Open Message Folder" button then it only opens new window without jumping to folder. Reproducible: Always

Dayslypper, Need more detail.. What do you mean by *full* location? Do you mean the folder name?, or the folder hierarchy? Can you give an example. And are you speaking of Edit>Find>"Search Messages" (ctrl+shift+F) or the new "Search all messages" in the tool bar? There is a related item for "Search Messages" - the location column doesn't persist. I'm not finding a Thunderbird bug for in search component which is surprising, because it's bothered me for a long time. I must be thinking of Seamonkey Bug 77940 Search UI: Location column doesn't preserve shown/hidden state. Should that be a core bug? (xref fixed Bug 374551 - Location column visibility is not persisted in saved searches, which I think is fixed - bug 497272) Dayslypper, Open Message Folder" item is an existing bug and easy find. search on Open Message Folder search Needless to say, it would be very cool to have these fixed, as they hamper the functionality afforded by all the various search tools.

queries: location related - https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=anywordssubstr&short_desc=location+&long_desc_type=allwordssubstr&long_desc=location&product=MailNews+Core&product=Thunderbird&resolution=FIXED&resolution=---&bug_severity=major&bug_severity=normal&bug_severity=minor&chfieldto=Now&field0-0-0=short_desc&type0-0-0=nowordssubstr&value0-0-0=book+bar+address&field0-1-0=short_desc&type0-1-0=substring&value0-1-0=saved&field1-0-0=short_desc&type1-0-0=substring&value1-0-0=search+&field1-0-1=component&type1-0-1=substring&value1-0-1=search broader - https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=anywordssubstr&short_desc=location+folder&long_desc_type=anywordssubstr&long_desc=location+hierarchy+account+parent&product=MailNews+Core&product=Thunderbird&resolution=---&bug_severity=normal&bug_severity=minor&bug_severity=enhancement&chfieldto=Now&field0-0-0=short_desc&type0-0-0=nowordssubstr&value0-0-0=book+bar+total+unread+address+select+stop+notif++news+counts&field1-0-0=short_desc&type1-0-0=substring&value1-0-0=search+&field1-0-1=component&type1-0-1=substring&value1-0-1=search

I mean folder hierarchy (folder tree). I mean "Search Messages" (ctrl+shift+F) or right click to any folder. I tried to search before but probably bad keywords. Sorry.

(In reply to comment #3) > I mean folder hierarchy (folder tree). Dayslypper, I don't think there is a bug for this. Please modify this bug so that it only addresses this issue. > I mean "Search Messages" (ctrl+shift+F) or right click to any folder. xref bug 524821 regression folder pane changes to smart folders if Open in Folder used from Search Messages with open messages in new window preference

"Open Message Folder" was really already mentioned in dofferent place. So I change this issue to feature request to display full e-mail path in "Location" column during "Search Messages".

(In reply to comment #1) > Needless to say, it would be very cool to have these fixed, as they hamper the > functionality afforded by all the various search tools. Agree with Wayne, "have a column that shows full path" (this bug) and "open containing folder" (currently only available from "Search Messages" dialogue) would be very cool improvements for any type of search result. -> confirming UI Considerations - some users will still need Location and Account columns as we provide them now, i.e. a column that shows only folder name (without path), and another one for account name (without folder details). - other users need a column that shows the full path (and with the arrival of gloda full text search, this has become much more important as the default search scope is now global) - uiwanted: supposing that we can agree on 1-3, how do we want to label the 3 columns so that they are easy to understand and tell apart? UI Proposal 1) /in addition/ to the functionality of existing Location and Account columns, 2) implement column that shows the full path, 3) including account and folder hierarchy (user@asdf.com/Inbox/subfolder/...) 4) Label colums as follows: a) Account-only column: Account (no change) b) Folder-only column: Folder c) Full-Path column: Location (?) a) is obvious, I'm not so sure about b) and c). Alternatives for c) might be "Full Path" "Folder Path" (more similar to Folder) "Folder (Full Path)" (bit clumsy, but clear) "Path" BTW, Firefox has had hundreds of requests over time to implement a "bookmark path" column into various bookmark search results, especially in the Library. We should be better, and not let users wait several years for such obvious and basic features. We also need a new bug for "Open in folder" aka "Open containing folder" to be available from any search results contextual menus (although the pending addition of "Show msg in conversation" will go a long way in that direction).

"Location Details" might be another alternative, would also work with current "Location" for folder-only column. Actually, b) "Folder" and c) "Folder path" would be my preference, as they are simple, similar, and yet you can immediately tell the difference. Also, we have "New folder" and "New Subfolder", "Favourite Folder", "Mark folder read" - so I can't see any reason to use "Location" where we really mean "Folder". Am I missing something? Does "Location" column ever show anything else than a folder?

These are all great suggestions, but just to be clear, even if it tells you the hierarchy, I find it really hard to find certain folders b/c the vertical line that tracks/follows the folder is sooooo long, I can't follow it when I scroll past the "Local Folders" so it's out of my eye sight. So if it could tell us the path & also jump to the folder that would be best. Thanks Michelle

So, is "Open message folder" (i.e., "Open folder containing this message") part of this bug?

No, "open containing folder" is not part of this bug, and the only related one I could find is Bug 509422 - [faceted search] need method to open found message in the containing folder location in which it resides (currently unconfirmed, I wonder why). That bug is probably about the *first* results of *faceted search* only, so I suppose my comment 6 still applies: > We also need a new bug for "Open in folder" aka "Open containing folder" to > be available from *any* search results contextual menus (although the pending > addition of "Show msg in conversation" will go a long way in that direction). dayslypper, comment 5, you say: > "Open Message Folder" was really already mentioned in dofferent place. Could you tell us about the bug where you found that?

I am wondering if comment 6 is not overly complex. would it not be sufficient for most people to display the full path of a message on mouseover of the existing Location column? Or are there use cases for enough people that more column types are really needed, and if so, please describe the use case?

So long as I can find where the folder exists, that's all that matters to me. Right now I use quick folder move & quick filer, 2 VERY great add-ons. I can see the folder exists, I just have no idea where it is in the tree of NUMEROUS folders, & so I don't know if I should file the mail in there, or another similar folder. I can't go check the contents of the folder b/c again, I can't find it. HTH Michelle P.S. Thomas, how are you doing? I e-mailed you on the 3rd, did you receive my e-mail : )

(In reply to comment #12) > I am wondering if comment 6 is not overly complex. I am failing to see the complexity, but it may not be well expressed. > would it not be sufficient for most people to display the full path of a > message on mouseover of the existing Location column? Clearly: NO. > Or are there use cases for enough people that more column types are really > needed, and if so, please describe the use case? Wayne, comment 6 asks to add exactly *one* new column type - "full path" (as a solution for this bug) e.g. user@asdf.com/Inbox/subfolder/... while retaining the two existing columns - account (e.g. "user@asdf.com") - location (= folder name without path, e.g. "subfolder") The use cases are plenty for people who have more than one folder of the same folder name in different accounts, in different subfolders, saved searches etc. Users want to visualize, from tabular search results, how many and which of these results are in which folder. They want to sort according to that folder, in a way that is immediately visible (instead of guess-working with the mouse to hover over lots of items till you happen to find the difference). After sorting, they may want to act only on a certain subset of results, distinguished only by the full folder path, and *not* by the folder's name. It's really straightforward and very obvious, and not at all complex to implement.

Please consider this use case scenario: We have a "Suppliers" folder (among many others, in order to organize our mail better). In this folder we have separate subfolders for each of our various suppliers. Each specific supplier subfolder has other various subsequent subfolders ("orders", "offers", "invoices" etc). We have created several saved searches folders in order to limit the displayed mails by date/age. When we look in the "Today & Yesterday" search folder for example, there are many emails that display "orders" at their "Location" column. This doesn't tell us though to which specific supplier folder this "orders" subfolder resides. Sometimes it is easy to guess it simply by looking at the "Correspondent" column, but that isn't always reliable -for one because the correspondent could be us-. So two possible solutions here would be: 1. Provide a full path to the subfolder as a column. 2. Provide a context menu entry to "jump" to the containing folder (perhaps a keyboard shortcut too). The extra "Full path" column would be great, but it might get really long and force people to scroll horizontally a lot (even those in large wide-screen monitors). To avoid this, we could implement the full path feature as a hover-over tooltip when people set their mouse over the current "Location" column. That on the other hand would not allow people to sort mail by actual full path nor even be able to print this information. The "Open containing folder" menu entry seems more appropriate to my situation and perhaps it should be made to open in a new tab by default so that people don't loose their current search display. QUESTIONS: - From what I understand this issue here is about implementing the first solution so that people can simply have a way to know where the actual mail is located. They will be able to navigate to the containing folder in a second step if they want ("manually", by going through the folder tree I guess). Right? - Is Bug 509422 about implementing the second solution ("Open containing folder" menu entry)? If so, why is it still marked as "UNCONFIRMED" and why its title is set to suggest that it should only be implemented in the faceted search?

I just wish they'd implement this already. A lot of people want this. I even asked on the forum if there was an add-on for this problem & it seems there's one for Fx bookmarks, but not for TB. : ( Michelle

(In reply to klonos from comment #15) > Please consider this use case scenario: [snip] Klonos, thank you for providing this excellent and detailed use case scenario. > So two possible solutions here would be: > 1. Provide a full path to the subfolder as a column. > 2. Provide a context menu entry to "jump" to the containing folder (perhaps > a keyboard shortcut too). Both is needed! > The extra "Full path" column would be great, but it might get really long > and force people to scroll horizontally a lot (even those in large > wide-screen monitors). Depends on implementation, columns are resizable, and we might try truncating the initial part of the path rather than the end. > To avoid this, we could implement the full path > feature as a hover-over tooltip when people set their mouse over the current > "Location" column. The tooltip is needed (perhaps for /both/ the current "Location" alias "Folder" column AND definitely for the "Full Folder Path" column requested by this bug. > That [Full path tooltip on current Folder-only column] on the other hand would > not allow people to sort mail by actual full path nor even be able to print > this information. Exactly. Therefore this bug. Not only for sorting, but also for viewing the full path without having to hover over each and every message. > The "Open containing folder" menu entry seems more appropriate to my > situation and perhaps it should be made to open in a new tab by default so > that people don't loose their current search display. "Open containing folder" /in a new tab/: That's something tricky which I haven't thought about yet... > QUESTIONS: > - From what I understand this issue here is about implementing the first > solution so that people can simply have a way to know where the actual mail > is located. They will be able to navigate to the containing folder in a > second step if they want ("manually", by going through the folder tree I > guess). Right? Correct. > - Is Bug 509422 about implementing the second solution ("Open containing > folder" menu entry)? If so, why is it still marked as "UNCONFIRMED" and why > its title is set to suggest that it should only be implemented in the > faceted search? Good question! ;) As you rightly point out, bug 509422 doesn't cover all search types. Furthermore, while covering a number of good ideas, bug 509422 comment 0 was not very structured and clear. I think that's why we hesitated to confirm. The answer: I filed a new bug to address this issue in a more systematical manner: Bug 686851 - Implement "Open containing folder" contextual action for messages in search results (faceted search, open as list, search messages dialogue, saved searches) [Show found message in folder location] That bug delivers the main idea and certainly needs some followup bugs to deal with and implement the details. Thank you, Klonos, for asking the right questions! :))

Though perhaps not technically dependent on each other, Bug 686851 and this bug are certainly related. This bug might be the logical first step and slightly easier to implement. Thus, just to track the relationship, marking Bug 686851 as dependent.

This RFE is really about /adding/ a full folder path column, and probably adding a tooltip with the full path on current "Location" (= "Folder name") column, but NOT about /replacing/ the current folder-name ("Location") column with a full path column -> adjusting summary accordingly. Depending on each user's system of folders and use patterns, short folder-name column ("Location", without full path) is still an important use case.

I'm sure there are more GS reports, but I'm running out of time and things aren't easy to find on GS.

No comments on this for two years? That's a bummer - it's driving me crazy. I've taken to segmenting my Trash and Sent folders by year, the same way the Archives folder is, to deal with multiple 100,000 message counts. Using global search is often useless for finding the original message, as "2005" could refer to several different folders. Yes, the obvious workaround is to make sure all folder names are unique. But some of us have historical folder hierarchies that go back a decade or more, and changing names at this point would break backup systems.

The interface really needs a path indicator somewhere. Neither in search nor in message view can the user tell the path to the folder where a message is located.

I adhere to this. People having a complex tree structure of folders for managing their e-mails really need this feature to pin-point the proper message. What I have to do now when looking for a message after a global search is tagging it as "unread" and then manually look for that unread message which is time consuming and annoying.