Closed Bug 546621 Opened 10 years ago Closed 3 years ago

'Show in conversation' feature is too hidden - add a "Conversation" toolbar button

Categories

(Thunderbird :: Message Reader UI, enhancement)

enhancement
Not set

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 51.0

People

(Reporter: mozbugzilla, Assigned: Paenglab)

References

(Depends on 1 open bug, Blocks 2 open bugs)

Details

Attachments

(4 files, 3 obsolete files)

Thunderbird 3's new Show In Conversation feature is fantastic.  However, it's too hard to discover.  The feature is buried under 'other actions' in the message view pane.  I've shown this feature to many users who already use Thunderbird 3 yet hadn't discovered it for themselves.  They've been really impressed with it, and many have said they wished they'd known it was there all along.  I would suggest that the UI to this could do with a re-work to make such a good feature more easily discoverable.

There are possibly two issues here.  The first being that the feature is hidden under 'other actions'.  Secondly, it's perhaps not that clear what 'show in conversation' actually means.
I would tend to agree with this, and if it's something that we could address without too much design work, I'd love to see it addressed in the short term.  clarkbw, how much work do you think this is likely to be to address this, and is now the right time?
Flags: wanted-thunderbird+
Not sure what the right solution would be here.  I agree it would be great to surface this feature more than it is now but I don't have a clear path to an easy fix so I'm feeling like this might have to sit on the roadmap a little longer until we can get some designs for possible solutions.

Ideas we had about this earlier were to place a section at the end of the message (the end of the scrolled message area) where we can show a link to ( See Entire Conversation )

More ideas (and even just variations) would be greatly appreciated.
How about just including it in the Message Menu and the right-click context menu? 

They are pretty much the locations where until now most people would expect all these things to be (and all other items in "other actions" are available in the standard menus).
I don't think putting this feature in the message menu or context menu would solve the issue of making it more visible.  I think it needs to be something that is visible by default, like for example the reply button, or the other actions menu itself.  I appreciate that real-estate is going to be an issue here, but I think this is such a useful feature that it deserves some space.

I also don't think putting a link at the end of the scrolled message area would work for me, as I find I use the feature most when I'm going back to a message that I've already read.  I'm using the message as a start point to jump me into the conversation, so I don't generally scroll through that message.  Even for new messages it is often still helpful to go to the original conversation before taking in the new details.

How about adding a 'yellow bar' (like the Show Remote Content bar) to the top of messages that are part of a conversation.  An initial implementation could just say 'This message is part of a conversation.  View Conversation'. or similar.

This bar could go on to be used to give more information about a messages context.  For example, for messages that you've replied to it could say, 'You replied to this message on 1/2/2010 at 12:35pm.  [View Conversation]'.  Such feature creep should probably be the subject of another bug, however!

