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
Fixed for TB 3.0  HOORAY!  

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.</span>
155622 fixed for TB 3.0  HOORAY!  

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 and bug 452092: 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." This default has been changed in bug 65794 to 'attachment', which still doesn't appear to be the optimal solution since neither default is good for all MIME types and in all situations. Comments in the spin-off bug 452092 are about to which attachments the default content disposition should be applied (not for all MIME types an 'inline' disposition makes sense), and how a user could specify the disposition type while attaching.

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.

Bug 307023: Attributes of HTML messages received in quoted-printable or other complex Content Transfer Encodings may get corrupted when the message is re-edited (e.g., forwarded, potentially replied to, or opening own messages after saving them as draft). This causes substantial problems, such as loss of images embedded in the HTML, which cannot be explained by the average user.

Bug 120679: Thunderbird overrides the user's / admin's configured umask on UNIX systems. Multi-user sites need to control the umask for file/directory creation so one user can, if their account is configured for it, create files that other users can modify. Thunderbird overrides the user's settings when (a) creating directories and (b) saving attachments. I currently have to patch this locally.

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)Fixed for TB 2.0. 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; showing all the attachments is considered a feature, but there is no visible means to distinguish which message contains which attachment (bug 35587).

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).For .EML files, most of the useful functions were available as of TB 1.5; for RFC822 attachments, these functions are available with TB 2.0. Some useful functions, mostly from the View menu, are still unimplemented.
• Display of the message's own attachments are not right (bug 206278)Fixed for TB 2.0
• It should be possible to file (import) the attachment or the .EML file directly into a mail folder (bug 11013 / bug 226877, bug 204612). The menu action  Message | Copy To | folder  would be an elegant way to implement this.
  For a .EML file, the Copy menu is enabled, but does nothing (the Move menu is disabled). However, for an RFC822 attachment, both menus are enabled, and an attempt to file the attachment using them puts the program into an unstable state that prevents normal message movement and other actions (bug 259522).

Semicolon-separated address lists

Microsoft's mail handlers have both accepted and encouraged the use of semicolon-separated address lists, in direct contradiction of RFC 2822. While Mozilla's support for the accepted use of the semicolon (named address groups) is lacking, that usage is not at all widespread. On the other hand, there are plenty of mailto: links in the wild which specify a list of addresses separated with semicolon, and messages that arrive from Outlook users with address lists separated by semicolons; Mozilla's behavior with these is clearly broken.

Bug 242693: Smarter handling of a typed-in semicolon-separated address list. While we would prefer users not enter semicolons at all, the list is not flagged as erroroneous and TB attempts to send, but misparses the list badly, resulting in errors when sending.

Bug 210521: Smarter handling of semicolon-separated address lists using Reply All. In this case, the address list is grossly misparsed, filling in the address fields on the CC: list of the new message with a long, illegal string.

Bug 258653: Smarter handling of semicolon-separated address lists in a mailto: link. Similar results to the above bug.

Internationalization bugs

Bug 254519: Incorrect RFC 2047 encoding and decoding. This is one of the most-duped bugs in the mail domain. When replying to a message with an RFC2047-compliant header that happens to contain a comma in the name --e.g. Müller, Wolfgang -- the comma is interpreted as an address separator, and the reply goes to two different recipients, Müller and Wolfgang (and the actual mail address is only supplied to the second). A MIME-encoded name field is supposed to be treated as an atom; special characters contained within are to be treated literally.

Search and Filter bugs

The match operators "doesn't contain" and "isn't" aren't available in a number of different situations:

• Bug 146676: for any header in Search Messages for News.

• Bug 238816: for custom headers in MailView and Search Messages (POP and IMAP).

• Bug 242550: for custom headers in Filters for IMAP.

In addition: Bug 319831: All non-custom text headers in Search Messages for IMAP only have "contains" and "doesn't contain".

Bug 187768: Recipient fields (To, CC, "To or CC") don't have "is/isn't in my address book"
Fixed for TB 3.0

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.) Fixed for TB 2.0

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 2.0.)

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)