I've wanted this feature for a long time (as measured in years). Basically I get "threads" of bugmail, and I would like to be able to view the thread that I have in approximately the same way that it would appear in bugzilla. I tend to use mozmail w/ collapsed headers, so I'd want something like this: --- [W] Subject: Updated API ref Newsgroups: netscape.public.mozilla.jseng -- [f] Sterling Bates (whoelse@sterlingbates.com) Date: 2004-04-20 13:22:34 PST OK, I'm done running through and correcting the following: - syntax & type declarations - spelling errors - most grammar errors The diff file is about 250K, so how should I submit it? Sterling [f] Sterling Bates (whoelse@sterlingbates.com) Date: 2004-04-20 13:22:35 PST [+] <quotation collapsed, click here to expand> Oh, and it also includes all of the missing API functions and data structures. I haven't updated all of the #define's tho (like JSREG_FOLD, JSREG_GLOB, etc). Sterling [f] Brendan Eich (brendan@meer.net) Date: 2004-04-20 14:01:47 PST [+] <quotation collapsed, click here to expand> Hmm, that's gonna be hard to read. Maybe you should get some trusted English-fluent proofreaders to read through your patched site? Or we land it and then do that? I'm very willing to believe that you made things better on average, but I would want to review what you did. /be [f] Sterling Bates (whoelse@sterlingbates.com) Date: 2004-04-20 14:26:00 PST (Accidentally replied privately...) Brendan Eich wrote: > Hmm, that's gonna be hard to read. [+] <quotation collapsed, click here to expand> I certainly don't mind having people proofread it. I walked through the spelling using MS Word, and only made obvious grammatical corrections, if that helps :) My mother has her M.A. in English Literature, but she'd be entirely lost with the subject matter. I think it'll be easier to render it out in a standard HTML or ASCII format. If you can point me to a decent converter for that task (XSL?) then I'll post it on my website until we're sure it's OK. Sterling [f] Brendan Eich (brendan@meer.net) Date: 2004-04-20 14:31:54 PST [+] <quotation collapsed, click here to expand> Ah -- good to know. Thanks for doing this work! [+] <quotation collapsed, click here to expand> Just pull mozilla/js/docs from cvs.mozilla.org or cvs-mirror.mozilla.org, copy your jsref.xml over the one there, type make, and point a browser at the gen/ directory. /be [f] Sterling Bates (whoelse@sterlingbates.com) Date: 2004-04-20 14:41:54 PST Brendan Eich wrote: [+] <quotation collapsed, click here to expand> Unfortunately I don't have cygwin working on my machine yet, so I need an nmake equivalent, if there is one. Sorry :( [f] Sterling Bates (whoelse@sterlingbates.com) Date: 2004-04-20 14:52:34 PST [+] <quotation collapsed, click here to expand> I'm just downloading perl right now, and then I'll manually do the instructions in Makefile. Looks easy enough :) [f] Sterling Bates (whoelse@sterlingbates.com) Date: 2004-04-20 15:42:07 PST [+] <quotation collapsed, click here to expand> OK, the generated docs are available at http://www.sterlingbates.com/jsref/sparse-frameset.html and http://www.sterlingbates.com/jsref/complete-frameset.html Sterling [f] Sterling Bates (whoelse@sterlingbates.com) Date: 2004-04-20 16:25:30 PST [+] <quotation collapsed, click here to expand> Sorry for the deluge today, just one more note. I've uploaded the diff.txt and jsref.xml files to my site as well: http://www.sterlingbates.com/jsref/diff.txt and http://www.sterlingbates.com/jsref/jsref.xml --- If you're viewing a thread and some messages have been read before, then by default the view should be like this: --- [W] Subject: Updated API ref Newsgroups: netscape.public.mozilla.jseng -- [f] Sterling Bates (whoelse@sterlingbates.com) Date: 2004-04-20 13:22:34 PST [f] Sterling Bates (whoelse@sterlingbates.com) Date: 2004-04-20 13:22:35 PST [f] Brendan Eich (brendan@meer.net) Date: 2004-04-20 14:01:47 PST [f] Sterling Bates (whoelse@sterlingbates.com) Date: 2004-04-20 14:26:00 PST [f] Brendan Eich (brendan@meer.net) Date: 2004-04-20 14:31:54 PST [f] Sterling Bates (whoelse@sterlingbates.com) Date: 2004-04-20 14:41:54 PST [f] Sterling Bates (whoelse@sterlingbates.com) Date: 2004-04-20 14:52:34 PST [f] Sterling Bates (whoelse@sterlingbates.com) Date: 2004-04-20 15:42:07 PST Sterling Bates (whoelse@sterlingbates.com) Date: 2004-04-20 16:25:30 PST [+] <quotation collapsed, click here to expand> Sorry for the deluge today, just one more note. I've uploaded the diff.txt and jsref.xml files to my site as well: http://www.sterlingbates.com/jsref/diff.txt and http://www.sterlingbates.com/jsref/jsref.xml --- behaviors: 1. clickable widgets: W means watched and would have the watch icon, w means not watched and would have some other icon F means flagged and would have the flagged icon, f means not flagged and would have some other icon Clicking W/F widgets would toggle the widget clicking the header of a collapsed message would uncollapse the message (this probably corresponds internally to marking as unread). 2. Double clicking on a line like: [f] Sterling Bates (whoelse@sterlingbates.com) Date: 2004-04-20 14:41:54 PST should open that individual message in a new window (with view>thread>as conversation unchecked). 3. In this mode (view>thread>as conversation checked), pressing delete would delete the entire thread. 4. Reading a thread using this mode will mark all messages for a thread as read at the same time (or unread if you foolishly decide to toggle the read bit). 5. if you select a series of messages (that don't 'seem' to be from the same conversation), the engine should splice them together just like anything else. 6. If some messages are signed and some aren't, then the inline header item (<From> ... <Date>) could have icon(s) for the various status creatures (signed, encrypted, whatever). 7. Dates. Mozilla supports semi intelligent dates, so the dates should be rendered that way instead of with the absolute dates listed in my examples. Ideally dates would be of the form (20 mins ago/yesterday/2 days ago/last month/abs date) instead of 20:10 which doesn't really help me unless I have a clock (and I never look at my clock - the datestamp on this submission should be proof of that). WRT live updates of timestamps, I don't absolutely need it. But if BIFF triggers and the thread updates, then the timestamps should update.