I'm liking View Conversation more than View In Conversation.  In my opinion, 'view in conversation' makes it less clear what the feature does.
(In reply to comment #3)
> How about just including it in the Message Menu and the right-click context
> menu?

Mark, this will be fixed by Bug 525890 as soon as it gets your review - Missing (context) menu: Message > "Show in conversation"
Depends on: 525890
(In reply to comment #0)
> I would suggest that the UI to this could do with a re-work to make
> such a good feature more easily discoverable.

While bug 525890 will help to some extent, I think this bug should stay open to explore other ways of making this more discoverable (Bryan's comment 2).

> Secondly, it's perhaps not that clear what 'show in conversation' actually
> means.

Bug 525890 has changed the caption to "Open in conversation" (proposed by Bryan), as it's pretty much related to "openening" a msg (in its context).
In the same line of thought, we also implemented Ctrl+Shift+O as a keyboard shortcut for "Open in conversation", derived from Ctrl+O for "Open". I don't have strong feelings about the caption, but I think the concept of "Opening" makes a lot of sense and for many people it might just be "the other way of opening a message". "Open" is the established term that we use in the UI to describe the action of "showing" / "viewing" a msg.
I think my problem is that it's not really clear what '*in* conversation' means.  I'd like to suggest 'Open Whole Conversation'.  I think this makes it much clearer what this action will do.  (comment also added to bug 525890).

Whilst I'm commenting here, I'd like to re-iterate that this bug is about far more than a context menu or keyboard shortcut.  These are not easily discoverable features.
(In reply to comment #7)
> I think my problem is that it's not really clear what '*in* conversation'
> means.  I'd like to suggest 'Open Whole Conversation'.  I think this makes it
> much clearer what this action will do.  (comment also added to bug 525890).

Hmm. Not sure. We're /not/ really opening the whole conversation (i.e. every msg. of that conversation), what we actually do is "Open (selected) Message in the context of its conversation". But that's too long for a caption. The short version is "Open Message in conversation".  In the message menu, we skip the word Message, as we expect the user to implicitly read the word message with every command, like this: "Message > Open in conversation" = "Open [Message] in conversation".
I don't think this caption in itself is unclear. Some ambiguity arises when we iuxtapose this with the other "Open" variants:
"Open in new tab"
"Open in new window"
"Open in conversation"
It's confusing because the parallel wording might suggest that "conversation" is structurally similar to "new tab" or "new window". But in fact, you could open a message in conversation in a new window, or a new tab. But we don't offer that yet, we'd probably need different UI with popups for that.
Perhaps add a preference to make "Open in conversation" the default "Open" behavior?  (This wouldn't help with discoverability, but would help with usability once it is discovered.)
We need icons, but let's let the code-y bits get reviewed, and we'll pull forward the r and ui-r into the patch with icons…
Assignee: nobody → bwinton
Status: NEW → ASSIGNED
Attachment #595449 - Flags: ui-review?(nisses.mail)
Attachment #595449 - Flags: review?(mbanner)
(Oh, just to expand a little on that, I've added a button to the customize dialog of the message header and mail toolbar so that people can more easily access the functionality.  I'm not adding it to either toolbar by default yet, but we should also put something in the release notes, and perhaps even in the start page, or as a Tip Of The Day.)
(In reply to Blake Winton (:bwinton - Thunderbird UX) from comment #11)
> (Oh, just to expand a little on that, I've added a button to the customize
> dialog of the message header and mail toolbar so that people can more easily
> access the functionality.  I'm not adding it to either toolbar by default
> yet, but we should also put something in the release notes, and perhaps even
> in the start page, or as a Tip Of The Day.)

(In reply to Blake Winton (:bwinton - Thunderbird UX) from comment #10)
> We need icons, but let's let the code-y bits get reviewed, and we'll pull
> forward the r and ui-r into the patch with icons…

Does this really help, though? I'm ok with this, since I don't know if it should be in the primary UI all the time (I only rarely use this option, much less often than any of the other header buttons*), but I'm not sure how you'd make it more discoverable otherwise.

We should also hook up all the other "show in conversation" commands to this new <command> node to facilitate code reuse**. This would be a good time to fix bug 550775, too.

* To be fair, I might use it more if conversations weren't broken on Gmail due to how Gmail structures its folders.
** It would also get us one small step closer to using command="" instead of oncommand="" for our buttons/menu-items, which will make the "menu and toolbar usage" Test Pilot study much easier to implement.
Attached image icon proposals
A couple of icon variants I've came up with.
From left to right:
1. Same as thread icon
2. Breaking out thread
3. Well established metaphor on cell phone UIs
4. I think we want to save this one for a future generic-in-tab-menu feature.
How about something along the lines of a chat bubble?

(#2 seems a little too much like a flag to me.
 #3 seems more like "Send and Receive" than "Open in conversation".)
Chat bubble have been on my mind, but then there is also bug #714733
Yeah, that was my concern, too.  On the other hand, we may open chat results in that tab, too, so it might fit…  ;)

And we could still use a silhouetted head for "chat with this user"…
Comment on attachment 595449 [details] [diff] [review]
A patch to add the buttons.

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

::: mail/base/content/mail3PaneWindowCommands.js
@@ +312,5 @@
> +      case "button_showconversation":
> +        // Enable/disable the Open Conversation button.
> +        let prefBranch = Components.classes["@mozilla.org/preferences-service;1"]
> +                                   .getService(Components.interfaces.nsIPrefBranch2);
> +        let glodaEnabled = prefBranch.getBoolPref("mailnews.database.global.indexer.enabled");

Please use Services.prefs now (and nsIPrefBranch2 is obsolete!)

Same applies to messageWindow.xul...

@@ +316,5 @@
> +        let glodaEnabled = prefBranch.getBoolPref("mailnews.database.global.indexer.enabled");
> +
> +        if (glodaEnabled && gFolderDisplay.selectedMessages.length > 0) {
> +          let message = gFolderDisplay.selectedMessages[0];
> +          return Gloda.isMessageIndexed(message);

I think we can drop the intermediate variable.


Same applies to messageWindow.xul...

::: mail/locales/en-US/chrome/messenger/messenger.dtd
@@ +536,5 @@
>  <!ENTITY replyListButton.tooltip "Reply to mailing list">
>  <!ENTITY forwardButton.tooltip "Forward selected message">
>  <!ENTITY fileButton.tooltip "File selected message">
>  <!ENTITY archiveButton.tooltip "Archive selected messages">
> +<!ENTITY openConversationButton.tooltip "Open selected messages in their conversation">

How about "with their conversation" ?

::: mail/locales/en-US/chrome/messenger/msgHdrViewOverlay.dtd
@@ +58,5 @@
>  <!ENTITY editMessageButton.label "Edit…">
>  <!ENTITY hdrArchiveButton1.label "Archive">
>  <!ENTITY hdrArchiveButton1.tooltip "Archive this message">
> +<!ENTITY hdrOpenConversationButton1.label "Conversation">
> +<!ENTITY hdrOpenConversationButton1.tooltip "Open this message in its conversation">

How about "with its conversation" ?
Attachment #595449 - Flags: review?(mbanner) → review-
Do we need the ui-r open whilst we're discussing icons?
Please consider 668491 as this gets resolved.
Comment on attachment 595449 [details] [diff] [review]
A patch to add the buttons.

Cancelling ui-review for now, as I don't believe its of any use atm.
Attachment #595449 - Flags: ui-review?(nisses.mail)
(Assigning to Andreas to get a new icon… ;) )
Assignee: bwinton → nisses.mail
Blake, not much has changed in this area so perhaps it's OK to continue from "we need an icon" with paenglab?  Or, does this bug need a rethink?
Assignee: bugs → nobody
Blocks: 668491
Status: ASSIGNED → NEW
Flags: needinfo?(bwinton)
Yeah, I think continuing from "we need an icon" is reasonable.  "Show in Conversation" is still a neat feature, even six years later…  ;)
Flags: needinfo?(bwinton)
paenglab, plesae see comment 14 - 16
Flags: needinfo?(richard.marti)
Attached image other icon proposal
And how about this icon? I searched for conversation icons and most of them are looking like this. Still different enough to the chat icon.
Flags: needinfo?(richard.marti)
Attachment #8757614 - Flags: feedback?(bwinton)
Comment on attachment 8757614 [details]
other icon proposal

Yeah, I could go with this.  I mean, it does look a little like multiple chat icons, so it's not perfect, but I don't think we're going to get anything perfect here, and this works for the purpose.
Attachment #8757614 - Flags: feedback?(bwinton) → feedback+
Attached patch Bug546621.patch (obsolete) — Splinter Review
Blake's patch updated to tip and with icons which have f+ from Blake.
Assignee: nobody → richard.marti
Status: NEW → ASSIGNED
Attachment #8787975 - Flags: review?(mkmelin+mozilla)
Comment on attachment 8787975 [details] [diff] [review]
Bug546621.patch

Aceman, can you take this review? I never knew "Open in Conversation" existed, I found it under "More" in the message pane, but it's always disabled. How do you enable it?
Attachment #8787975 - Flags: review?(mkmelin+mozilla) → review?(acelists)
It's also in thread pane context menu the third on top.
You enable it by enabling gloda. (I have it disabled too...)
Comment on attachment 8787975 [details] [diff] [review]
Bug546621.patch

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

I can take this as I had already started...

::: mail/base/content/mail3PaneWindowCommands.js
@@ +303,5 @@
> +        let prefBranch = Components.classes["@mozilla.org/preferences-service;1"]
> +                                   .getService(Components.interfaces.nsIPrefBranch2);
> +        let glodaEnabled = prefBranch.getBoolPref("mailnews.database.global.indexer.enabled");
> +
> +        if (glodaEnabled && gFolderDisplay.selectedMessages.length > 0) {

Please just use 

  if (Services.prefs.getBoolPref("mailnews.database.global.indexer.enabled") && gFolderDisplay.selectedMessage)

@@ +304,5 @@
> +                                   .getService(Components.interfaces.nsIPrefBranch2);
> +        let glodaEnabled = prefBranch.getBoolPref("mailnews.database.global.indexer.enabled");
> +
> +        if (glodaEnabled && gFolderDisplay.selectedMessages.length > 0) {
> +          let message = gFolderDisplay.selectedMessages[0];

gFolderDisplay.selectedMessage, but just pass that directly. (no need to declare a variable for it)

::: mail/base/content/messageWindow.js
@@ +958,5 @@
> +        let prefBranch = Components.classes["@mozilla.org/preferences-service;1"]
> +                                   .getService(Components.interfaces.nsIPrefBranch2);
> +        let glodaEnabled = prefBranch.getBoolPref("mailnews.database.global.indexer.enabled");
> +
> +        if (glodaEnabled && gFolderDisplay.selectedMessages.length > 0) {

same thing here of course
but I suppose it should just be enabled for single selections? if it's different threads...

::: mail/locales/en-US/chrome/messenger/messenger.dtd
@@ +547,5 @@
>  <!ENTITY forwardAsInline.tooltip "Forward selected message as inline text">
>  <!ENTITY forwardAsAttachment.tooltip "Forward selected message as an attachment">
>  <!ENTITY fileButton.tooltip "File selected message">
>  <!ENTITY archiveButton.tooltip "Archive selected messages">
> +<!ENTITY openConversationButton.tooltip "Open selected messages in their conversation">

Show conversation of selected message

?
Attachment #8787975 - Flags: review?(acelists)
(In reply to Magnus Melin from comment #31)
> Comment on attachment 8787975 [details] [diff] [review]
> Bug546621.patch
> 
> Review of attachment 8787975 [details] [diff] [review]:
> -----------------------------------------------------------------
> ::: mail/base/content/messageWindow.js
> @@ +958,5 @@
> > +        let prefBranch = Components.classes["@mozilla.org/preferences-service;1"]
> > +                                   .getService(Components.interfaces.nsIPrefBranch2);
> > +        let glodaEnabled = prefBranch.getBoolPref("mailnews.database.global.indexer.enabled");
> > +
> > +        if (glodaEnabled && gFolderDisplay.selectedMessages.length > 0) {
> 
> same thing here of course
> but I suppose it should just be enabled for single selections? if it's
> different threads...

When multiple messages are selected, only the first opens in conversation tab.
Should this part be removed from messageWindow.js?
Flags: needinfo?(mkmelin+mozilla)
My changing of the reviewer didn't subscribe me to the bug, grrr.

(In reply to Richard Marti (:Paenglab) from comment #29)
> It's also in thread pane context menu the third on top.
Found it. But the menu item doesn't show on the topmost message in the folder, strange. I'll try the patch now.

(In reply to Magnus Melin from comment #30)
> You enable it by enabling gloda. (I have it disabled too...)
I have that enabled, as Kent says: We need to eat our own dog food. Did you know that Gloda autocomplete is completely broken? Bug 1271445 comment #11.
Can someone please explain to me when the various "Open in Conversation" menu items/buttons should be enabled/present. Does that only work when Gloda has index them?

If I select two messages each of which has "Open in Conversation", both of them selected results in
Message > "Open in Conversation" greyed out. However, the new button stays enabled. So there is something wrong here. As Richard pointed out, if you select two messages from different threads, only one in displayed in a conversation. So I'd recommend that the button follow the menu item and get disabled when more than one message is selected.
(In reply to Richard Marti (:Paenglab) from comment #32)
> When multiple messages are selected, only the first opens in conversation
> tab.

Yes, that's why I'd keep it enabled only when one message is selected.

> Should this part be removed from messageWindow.js?

Would be pretty sweat to use it from the standalone message window, but if it doesn't work you should remove it.
Flags: needinfo?(mkmelin+mozilla)
Attached patch Bug546621.patch (obsolete) — Splinter Review
(In reply to Magnus Melin from comment #31)
> Comment on attachment 8787975 [details] [diff] [review]
> Bug546621.patch
> 
> Review of attachment 8787975 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> I can take this as I had already started...
> 
> ::: mail/base/content/mail3PaneWindowCommands.js
> @@ +303,5 @@
> > +        let prefBranch = Components.classes["@mozilla.org/preferences-service;1"]
> > +                                   .getService(Components.interfaces.nsIPrefBranch2);
> > +        let glodaEnabled = prefBranch.getBoolPref("mailnews.database.global.indexer.enabled");
> > +
> > +        if (glodaEnabled && gFolderDisplay.selectedMessages.length > 0) {
> 
> Please just use 

and

>   if (Services.prefs.getBoolPref("mailnews.database.global.indexer.enabled")
> && gFolderDisplay.selectedMessage)
> 
> @@ +304,5 @@
> > +                                   .getService(Components.interfaces.nsIPrefBranch2);
> > +        let glodaEnabled = prefBranch.getBoolPref("mailnews.database.global.indexer.enabled");
> > +
> > +        if (glodaEnabled && gFolderDisplay.selectedMessages.length > 0) {
> > +          let message = gFolderDisplay.selectedMessages[0];
> 
> gFolderDisplay.selectedMessage, but just pass that directly. (no need to
> declare a variable for it)

fixed

> ::: mail/base/content/messageWindow.js
> @@ +958,5 @@
> > +        let prefBranch = Components.classes["@mozilla.org/preferences-service;1"]
> > +                                   .getService(Components.interfaces.nsIPrefBranch2);
> > +        let glodaEnabled = prefBranch.getBoolPref("mailnews.database.global.indexer.enabled");
> > +
> > +        if (glodaEnabled && gFolderDisplay.selectedMessages.length > 0) {
> 
> same thing here of course

I removed it because it doesn't work in standalone message window because it can't find a tab. This could surely been fixed but is not in my capabilities. Also the conversation menuitem in this window is alwasy disabled

> but I suppose it should just be enabled for single selections? if it's
> different threads...

fixed

> ::: mail/locales/en-US/chrome/messenger/messenger.dtd
> @@ +547,5 @@
> >  <!ENTITY forwardAsInline.tooltip "Forward selected message as inline text">
> >  <!ENTITY forwardAsAttachment.tooltip "Forward selected message as an attachment">
> >  <!ENTITY fileButton.tooltip "File selected message">
> >  <!ENTITY archiveButton.tooltip "Archive selected messages">
> > +<!ENTITY openConversationButton.tooltip "Open selected messages in their conversation">
> 
> Show conversation of selected message

Used your proposal.
Attachment #8787975 - Attachment is obsolete: true
Attachment #8791294 - Flags: review?(mkmelin+mozilla)
Thanks, works fine. I'll let Magnus give the final seal of approval.
Comment on attachment 8791294 [details] [diff] [review]
Bug546621.patch

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

::: mail/base/content/mail3PaneWindowCommands.js
@@ +302,5 @@
> +        // Enable/disable the Open Conversation button.
> +        if (Services.prefs.getBoolPref("mailnews.database.global.indexer.enabled") &&
> +            gFolderDisplay.selectedCount == 1 && gFolderDisplay.selectedMessage)
> +          return Gloda.isMessageIndexed(gFolderDisplay.selectedMessage);
> +        return false;

Sorry, this is correct in a way, but I realized we already have cmd_openConversation, so you should just put the button_showconversation case next to that and fall through, for all the cases

::: mail/locales/en-US/chrome/messenger/msgHdrViewOverlay.dtd
@@ +24,5 @@
>  
>  <!ENTITY hdrArchiveButton1.label "Archive">
>  <!ENTITY hdrArchiveButton1.tooltip "Archive this message">
> +<!ENTITY hdrOpenConversationButton1.label "Conversation">
> +<!ENTITY hdrOpenConversationButton1.tooltip "Open this message in its conversation">

Change this too?
Attachment #8791294 - Flags: review?(mkmelin+mozilla)
Attached patch Bug546621.patch (obsolete) — Splinter Review
This should address the review comments.
Attachment #8791294 - Attachment is obsolete: true
Attachment #8791366 - Flags: review?(mkmelin+mozilla)
Comment on attachment 8791366 [details] [diff] [review]
Bug546621.patch

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

::: mail/base/content/mail3PaneWindowCommands.js
@@ +140,5 @@
>        case "cmd_cancel":
>        case "cmd_deleteFolder":
>        case "button_delete":
>        case "button_junk":
> +      case "button_showconversation":

for controllers you have three cases: supported, enabled and docommand. 

you just have two cases, so supports/or enabled is missing. (I don't see which in the diff)

::: mail/locales/en-US/chrome/messenger/messenger.dtd
@@ +547,5 @@
>  <!ENTITY forwardAsInline.tooltip "Forward selected message as inline text">
>  <!ENTITY forwardAsAttachment.tooltip "Forward selected message as an attachment">
>  <!ENTITY fileButton.tooltip "File selected message">
>  <!ENTITY archiveButton.tooltip "Archive selected messages">
> +<!ENTITY openConversationButton.tooltip "Show conversation of selected message">

you changed it the wrong direction ;)
Attachment #8791366 - Flags: review?(mkmelin+mozilla)
(In reply to Magnus Melin from comment #40)
> Comment on attachment 8791366 [details] [diff] [review]
> Bug546621.patch
> 
> Review of attachment 8791366 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: mail/base/content/mail3PaneWindowCommands.js
> @@ +140,5 @@
> >        case "cmd_cancel":
> >        case "cmd_deleteFolder":
> >        case "button_delete":
> >        case "button_junk":
> > +      case "button_showconversation":
> 
> for controllers you have three cases: supported, enabled and docommand. 
> 
> you just have two cases, so supports/or enabled is missing. (I don't see
> which in the diff)

The case "button_showconversation": is in supportsCommand: function(command) and isCommandEnabled: function(command)

In doCommand: function(command, aTab) it's missing. Do I need to add here something like:

case "button_showconversation":
  break;


> ::: mail/locales/en-US/chrome/messenger/messenger.dtd
> @@ +547,5 @@
> >  <!ENTITY forwardAsInline.tooltip "Forward selected message as inline text">
> >  <!ENTITY forwardAsAttachment.tooltip "Forward selected message as an attachment">
> >  <!ENTITY fileButton.tooltip "File selected message">
> >  <!ENTITY archiveButton.tooltip "Archive selected messages">
> > +<!ENTITY openConversationButton.tooltip "Show conversation of selected message">
> 
> you changed it the wrong direction ;)

Really? This is your proposal in comment 31.
Flags: needinfo?(mkmelin+mozilla)
Attached patch Bug546621.patchSplinter Review
(In reply to Magnus Melin from comment #40)
> Comment on attachment 8791366 [details] [diff] [review]
> Bug546621.patch
> 
> Review of attachment 8791366 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: mail/base/content/mail3PaneWindowCommands.js
> @@ +140,5 @@
> >        case "cmd_cancel":
> >        case "cmd_deleteFolder":
> >        case "button_delete":
> >        case "button_junk":
> > +      case "button_showconversation":
> 
> for controllers you have three cases: supported, enabled and docommand. 
> 
> you just have two cases, so supports/or enabled is missing. (I don't see
> which in the diff)

Figured out how to do it.

> ::: mail/locales/en-US/chrome/messenger/messenger.dtd
> @@ +547,5 @@
> >  <!ENTITY forwardAsInline.tooltip "Forward selected message as inline text">
> >  <!ENTITY forwardAsAttachment.tooltip "Forward selected message as an attachment">
> >  <!ENTITY fileButton.tooltip "File selected message">
> >  <!ENTITY archiveButton.tooltip "Archive selected messages">
> > +<!ENTITY openConversationButton.tooltip "Show conversation of selected message">
> 
> you changed it the wrong direction ;)

As wrote before, I used your proposal in messenger.dtd and now in msgHdrViewOverlay.dtd "Show conversation of this message".
Attachment #8791366 - Attachment is obsolete: true
Flags: needinfo?(mkmelin+mozilla)
Attachment #8791486 - Flags: review?(mkmelin+mozilla)
Comment on attachment 8791486 [details] [diff] [review]
Bug546621.patch

This looks like a nice and very straight forward patch now. Thanks Richard for the perseverance.
Comment on attachment 8791486 [details] [diff] [review]
Bug546621.patch

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

LGTM, thx! r=mkmelin

Must have been to tired before ;)
Attachment #8791486 - Flags: review?(mkmelin+mozilla) → review+
Keywords: checkin-needed
Summary: 'Show in conversation' feature is too hidden → 'Show in conversation' feature is too hidden - add a "Conversation" toolbar button
https://hg.mozilla.org/comm-central/rev/ac9e6b6f0497
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 51.0
See Also: → 1313871
See Also: → 668491
Blocks: 1475910
You need to log in before you can comment on or make changes to this bug.