806080 - Implement "Open containing folder" (menu and/or button) in Message Browse Window (too)

Status: RESOLVED WORKSFORME

(Thunderbird :: Message Reader UI, enhancement)

Description

[André Pirard]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:15.0) Gecko/20100101 Firefox/15.0.1
Build ID: 20120907230839

Steps to reproduce:

Nothing, I swear.


Actual results:

The search window contains an "Open in Folder" button. Excellent.


Expected results:

If that button were in the e-mail View (Open) window (instead or in addition), that feature would be available for any message, whatever the way to reach it.
The user has most often opened his message before wanting to reach the folder.
That's the way Good Old Eudora does it: select e-mail and focus the selection.
Thanks.

Comment 1

[Thomas D. (:thomas8)]

Andre, pls make sure to include all the details of STR, Actual Result, and Expected result. As it stands, your bug is not easy to understand. But let's try:

STR

1a) open msg a in a tab
1b) open msg b in a standalone window
1c) from gobal search results, open as list, select a msg c
2) for any of these messages a/b/c which are right in front of you in their own container, try to get back at their *containing folder* to see the message in the context of the folder (not necessarily limited to the context of the conversation!)

for comparison:
3) find msg a/b/c using advanced search, select msg, then "Open in folder"

Actual result

2) for any of the messages a/b/c open in their own container:
- no way to get back to the containing folder of the message which is right in front of you
- need to remember (guess?) the containing folder and then find the message there manually
- no "Open in folder" aka "Open containing folder" button like in Advanced Search (Search Messages, Ctrl+Shift+F)

Expected result

2) whereever we show a message outside its folder context (in a tab, in a standalone window, in search results), there should be
- a contextual command "Open containing folder" (bug 686851)
- an optional "Open in Folder" button on the respective toolbar customization palette (Mail toolbar, message header toolbar), as we have it in Advanced Search Results (after step 3)

...so that users will be able to get back to the containing folder and see the message in the context of the folder (not necessarily limited to the context of the conversation!)

This bug is requesting a toolbar *button* and covers some situations so far not mentioned in search-centered bug 686851 which requests a *context menu*. The underlying idea is very much the same, and I support that 100%. Imho it's a major shortcoming which, if addressed, could make search results (and single messages in msg reader) a lot more useful. I'd recommend doing bug 686851 first.

Comment 2

[Thomas D. (:thomas8)]

OT: Fwiw, I was so annoyed about the same problem with M$ Word files currently open in Word ("right in front of you"), that I added a customized toolbar button "Open in Explorer" with a macro to show the currently open document highlighted in its parent folder in Windows explorer. It's interesting to note that old Works for DOS had all the file management commands in Works File menu, then they got outsourced to File Manager, but the direct link from the document to the file manager was never implemented.
In fact, I've also added "Rename document", "Delete document", and "Write-protect" buttons to my Word toolbar, and I use them regularly - very comfortable.

Comment 3

[André Pirard]

How can you say that my explanation is not easy to understand if you understood it so well? ;-)
It is just explained simpler so that one only needs to read it once.
The message browser window (standalone or tab if you prefer) should implement (menu and/or button) an "Open containing folder" to display the folder (containing the viewed message), preferably in foreground, with the message highlighted. Possibly implementable in other places related to a message.
With that view of the folder, the user can see the message in context and do a lot of things, for example, see the messages received before and after it, sort by name and delete or move thread ...
This is what the Search window does already in less clear terms and way with "Open file in folder". From Search, one could alternatively "Open file" and then "Open containing folder".

Comment 4

[Thomas D. (:thomas8)]

(In reply to André Pirard from comment #3)
> How can you say that my explanation is not easy to understand if you
> understood it so well? ;-)

I tried very hard and I have intuitions for useful ideas ;)
I can say that with the technical experience and inferential skills of more than 5 years of BMO triaging experience, and believe me, without a crystal-clear description, especially solid steps to reproduce, your idea will not get an inch of attention among thousands of bugs and RFE's. Even with perfect description, it's still hard to get attention and manpower.

Comment 0 fails to provide clear information about the scenario, the problem (actual results), and even the expected results (due to ambiguities in the terminology used), and requires a lot of guesswork and interpretation to understand:

Steps to reproduce (scenario) are entirely missing ("Nothing, I swear").

Actual Results does not describe the details of the problem which you are seeking to solve. Instead, it gives a description of the solution found elsewhere in the program using unclear terminology: "the search window" is an undefined entity because we have at least 4 different types of search:
- Global Search (Ctrl+K), with two different result flavors (faceted preview, open as list)
- Quick Filter (Ctrl+Shift+K)
- Advanced Search (Ctrl+Shift+F), that's the one you're talking about
- Saved Search Folders (Virtual Search Folders, saved from Advanced Search)

Expected Results is a conglomerate of a little bit of everything, again using unclear terminology:

"the e-mail View (Open) window" is an undefined entity because we have lots of different places and flavors where email messages can be "viewed".
The technical term for those instances is "Message Reader" (which is what those people who need to fix your bug can understand), and then you still have to tell them about place and flavor (standalone window, in a tab, in "Open as list" view of Global Search, etc.). 

> It is just explained simpler so that one only needs to read it once.

So no, I'm afraid it's the "simple" version of comment 0 which needs several readings to parse correctly (if at all possible) because it lacks format, detail and technical precision, whereas the seemingly more complex comment 1 will be easier to parse because it follows the prescribed format, provides detail and uses acknowledged technical terminology.