Are you proposing putting the message listing (currently the thread pane) in the same pane as the message text? And the ability to show text from multiple messages simultaneously? In the case of bugmail, how do you propose handling the display of changes to the various fields, which may or may not be accompanied by a comment? Bugmail is an unusual case because the stream of messages is enforced in a linear pattern rather than threaded. Are there other services which have a similar constraint? For a regular message thread, if I understand the request correctly, "View as Conversation" would be worse than a threaded view, altho perhaps a little better than a regular flat view.

> In the case of bugmail, how do you propose handling the display of changes to > the various fields, which may or may not be accompanied by a comment? Not a problem, because field changes are merely (new) text for the mail client. timeless, from how I understand it, you lose the threading/hierarchy information. If somebody replies with just "I agree" (without quote - ok, rare case), how am I supposed to decipher that? Even if there's a quote before/after the "I agree", you hide the quote, so people are likely to misinterpret the msg, if there are other msgs between the "me too" msg and the original one.

worst case, mozmail and end user can't figure out what was referenced by 'i agree' and turns off this feature temporarily, ideally most of the time we do something intelligent, i'll have to play with this a bit to see how it works. since this feature has been around for ages, we could prototype it w/ npm.test or whatever and groups.google.com

> worst case, mozmail and end user can't figure out what was referenced I am talking about the case where mozmail *can* figure it out, and currently does display in threaded mode, by using the References / In-Reply-To header.

welp, groups.google.com shows you a tree of the messages, which enables you to see how responses relate. groups.google.com also lets you view "sorted by reply" or "sorted by date". unfortunately i don't have any threaded conversations in gmail yet, i suppose i should get bugzilla-reviewers or something to spam gmail for a while, that should enable me to build up a corpus. i suppose one could actually have the messages or headers or something indent, or draw a tree of some sort off to an edge.

> i suppose one could actually have the messages or headers or something indent slashdot?

*** Bug 268274 has been marked as a duplicate of this bug. ***

*** Bug 362654 has been marked as a duplicate of this bug. ***

