Thunderbird:Fix some longstanding bugs

The things that always bug me about TB are mostly bugs that have been around for a long time, back to early suite development, with little attention. In particular, I see a lot of mail composition bugs, especially around HTML and also format=flowed. Part of the problem, I assume, is that the editor code is all gnarly and nobody currently active on the project wants to get that deep into it.

These are some that I think really ought to be given attention:

Mail Editing bugs

Bug 180997: Embedded images (and other documents) in an HTML composition are simply discarded during the conversion to plain text; these should be turned into attachments. Even worse: embedding an image does not count as "HTML formatting" when determining whether to convert to plain text, so unless the user has performed one of the mystical ablutions to ensure the message going out as HTML, the image -- which may be the most important part of the message -- can be dropped without notice.

Bug 125928: HTML compose, converted to plain text for sending, is marked as format=flowed but is not processed like plain text is for f=f, resulting in badly formatted mail

Bug 155622 and Bug 220575: Plain Text compose: When you open a saved draft, or Edit <msg> As New (155622), or select Edit | Rewrap (220575), all the flow information is discarded, so the end of every visible line has a hard line break. Restoring all that information is tedious and error-prone.

Bug 187997: Rewrap doesn't work on selected (plain) text; it joins lines incorrectly and puts quote marks (>) in the middle of lines.

Bug 249082: Rewrap behavior in an HTML message is just wrong; it either does nothing to, or completely breaks, quoted text. (It has essentially no effect on the user text, which is as expected, and as it should work for plain text.)

Attachments & MIME bugs

Bug 65794: The default setting for an attachment's Content-Disposition is 'inline' (and there is no UI to change it). "very old, very annoying, gets lots of dupes, and is easily fixable. See also this mz thread."

Bug 147461 and bug 229075: The actual handling of Content-Disposition is inconsistent; types that Mozilla knows how to render (image/jpeg, text/plain) will be shown inline even with Content-Disposition set to 'attachment', and other attachments with Content-Disposition set to 'inline' are not shown inline. This latter problem can even suppress display of the message body itself (bug 182627).

Bug 76804: A plain text message with an HTML attachment shown inline will assume the coloration of the attachment.

Bug 244618: TB does not allow the user to define and edit MIME types and their associations to file extensions and programs, following the model implemented by Firefox. While Firefox can get away with this because it's only dealing with incoming files, TB can send files as attachments, and it would be nice if the users could configure the program to provide the correct MIME type when sending it out. This bug is a request-for-enhancement, but it's an enhancement that's sorely needed.

RFC822 Attachments and .EML files

There are numerous bugs opened about these items, with most symptoms seen in both the attached mail message and the saved mail file. Fixing these would not only make life easier for users—it would make life easier for testers!

An attached message can be opened in its own message window; however, doing so puts an error in the JavaScript console (bug 231282). All attachments of the "parent" message (including the forwarded message itself) are shown in that window's attachment panel (bug 203570). Obversely, if the attached message itself has attachments, those are shown in the attachment panel of its "parent" message (bug 35587).

A .EML file can be opened in its own message window (via the File|Open menu). That window does not display with a normal envelope panel, but instead is rendered as the Mozilla browser renders a .EML file (bug 241212). However, it is not possible to open the .EML file via a command line (bug 242959).
These two bugs have been fixed in time for TB 1.5. Yay!

For both the opened attachment and the opened .EML file:

• Most of the actions that you might want to perform on the message (Forward, Reply, Edit as New, View Source, Create Filter From Message) are disabled (or enabled but nonfunctional) (bug 204350, bug 241213 and their dependents).
• Display of the message's own attachments are not right (bug 174692 and bug 206278).
• It should be possible to file (import) the attachment or the .EML file directly into a mail folder (bug 11013 / bug 226877, bug 204612). In fact, if you try to "file" one of these attachments or files by opening it into its own message window and using the  Message | Copy To | folder  menu, the program gets into an unstable state that prevents normal message movement and other actions (bug 259522).

Filter bugs

I'm unaware of any actual serious bugs in filters, but there are quite a few RFEs that should be implemented:

Bug 129883: Filters should be shareable by multiple accounts. Bug 257979: When the Global Inbox is used for multiple accounts, it should be possible to specify filters that run on all mail or only for a particular account.

Both of those bugs might be better implemented per bug 267197: adding an account ID as a criterion field to the filter.

Bug 257990: Replace the current Junk Mail Controls menu item with pages in Options (for global junk settings) and Account Settings. (This is also mentioned in the suggested menu reorganization.)

Bug 202605: Expert users would benefit from presenting the junk filter a little more like regular filters. There are several bugs that address individual features for this, in particular:

• bug 196036 requests that Junk Status be a filter criterion.
• bug 198100 requests an option to change the execution precedence of junk controls compared to regular filters.

Both of the above depend on bug 223591, which requests that message be analyzed for junk on arrival, rather than after execution of filters. (There is a patch pending for this bug, unlikely to get into TB 1.5.)

Notification bugs

I don't know how much of the notification stuff is Core -- the Notification category in Bugzilla is listed under the Suite product, but these problems are all present in TB 1.0. Maybe the 'new items in account' and 'new items in folder' indications are going to change drastically as the filesystem converts to a database and all the folders become virtual, so these may be moot...

Bug 116181 and Bug 222068: The 'New' indicator on each mail account, and the system tray icon, do not automatically clear as expected during (after) reading messages that were filtered to a different account. Each account's 'New' indicator will only clear after some activity within the account, even all the new messages were filtered elsewhere. The tray icon will only clear when one account has its 'New' indicator cleared.

Those two bugs lead directly to this one:

Bug 210148: I want to get further notifications (slide-up and audible alert and, if necessary, a new tray icon) even when a previous notification has not been entirely cleared. This is filed as an enhancement (see the bug for a pointer to why), but there is a UI glitch associated with this as well: the tray icon will clear immediately upon reading the mail in one account, but if new mail has arrived in two accounts and only one has been read, subsequent new mail (via biff) will not trigger another notification

Bug 138095 and Bug 209752: The tooltip on the tray icon does not update as new mail arrives; only the count of the initial fetch for each account is shown, and if more than two accounts receive mail, not all accounts are shown in the tooltip.

---

[More to come...]

--mcow 09:14, 13 Mar 2005 (PST)