smart subjects in the thread pane (like zimbra) I just noticed that in zimbra, the subject lines include the plain text part of the message, as preview. for an unread message, it does: <bold>message subject</bold><grey>plain text beginning of the message...</grey> for read message, it does: <normal>message subject</normal><grey>plain text beginning of the message...</grey> for messages without subject, instead of a blank line (in tbird), it does: <normal><No Subject><normal><grey>plain text beginning of the message</grey> here come some screen shots...

Bug 307070 is quite similar.

thanks magnus, it is similar to bug #307070 (logged by dan). But, one thing I really like about what zimbra does is that it keeps the compact, one row per message model. so, I don't think this is a duplicate (but it is related)

I don't want to lose track of this bug. I wonder. It should be pretty easy to just append the preview text (if we have fetched it) to the data we paint into the row for the subject column. Might be harder to make the preview text part be in a different color from the subject though.

Gmail uses this style also.

> Might be harder to make the preview text part be in a different color from the > subject though. good point, I didn't think about that. here's where I demonstrate my CSS ignorance: what about Pseudo-elements? we use css to make the unread messages text bold. what about using CSS to make the :first-line of the subject be non-italic and non-grey but by default, all subjects are italic and grey? See http://www.w3.org/TR/REC-CSS2/selector.html that would require us to have multiple lines in the subject, which we might currently be stripping out. another idea, if we currently escaping < > & ; from subjects to display them as intended, we could wrap emit a <span class="previewbody">[escaped body text]</span> but I don't know if the tree will do the right thing when it gets a tag.

this does the simple part, appending the preview text to the subject column in the thread pane. It only does so if we've figured out the preview text. I also noticed that the preview text value we get from the msg hdr doesn't always match. Sometimes I'm getting the preview text for a message I've deleted. Someone might see this patch and be interested in picking it up and investigating the CSS style issue to make the preview text grey.

One thing I'm not liking about this patch is that the tooltip on the subject cell fills the width of my entire monitor because the subject is now really long (usually 2K or so). We might want to force a max width on the tooltip or something.

It might be worth trying this patch out on the trunk now that the compress quotes code has landed there. The problem I reported earlier with preview text getting assigned to the wrong messages was due to an unrelated change in my tree.

Comment on attachment 250522 [details] [diff] [review] work in progress David, what do you think about experimenting with this a bit on the trunk?

Comment on attachment 250522 [details] [diff] [review] work in progress yes, worth playing with on the trunk.

this patch will be in tomorrow's trunk build so we can start experimenting and collecting feedback.

(In reply to comment #13) > this patch will be in tomorrow's trunk build so we can start experimenting and > collecting feedback. I presume you guys have already noticed the non-printing characters that are showing up? I'll be interested to see how this looks once the true subject is made bold. Currently it's harder to scan subjects when the preview is printed due to clutter. Cheers

Besides the non-printing character separating the actual subject from the text, I'm seeing q-p characters. I'm also seeing this appearing very inconsistently across messages. At the moment, in my Inbox, the body only appears for messages dated after 1/1/2007; and not for two messages from someone else on the Well using Squirrelmail webmailer (webmail.well.com) -- I don't see anything obvious about those messages' source that might lead to them not getting their subject listed -- nor one message that has a longish subject header. I will add my voice to the chorus: Please Let Us Turn This Off, Thank You. Altho it certainly provides more information, I think it makes the thread pane far less readable. Edward Tufte wouldn't like it. :)

Whoa -- I just realized that the "two Squirrelmail messages" were actually the same message -- I had a ghost dupe in there. I deleted one and other turned into a "31-Dec-69" message. So I undeleted (it came back, marked Unread) and then Rebuilt Index: and now the subject isn't appearing for any of the messages in the Inbox. I switched to a different Inbox and saw the body for some of the messages (all recent, but since sometime in November, not since 1/1). Switched back, still none. (This is all with 3a1-0110.) Too erratic! I'm going back to 2b1.

I've been running the tip of the 2.0 branch recently, not 3.0 - but it's not clear to me how those symptoms could be related to this change. I'll try running the trunk for a little bit and see if I see any of those problems.

I've been running 2b1 75% of the time or more of late. I didn't mean to imply that this bug's feature caused the duplicate message, just that having the duplicate-message symptom, and cleaning up after it, may have caused the body-in-thread-pane to turn off, somehow. When I say "too erratic", I mean the feature, which (as I've described) is not displaying consistently.

I can't quite tell from the above, so not sure if you're aware, but I'm seeing a lot of cases where the wrong text is used. i.e. text from another msg in used as the preview. also, and I do know you're aware of this, is that having it in the same weight & colour as the subject makes it very hard to read just the subject. The screenshots show it is much more usable when the preview is of much lighter weight.

I would prefer to have a user option to view the subject or subject and snippet of body, as seperate columns, then on hover over each message subject to see the body of the message. Right now with the non-printing characters and the body, it is too much information for the space, especially in the clasic layout.