Any news on this feature? I would love to see a flat view with all of the messages in a thread concatenated into a single page.

no one working on this???

Not yet; are you interested in signing up?

I am new to open source development, a student graduating this december, I would not mind assisting someone with this.

Great! Shoot me an email at dmose@mozilla.org with a short description of what your skillset is, how much time you'd be interested in spending, and I'll help try and figure out the best way we can structure something...

For a detailed description of Gmail's threading with user's replies, see the heading "Viewing a conversation thread" on this page: http://xkahn.zoned.net/software/evolution/threads/ ‎This is also relevant: http://taint.org/wk/GmailThreadingDetails

Those are very useful and relevant links; thanks for adding them!

A few notes: 1) Using Gloda would allow cross-folder conversations, so I _strongly_ recommend using those APIs rather than the per-folder ones. 2) I'd suggest working on it as an add-on first, to figure out a lot of the details. Then we can consider adding the functionality to the core in a second phase.

I would love to see Gmail-like conversations.

also check out the thread summary bug 454829 which gives a conversation summary on collapsed threads. There are also options for extension to enhance the summary view.

Has there been any progress on this? I would also love this in TB...

(In reply to comment #22) > Has there been any progress on this? > I would also love this in TB... all that's known about the bug should be here for your reading pleasure ^^

Agreed!!!

IMHO, this is _the_ feature that's missing from Thunderbird. Postbox[1], a commercial Thunderbird fork, implements this feature very well, maybe it can serve as an additional source of inspiration. http://www.postbox-inc.com/features

If you click on "other actions" in the message reader and choose "show in conversation", we will launch a new tab (or window depending on prefs) that uses the global database to show all of messages belonging to the conversation regardless of the folder they are located in. The presentation is the standard 3-pane view. I believe there is an add-on available that does more of the web UI styling of the conversation using the message pane.

asuth, that feature 1) doesn't work when invoked from standalone msg window. 2) It is also, as you said, just a normal threadpane filtered to the current thread. The value of the conversation view - reading the whole thread in one page which I can scroll through in one go - is not here. So, this feature doesn't help at all, unfortunately.

