686851 - Implement "Open containing folder" contextual action for messages in search results, own tab, or standalone win (faceted search, open in conversation, open as list, advanced search messages dialogue, saved searches) [Show found message in folder location]

Status: RESOLVED FIXED

(Thunderbird :: Search, enhancement)

Description

[Thomas D. (:thomas8)]

Search results of any type would be a lot more useful if messages found had a contextual action to "Open containing folder", to see the message in its original context/location. This is different from "Open in conversation", which excludes neighbouring / related messages that reside in the same folder. Use cases are obvious, especially for, but not limited to, users who arrange / filter their messages into folders (a nice business use case example in Bug 522768, Comment 15).

STR

1a) Global search > faceted search results, or
1b) Global search > ... > Open as list (message list), or
1c) Search messages dialogue > search results (message list), or
1d) Saved search (message list)
2) try to view a found message in the context of its containing folder location

Actual result

- for 1a/b/d (Global search variants, Saved search), TB does not provide any UI as a direct link to view the message in its containing folder; user has to go to the containing folder manually; worse, we don't even /indicate/ the full folder path anywhere in the search results (Bug 522768)
- for 1c (search messages dialogue), we have a button: Open in folder (which works as expected), but no context menu

Expected result

- for 1a/b/d (Global search variants, Saved search), TB should provide a direct link UI to view a found message in its containing folder (most likely, a context menu action, e.g. "Show in containing folder")
- for 1c (search messages dialogue), we should add a respective context menu action (which requires adding the context menu first, may need a new bug)

Implementation Details

- In general, the easiest implementation is to provide the respective link as an additional action from the context menus (e.g. "Show in containing folder");
for 1a (Faceted search results) and 1c (Search messages results) this requires implementing / adding the context menu first
- This bug might be morphed into a meta/tracker bug, and implementation details / variants for each search results type could be handled in followup bugs

OT:
- FF bookmarks suffer from the same problem, and lots of users have requested respective improvements for ages
- I guess most OS handle this correctly, on Windows 7, there's "Open file location" from the context menu of found files
- Another good example, Mozilla's download managers (Ctrl+J in FF/TB) have "Open containing folder" in the context menu

Comment 1

[Thomas D. (:thomas8)]

Of course (as mentioned in Bug 509422, Comment 0, and Bug 509422, Comment 4) we would also want to add "Open containing folder" or similar to the de-facto-contextual menu of "Other Actions" button on stand-alone message reader tabs/windows, which probably needs another dependent bug.

Comment 2

[Thomas D. (:thomas8)]

This bug is the logical extension and a necessary supplement of

Bug 522768 - Search Results: Missing full path in "Location" column (Faceted Search: Open as List, Saved Searches, Search Messages; Main 3-pane Window).

In that general sense (not strictly speaking), this bug relates to and "depends on" bug 522768.

Comment 4

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #0)

> Implementation Details [...]
> for 1a (Faceted search results) and 1c (Search messages results) this
> requires implementing / adding the context menu first

for 1c: Bug 302609 - right-click on message in search messages (advanced) results should show contextual menu

Comment 5

[Thomas D. (:thomas8)]

From the fruitful ashes of Bug 540315, I discovered another type of "search result" to which this bug also applies: "Open in conversation". There are many ways to get there, and not all of them start out in a folder (e.g. you get "Open in conversation" when you click on a faceted global search result item). So we need a way to view the containing folder from there, because "Open in conversation" doesn't work for many real-life conversations which technically don't link up correctly, so an unspecified number of related messages may not show up. But they are all in the containing folder...

By extension of this idea and this bug (inspired by close reading of bug 540315), we would probably also want this:

* Add an "Open containing folder" menu item on the dropdown menu of "Other Actions..." button on the message reader toolbar for "Open in conversation" or "Open as list" views (obviously, do not show that menu item for the main 3-pane message reader because we are already in the folder).