(In reply to comment #19) > I can't quite tell from the above, so not sure if you're aware, but I'm seeing > a lot of cases where the wrong text is used. i.e. text from another msg in used > as the preview. e.g. at the moment, for some msgs in my header pane, it is showing a preview of the *preceding* msg, for others it is correct, and for others still nothing is shown at all.

I think this is a misfeature. I would have classified it as major bug preventing me from using the mailer. If this is an opt-in feature, comment 20 would provide a nice UI without preference checkbox.

I realize you're only experimenting right now... so you want feedback, correct? :) 1. This should definitely be an opt-in feature. 2. The subject MUST be easily distinguished from the preview text (still work in progress, yes, but right now visually parsing it sucks). 3. I plan to disable this feature as soon as I know how... that said, I wouldn't mind keeping the tooltip preview, so I hope it's eventually configurable to keep one and not the other. And lest this comment sound too negative, I love this mail client. :)

Do not want to spam here, so I just post this link to forum about this "feature" and screenshout of bug not displaying subject at all. http://forums.mozillazine.org/viewtopic.php?p=2724695#2724695 Please make it optional. A message may contain some private information I would like noone can see just in mail window...

worth pursuing IMO. prefs: off, mouseover only, full-on?. ditto on needing to differentiate subject from body (which I realize unfortunately opens up a debate on style and fonts). otherwise I'll turn it off, too distracting/hard to scan/read subjects, though guessing it's not a big issue for people who use threaded view, which I rarely use (strict sort=date). rather see mouseover of extremely long lines be >=2 lines @shorter width

Just one further thing to note at this stage. I think the tooltip needs some sort of check that the threadpane is still foregrounded before firing. Because of the small delay, I've noticed that if I double-click on a message to open it, sometimes the tooltip pops up over the opened message.

Just because there is some space on a line does not mean the line should be filled. Filling up every line turns the message pane into a text page, making it difficult to scan the subjects. The pane's principal function - display the mail subjects - is lost. This "feature" is at best a nuisance. User should be able to opt out of it if it is retained.

(In reply to comment #28) > I think the tooltip needs some > sort of check that the threadpane is still foregrounded before firing. That's bug 334351. I think this is a systemwide problem with tooltips, not just limited to those from the 3-pane.

Please TURN THIS OFF until it is fixed. It is appending random **** from completely unrelated messages. It makes the message list impossible to use.

This is still happening in version 3 alpha 1 (20070227). It is still broken. The words it is tagging on to the end of the message subjects come from a *completely different message* (normally a spam message in my case), so the effect is that my message list, containing only legitimate messages, is full of references to viagra, cialis, porn, etc. from spam messages which I previously moved to my Junk folder. Please TURN THIS OFF until it is fixed.

(In reply to comment #33) > This is still happening in version 3 alpha 1 (20070227). > > It is still broken. The words it is tagging on to the end of the message > subjects come from a *completely different message* (normally a spam message in > my case), so the effect is that my message list, containing only legitimate > messages, is full of references to viagra, cialis, porn, etc. from spam > messages which I previously moved to my Junk folder. > > Please TURN THIS OFF until it is fixed. > While I do not see the mixup of texts from different messages in version 3 alpha 1 (20070228), I still regard this as a nuisance. Please make it optional.

*bump* on nuisance

If you have *details* to add about this feature, fine. But please stop "bumping" or adding "this is still happening" comments to this bug. Saying "me too!" doesn't solve the problem. If you want to express that this bug is important to you, add a "vote" to it, but please don't leave unhelpful comments that spam everyone else with e-mail (even the people who agree with you).

I am glad this bug/feature is already on the Bugzilla radar map. Attached is a chunk of TBird version 3.0a1 (20070430), that I think is the same thing as what you are describing... as best as I can tell. The subject+body behavior happens on a random basis. Email that had been received already PRIOR to installing TB3 can have this problem. So the message does not need to have been received with TB3. This problem has shown up on emails sent from: Microsoft Outlook Express 6.00.2900.3028 Thunderbird 1.5.0.4 Novell GroupWise Internet Agent 6.5.7 I realize that GMail has the described behavior... but if this is a feature the developers are keen on implementing, then DO put a check box to enable/disable the feature! ;-)

follow up to Michael Lueck, from IRC <mdlueck> ... I sent one email to several people, some of the responses do the behavior described, others do not... I also asked him to check the headers. <mdlueck> LOL, Thunderbird 1.5.0.4 and Novell GroupWise Internet Agent 6.5.7 did the annoying behavior, hotmail.com and Microsoft Exchange V6.5 did not!!! ;-)

I'm now seeing the attempt to decode Base64 for the preview text, but the preview is trying to display binary content. I have S/MIME messages which have some very bizarre previews.

I think we've experimented with this long enough and can back it out now until we decide what we want to do with it. At a minimum, we need to figure out a way to have the preview text be a different color from the subject. And more importantnly, we need to figure out why we are storing the wrong preview text for some messages.

Comment on attachment 266804 [details] [diff] [review] back out the preview test code I'm happy to try to figure out the wrong preview text problem - do you think we should just disable the code that appends the preview text?

This experimental feature was disabled as a checkin to Bug 379070 Just to let interested parties know.

Moin Moin. How about enabling the feature and(!!!) putting a "show preview texts" Button into the Taskbuttonbar along with a tooltipwarning that there may be confusing output from some "ill" formatted mailmessages. This way the users are capable to take advantage of the feature whilst knowing its drawbacks. If You want to keep the frontend's countenance clean, You might put an activationcheckbox into the Tools/Settings/General section that will have to be activated in order to show/display this experimental feature. _Tschuess, __Michael.

wanted‑thunderbird3-

Most of this is implemented in https://addons.mozilla.org/en-US/thunderbird/addon/gmail-conversation-view/

FYI Bug 441414 has been added to FossFactory.org and so far it is worth about $191. Feel free to donate to the project, if you would like to see this feature implemented. http://www.fossfactory.org/project/p294

@Ludovic, Conversation View only changes what happens in the preview pane. It doesn't update the thread pane.