I've started working on an extension that roughly does what is suggested here [1] [2]. I'd be glad to split my work into smaller patches to get them integrated, if you guys are willing to do this. [1] is pretty outdated unless you install the "Beta channel" or the "Latest development version". Just give [2] a quick look or check out the screenshot next to the "Download now" link on [1]. I wanted to wait a little bit before offering to integrate my patches, because my extension is slightly messy. However, I figured out I might as well start discussing right now before going further. There's a ton of bugs [3] because this *really* requires a huge amount of work. I've already spent many an evening working on this, diving into nsMessenger.cpp to figure out how to display a full message properly ;-). So the quality is not as high as I'd like, as I spend most of my time fixing the many bugs / feature requests reported by users. In particular, my "- show quoted text -" algorithm really sucks (actually, it's not even an algorithm, just some hacks). I also didn't integrate too deep into the Thunderbird codebase because I wanted an extension that doesn't interfere too much with the base code (and I'm already overriding too much, which requires me to track changes from at least two files); alas, that makes the Gloda queries completely sub-optimal. Anyway, just tell me if you think we can work out something. [1] https://addons.mozilla.org/en-US/thunderbird/addon/54035 [2] http://wiki.github.com/protz/GMail-Conversation-View/tour [3] http://github.com/protz/GMail-Conversation-View/issues

(In reply to comment #28) > Anyway, just tell me if you think we can work out something. Your extension is very exciting and exactly the kind of thing I hope for when I think about the potential extensions people might write! The current state of things is that I think in the short term we do not want to try and get this into the Thunderbird core, but we do want to enable and simplify the development of extensions such as yours. The rationale for not putting it in core is that, as you have discovered, the code you are having to deal with is ugly and has corner cases all over the place that make things painful. Also, development in core at the current time slows things way down. The gameplan going forward is to build on the Jetpack SDK technology and the abstraction groundwork laid by gloda. I have been working on a DOM-based widget/templating system that should hopefully make it easier to develop HTML DOM-backed interfaces where the code does not become a horrible mess. My next 2 weeks are basically given over to Thunderbird 3.1 so unfortunately there won't be any work on the widget system ("wmsy") or Jetpack stuff. However, if you want to place your bets on my plan while hopefully still being useful to your current extension work, I would suggest the following: 1) Look into using and extending the gloda 'connotent' content whittling system. It's a framework for processing message bodies to try and figure out what is quoted and what is cruft (ex: bugzilla boilerplate). It uses the JS mime emitter to get a representation of the message and goes from there. There are even unit tests! :) abstraction: http://mxr.mozilla.org/comm-central/source/mailnews/db/gloda/modules/connotent.js basic quoting implementation: http://mxr.mozilla.org/comm-central/source/mailnews/db/gloda/modules/fundattr.js#760 unit tests: http://mxr.mozilla.org/comm-central/source/mailnews/db/gloda/test/unit/base_gloda_content.js bugzilla content whittler: http://hg.mozilla.org/users/bugmail_asutherland.org/gp-bugzilla/file/a4317682a3d7/modules/attr_bug.js#l170 2) Join the tb-planning list and please post what specific things would be useful to your extension in the broader picture. Which is to say, specific hang-ups of building off of the thread summary code are not likely to be important, but knowing that gloda is not exposing some information you need is very interesting. I think from IRC you were also streaming messages into iframes? I'd be interested to hear results about that, noting that direct message streaming into an iframe is obviously going to not line up so great with the gloda connotent stuff as it stands. https://mail.mozilla.org/listinfo/tb-planning

(In reply to comment #29) > Your extension is very exciting and exactly the kind of thing I hope for when I > think about the potential extensions people might write! > :) > The current state of things is that I think in the short term we do not want to > try and get this into the Thunderbird core, but we do want to enable and > simplify the development of extensions such as yours. I wasn't thinking about that. Rather, submitting small patches that make my life easier and help you solve some details (such as bug 538750 for instance). Of course I'm pretty sure I won't land such a big thing anywhere in the near future. But as I'm fixing bugs in Thunderbird in the course of developing my extension, yes, I might as well submit patches! > > The gameplan going forward is to build on the Jetpack SDK technology and the > abstraction groundwork laid by gloda. I have been working on a DOM-based > widget/templating system that should hopefully make it easier to develop HTML > DOM-backed interfaces where the code does not become a horrible mess. > We're not strictly speaking about an HTML interface here. Rather, replacing a part that's already in HTML with some more HTML. But if you can simplify my life, yes, I'd be pretty happy. I've tried jQuery as it is included in Tb3 but that really wasn't very useful... > > 1) Look into using and extending the gloda 'connotent' content whittling > system. I'll try to improve that. However, it seems to me that you're just using very simple code to detect quoted parts. Many Outlook versions don't use "> " (often use some kind of a header), nor does Hotmail (often uses a <hr />)... I've added some hacks in my extension which of course are far from being reliable but that detect more quoted parts than just RFC-compliant "> ". I may try to add the more reliable of them. By the way, there is some other code in Cc["@mozilla.org/txttohtmlconv;1"] that already does that (see citeLevelTXT http://mxr.mozilla.org/comm-central/source/mozilla/netwerk/streamconv/public/mozITXTToHTMLConv.idl#108 ; this method tells you whether a given line is a quoted line or not, and its quoting depth). Why reinvent the wheel? Moreover, the code from txttohtmlconv recognizes far more quoting styles than yours (see http://mxr.mozilla.org/comm-central/source/mozilla/netwerk/streamconv/converters/mozTXTToHTMLConv.cpp#1058 for instance). Is there any specific reason for that? > > > 2) Join the tb-planning list and please post what specific things would be > useful to your extension in the broader picture. Which is to say, specific > hang-ups of building off of the thread summary code are not likely to be > important, but knowing that gloda is not exposing some information you need is > very interesting. I will most certainly do that. I'll try to post a detail report that stresses the areas that need some further efforts IMHO for extension developers. > > I think from IRC you were also streaming messages into iframes? I'd be > interested to hear results about that, noting that direct message streaming > into an iframe is obviously going to not line up so great with the gloda > connotent stuff as it stands. Well it works pretty well, minus some gory details about iframe heights and load events. > > https://mail.mozilla.org/listinfo/tb-planning See you there!

> the code from txttohtmlconv recognizes far more quoting styles than yours Note that this is only true #ifdef QUOTE_RECOGNITION_AGGRESSIVE, which by default is not defined (and needs a recompile).

(In reply to comment #30) > Why reinvent the wheel? Moreover, the code from txttohtmlconv > recognizes far more quoting styles than yours (see > http://mxr.mozilla.org/comm-central/source/mozilla/netwerk/streamconv/converters/mozTXTToHTMLConv.cpp#1058 > for instance). Is there any specific reason for that? The goal is extensibility, not just quoting detection. For example, the bugzilla whittler gets rid of the bugzilla ASCII art, and something that eats the boilerplate from facebook e-mails was also envisioned. Also, I think in the specific case this was implemented for (whittling to the text we put in the fulltext index) we don't remotely want HTML output. Having the implementation in JavaScript instead of C++ is considered a win. Besides making hacking on it easier and more accessible, it also will allow us to share code with raindrop. If someone, say you, wanted to try and port some of the more advanced quoting logic, that would be great. Just please be sure to add unit tests for the new cases; it doesn't look like the txttohtmlconv has any so I fear it can't be raided for those.

Protz' Conversations is now out, popular and quite appreciated by people who tried it. However, - converting it into the core seems a big task that neither the TB team nor Protz is able to undertake at this moment. - while close the widely adopted gMail presentation, it radically changes the traditional Thunderbird presentation of messages and may get users confused - it still shows some bugs and compatibility issues with some extensions One way to encourage the discovery of its features while keeping it as an addon is to think at a better and seamless integration with TB UI. The proposal is as follows: - protz to implement an activate/disactivate pref toggle that will trigger hot Conversation presentation on or off without restart. This is different from the add-on Enable/Disable control. - Figure out a menu entry (and/or toolbar widget) to toogle Conversations on/off when installed. Maybe View/Threads/As conversations... is finally the right thing to do.

So because the code that short-circuits various parts of Thunderbird to plug in the conversation is clean, it will be very easy to make conversations disable-able through a pref. Two important questions are: - do we want to install Conversations by default, in its disabled state, or just leave it in the discovery pane, and let people install it? - what is a good UI to tell people "hey, you can easily disable this feature by going into View > Conversations"? - what is a good UI to enable/disable it? I'm afraid a menu entry is a little bit hard to find. Ideas are welcome :). I'll try to implement this sooon.

Tried it, and it looks very good, a *lot* more mature than the last one I tested. Looks usable to me now. Surprisingly usable, in fact. (I didn't look at the code, but I am happy that it's using frames for each msg, which are critical for security.) jb, Mozilla should just hire jcramner, pretty please :)

> jb, Mozilla should just hire jcramner, pretty please :) Sorry, I meant protz of course. (I wouldn't mind jcramner either, though.)

In the dependencies are now a list of bugs that I'd like to see fixed to further polish Thunderbird Conversations. Some of them are assigned to me, and I still wish I'd find the time to fix them. For others, I'd be immensely grateful if someone could fix them. bug 478167 and bug 561859 would be very, very beneficial. I believe the former is very easy, and latter easy too (just a bit tedious). Other valuables improvements in Thunderbird that could help me somehow (no bugs filed for these): - make the code that sends a return receipt take a list of msgDbHdrs as a parameter, so that I can prompt the user for a return receipt too (right now, it's hardcoded that the return receipt should be sent for the selected message), - https://github.com/protz/GMail-Conversation-View/issues/295 which is probably the symptom of an underlying Thunderbird bug (more reports on getsatisfaction, :bienvenu and I tried to track it down some time ago on IRC with no luck), - quoting only selected text has getElementById("messagepane") hardcoded on the C++ side so I cannot perform monkey patching there, - https://github.com/protz/GMail-Conversation-View/issues/353 is also a bug in Thunderbird (when opening a compose window with a pre-filled message body, the message body is appended *after* the signature) The rest is work that should be performed on Thunderbird Conversations itself.

> right now, it's hardcoded that the return receipt should be sent for the selected message I misunderstood that, I read it that it's always sending without asking, if I have the pref on "ask". That'd be a privacy problem. protz told me that it's currently never sending. That's good, keep it like that :). This is not AOL.

+1