* Add an optional optional "Open folder" button available through customization of the message reader toolbar (conversation's view type only, not 3-pane)

Comment 6

[Thomas D. (:thomas8)]

As pointed out by similar bug 806080, the same problem addressed in this bug also occurs for messages opened in their own tab, or in the standalone msg window: While you have the msg right in front of you, there is no way to get back to the containing folder to see the msg in its original context, which is not necessarily limited to the context of the conversation/thread.

Comment 7

[Thomas D. (:thomas8)]

Richard (as a menu expert), for most parts, fixing this high-value bug should be straightforward: Add existing "Open in Folder" command (from advanced search dialogue) to the respective context menus. Excellent cost-benefit ratio (UX-Papercut). Could you try this (even partially)?

Comment 8

[Richard Marti (:Paenglab)]

I'm sorry, I'm no JS expert and this bug needs one. This is not only a copy-n-paste of the menu, it's also a hiding and showing this entry on the right context. My main skills are on CSS and the AppMenu was only a copy-n-paste with some low skill JS additions.

Comment 10

[Thomas D. (:thomas8)]

Can anyone confirm the ux-papercut status of this bug?

I.e., would you agree that locating found (or viewed) messages in their original folder context is useful and comes with an excellent cost-benefit ratio wrt implementation?

Any takers, even for partial fix like one type of search only?

Comment 11

[Wayne Mery (:wsmwk)]

I've not done anything on this front, and probably won't for at least another week or two. I'll keep in my queue to look at, but if someone else works on it first, that's fine with me.

Comment 12

[Thomas D. (:thomas8)]

(In reply to Wayne Mery (:wsmwk) from comment #11)
> I've not done anything on this front, and probably won't for at least
> another week or two. I'll keep in my queue to look at, but if someone else
> works on it first, that's fine with me.

Wayne, were you indicating that you might be able to fix (parts of) this bug?
I think it's great value for probably quite little effort of implementation.
It's one of those things that I'd just expect to work in any decent application: Search results must point back to their original context. TB advanced search has it, FF download manager has it, Windows Explorer file search has it, Google Image Search has it, need I say more?

Would you confirm the UX-papercut status of this bug by removing the question mark in the Whiteboard?

Comment 13

[Wayne Mery (:wsmwk)]

Hi Thomas. My comment was only relative to papercut status. I'm not in a position to provide a fix. I suggest this is not a papercut:
* bug has low vote count, only two votes
* IME it is not a frequent request in support forums
* It is isn't listed at https://wiki.mozilla.org/Thunderbird/Papercuts

Comment 14

[mitch deoudes]

One reason for the low number of votes could be the number of bugs asking for similar functionality.  Here are a few of them:  

https://bugzilla.mozilla.org/show_bug.cgi?id=522768
https://bugzilla.mozilla.org/show_bug.cgi?id=553600
https://bugzilla.mozilla.org/show_bug.cgi?id=522768
https://bugzilla.mozilla.org/show_bug.cgi?id=708563
https://bugzilla.mozilla.org/show_bug.cgi?id=591958
https://bugzilla.mozilla.org/show_bug.cgi?id=652432

There's probably a discussion to be had about how best to implement "search results point back to original context" functionality.  (Does it need to be a link / command - or is displaying it enough?)  But I don't think you could say that nobody wants it.

Comment 15

[mitch deoudes]

I should probably also point out that there may be people following some of these bugs who haven't voted for (or be aware of) all of them.

Comment 16

[Suyash Agarwal (:sshagarwal)]

Attachment: Patch v1

Possible fix.
Please let me know the cases left, bugs in the proposed behavior and do let me know if this is/isn't expected.

Thanks.

Comment 17

[Wayne Mery (:wsmwk)]

I'm sure this will be fixed in short order by sshagarwal, but I'm still writing the following to clarify about papercuts (not to be argumentative)

(In reply to mitch deoudes from comment #15)
> I should probably also point out that there may be people following some of
> these bugs who haven't voted for (or be aware of) all of them.

well, people who don't vote can't counted, nor assumed.

(In reply to mitch deoudes from comment #14)
> But I don't think you could say that nobody wants it.

I too would like to have this. And I'm quite sure I did not say nobody wants it or anything close to that. What I said is I don't think it meets the definition of a papercut. We have hundreds of average bugs which are annoying. But papercut includes the idea that it affects a percentage of the user population that exceeds that of the "average bug". This gives papercuts to greater focus - if the bug impacts *an order magnitude of users more* than the average annoying bug.  Indeed note that not all the bugs listed on https://wiki.mozilla.org/Thunderbird/Papercuts got even a second vote.

> One reason for the low number of votes could be the number of bugs asking
> for similar functionality.  Here are a few of them:  
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=522768
> https://bugzilla.mozilla.org/show_bug.cgi?id=553600
> https://bugzilla.mozilla.org/show_bug.cgi?id=522768
> https://bugzilla.mozilla.org/show_bug.cgi?id=708563
> https://bugzilla.mozilla.org/show_bug.cgi?id=591958
> https://bugzilla.mozilla.org/show_bug.cgi?id=652432
> 
> There's probably a discussion to be had about how best to implement "search
> results point back to original context" functionality.  (Does it need to be
> a link / command - or is displaying it enough?)  

Thanks for pointing these out.  point taken. Most are indeed variations of this issue. 

Note however in your list is bug 652432, dupe of bug 570787 which was recently fixed. It is not this bug.  And it is BTW an example of a papercut by my measure and by https://wiki.mozilla.org/Thunderbird/Papercuts  N.B. the bug's vote and cc count compared to this bug and all the others cited above. (not saying however that's the only way to measure "magnitude")

HTH

Comment 18

[mitch deoudes]

Thanks for the clarification...  I'm definitely not up on the terminology etc. w.r.t. the development and bug-tracking side of things.  Just weighing in as a user who's been tracking this issue, and didn't want to see it get buried.

Comment 19

[Thomas D. (:thomas8)]

Comment on attachment 8399472 [details] [diff] [review]
Patch v1

Review of attachment 8399472 [details] [diff] [review]:
-----------------------------------------------------------------

Suyash is once again my personal hero for improving TB and fixing with a single swift swipe what others have never dared nor tried before...
Users should be grateful forever (even those who are still unaware of the great potential of reverse/context search: find one, find them all (neighbouring messages related in time or content), plus potential context information provided by the folder, e.g. which project this msg was part of etc.).

From my reading of the patch (can't test) this looks as if it would fix almost all scenarios (probably except the context menu of a message shown in its own tab or standalone window, but we can easily leave those for bug 806080, which is where they came from anyway. Similarly, some toolbar buttons for this functionality can be done in their own bugs).

We'll want to check one edge case scenario where the folder pane is hidden, but unless this really fails, I think it's a nit that can be ignored.

::: mail/base/content/msgMail3PaneWindow.js
@@ +1215,5 @@
> +{
> +  if (!gFolderDisplay.selectedMessage)
> +    return;
> +
> +  MailUtils.displayMessageInFolderTab(gFolderDisplay.selectedMessage);

Nice! I understand this will search for an already open folder tab (rather than opening a new one), which is good imo.

::: mail/base/content/nsContextMenu.js
@@ +277,5 @@
>      this.showItem("mailContext-openConversation",
>                    this.numSelectedMessages == 1 && this.inThreadPane &&
>                    gConversationOpener.isSelectedMessageIndexed());
> +    this.showItem("mailContext-openContainingFolder",
> +                  !gFolderDisplay.folderPaneVisible &&

Pls try this:

- in main 3pane, hide the folder pane (view > layout > folder pane).
- right-click on a single selected msg in thread pane of same tab
- from context menu, click "Open message in containing folder" (what does it do? probably nothing?)

Ideally, "Open message in containing folder" shouldn't be shown in this case because we're already in folder view, but hiding the folder pane looks like a very rare edge case to me so unless this behaves oddly when clicked, I think it's fine to just ignore this or file a followup bug of type "trivial" for doing the cosmetics.

::: mail/locales/en-US/chrome/messenger/messenger.dtd
@@ +700,5 @@
>  <!ENTITY contextOpenNewTab.accesskey "T">
>  <!ENTITY contextOpenConversation.label "Open Message in Conversation">
>  <!ENTITY contextOpenConversation.accesskey "n">
> +<!ENTITY contextOpenContainingFolder.label "Open Message in Containing Folder">
> +<!ENTITY contextOpenContainingFolder.accesskey "g">

I think "g" is also the access key for "Tag" but it there is no other access key contained in the label which isn't already taken.
Having same access key for more than one menu item doesn't necessarily break functionality of access keys, pressing the letter toggles command selection, Enter executes selected command (although I'm not sure how that behaves for tag popup menu: when g is pressed twice to focus tag submenu, is submenu immediately active to take access keys like "1" for first tag?)

Otherwise, what about "n" as shared access key for the similar commands "Open in conversation" and "Open message in containing folder"? 1x n, Enter -> conversation. 2x n, Enter -> folder. Imho, that's even somewhat mnemonic: n for smaller context, nn for wider context.

Comment 20

[:aceman]

Comment on attachment 8399472 [details] [diff] [review]
Patch v1

Review of attachment 8399472 [details] [diff] [review]:
-----------------------------------------------------------------

I am not an expert on what this bug wants but the patch seems to work. It adds "Open message in Containing folder" context menu item when rightlicking a message shown in the threaded results of Gloda search.

::: mail/locales/en-US/chrome/messenger/messenger.dtd
@@ +700,5 @@
>  <!ENTITY contextOpenNewTab.accesskey "T">
>  <!ENTITY contextOpenConversation.label "Open Message in Conversation">
>  <!ENTITY contextOpenConversation.accesskey "n">
> +<!ENTITY contextOpenContainingFolder.label "Open Message in Containing Folder">
> +<!ENTITY contextOpenContainingFolder.accesskey "g">

Yeah, 'g' is already taken but it will be hard to find a free key in this menu.

Comment 21

[Suyash Agarwal (:sshagarwal)]

Comment on attachment 8399472 [details] [diff] [review]
Patch v1

(In reply to Thomas D. from comment #19)
> Pls try this:
> 
> - in main 3pane, hide the folder pane (view > layout > folder pane).
> - right-click on a single selected msg in thread pane of same tab
> - from context menu, click "Open message in containing folder" (what does it
> do? probably nothing?)

Ya, I see this :(
> Ideally, "Open message in containing folder" shouldn't be shown in this case
> because we're already in folder view, but hiding the folder pane looks like
> a very rare edge case to me so unless this behaves oddly when clicked, I
> think it's fine to just ignore this or file a followup bug of type "trivial"
> for doing the cosmetics.

Okay, thanks :) 
Requesting reviews!

Comment 22

[Thomas D. (:thomas8)]

Note for followup bugs:

When faceted search results (the snippets) eventually get a context menu (which they definitely should!), we should remember to include "Open message in containing folder" there, too.

Same for advanced search (Ctrl+Shift+F), unfortunately there's no context menu yet on found messages list (existing bug), although I imagine that should be quite simple to add because there's should be no structural difference to the other message lists so it's just a question of calling commands in the right scope, if anything.

Comment 23

[Richard Marti (:Paenglab)]

Comment on attachment 8399472 [details] [diff] [review]
Patch v1

Review of attachment 8399472 [details] [diff] [review]:
-----------------------------------------------------------------

ui-r- because of the "g" shortcut. I'm not very happy with sharing a key but if we are using "n" it would be the lesser evil as it shares entries with the similar meaning. "g" is also used for Tag and has nothing to do with opening of messages.

I checked other letters but all from this sentence are already used.

Comment 24

[Suyash Agarwal (:sshagarwal)]

(In reply to Richard Marti (:Paenglab) from comment #23)
> Comment on attachment 8399472 [details] [diff] [review]
> Patch v1
> ui-r- because of the "g" shortcut. I'm not very happy with sharing a key but
> if we are using "n" it would be the lesser evil as it shares entries with
> the similar meaning. "g" is also used for Tag and has nothing to do with
> opening of messages.
So, do I have ui-r+ with "g" changed to "n"? :)

Comment 25

[Richard Marti (:Paenglab)]

Yep, if you don't find a other (better) solution.

Comment 26

[Magnus Melin [:mkmelin]]

Comment on attachment 8399472 [details] [diff] [review]
Patch v1

Review of attachment 8399472 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM. r=mkmelin
I wonder why opening in the 3pane isn't the default though? Maybe there's a reason, I don't really use gloda so I can't tell.

Comment 27

[Suyash Agarwal (:sshagarwal)]

Attachment: Patch v1.1

Carrying over review from mkmelin Comment #26 , ui-r from Paenglab Comment #25.

Thanks.

Comment 28

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/comm-central/rev/4bfb2e080bcd

Comment 29

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Magnus Melin from comment #26)
> I wonder why opening in the 3pane isn't the default though? Maybe there's a
> reason, I don't really use gloda so I can't tell.

If you're asking why the faceted search UI: Performance reasons; showing messages in the 3-pane requires the folders to be open (aka .msf files loaded); since a gloda search can potentially find a message in every folder, this could have bad very bad performance and resource ramifications.  (Well, more than could, did.  We tried that first.)  Having a fake thread-pane backed by the gloda objects had performance problems because the tree-view is horrible about caching and gloda wouldn't necessarily have all the required data.

If you're asking why viewing the gloda search results in a tab hides the folder pane, it was because then synthetic folder nodes would need to be created and that would have resulted in feature creep.  (It would be neat to have a tree node that was 'recent searches' or something like that, of course.)

Comment 30

[Magnus Melin [:mkmelin]]

I was wondering about when you search for something, get a listing and click to open the mail, why it doesn't open in the 3pane. I'm not sure if that was the second part of your answer.
(With this patch, you can now in that non-3pane view, open in the 3pane from the context menu.)

Comment 31

[Andrew Sutherland [:asuth] (he/him)]

Yes, second part of the answer.  Clicking on the message displays the message's entire conversation which is inherently cross-folder and so has no guaranteed corresponding folder location.  (It is possible that all of the messages exist in some real or virtual Thunderbird folder, but that would require additional logic to determine and would then imply some type of quick-filter that gloda would have to figure out how to formulate in order to restrict down to the messages in the conversation.)

This new functionality (which is awesome!) appears to just display a single message.  Since a single header has an explicit location, there's no ambiguity and it's easy to display its (real, non-virtual) folder location which of course has a real folder in the folder pane.

Comment 32

[Thomas D. (:thomas8)]

Incomplete feedback on current implementation:

- No context menu yet for messages in "Saved Search" folders (because we only show context menu when there's no folder pane, which might be the wrong check; needs new bug).
- When you first open a saved search which happens to have the target msg (and/or target folder?) in the result set, target msg will be activated in that saved search folder view rather than the original source folder (that's a bug in the implementation of this bug).

Comment 33

[Thomas D. (:thomas8)]

This is a small but powerful feature addition for TB31.

Comment 34

[rsx11m]

Did you file those follow-up bugs?

Comment 35

[Thomas D. (:thomas8)]

No, and I wouldn't mind if somebody else did.