517593 - enigmail ends up adding funny mail headers to Tb3 header pane

Status: RESOLVED WORKSFORME

(Thunderbird :: Message Reader UI, defect)

Description

[John Beranek]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.4pre) Gecko/20090917 Lightning/1.0pre Shredder/3.0pre

As discussed on mozilla.dev.apps.thunderbird...

If you have a Tb2 profile where you've installed Enigmail and you upgrade to Tb3, you get the header pane showing funny headers for some messages. It turns out that this is because Enigmail has set the preference 'mailnews.headers.extraExpandedHeaders' to 'x-enigmail-version content-transfer-encoding openpgp x-mimeole x-bugzilla-reason x-php-bug'.

dmose has said:

It's consistent with my theory that Enigmail is adding them to the pref you mentioned because it needs them for a side-effect, and then doing something special to keep the headers from appearing.  If true, that implies that the hook that core is offering extension authors is indeed sub-optimal.


Reproducible: Always

Steps to Reproduce:
1.Make a clean profile
2.In Thunderbird 2, add Enigmail 0.96.0
3.Restart Tb2 to finish installation
4.Close Tb2
5.Start Tb3
6.Go to any message that has any of the headers shown in the details of this bug
Actual Results:  
The mail header pane shows what most users consider to be utterly pointless headers, like 'content-encoding' and 'x-bugzilla-cc'.


Expected Results:  
The mail header pane should not show pointless headers.

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

Yes, the hook is dumb.  The C++ header sink's attempt to save the UI from seeing headers that don't need to be displayed and the UI's dependence on this should be rectified.

Comment 2

[Dan Mosedale (:dmosedale, :dmose)]

While I agree that the libmime code is rotten for extensions, at the time it was done, it apparently won a non-trivial amount of performance back (it wasn't always that way).  Adding bienvenu, as perhaps he has thoughts here.

Really, though, we probably just need to re-profile, as the header has changed quite a bit since those days.

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

I think the more important thing is just stopping the UI from assuming that every header it is told about it wants to display.  Because I have a filter on a custom header, x-bugzilla-reason, every message I look at that includes that header displays it to me, even though I don't really want to see it.

In terms of performance, I think we already have the answer.  Gloda indexing on a box that was top-of-the-line-ish 2 years ago is able to stream and index 15 - 25 messages per second.  That includes both the mime emitter stuff and all of the indexing processing and a non-trivial amount of work involving pseudo-asynchronous database work.

Now, if the message header is doing anything that touches layout every time it sees a header, I could see how the performance would be disastrous.  But I trust we no longer do that if we ever did that.

Comment 4

[Maurits]

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4
this behaviour is also seen on a mac (so Not X86 vista specific)
with Enigmail 0.96.0 and also the nightly version of enigmail 0.97a 20090930

It is as describe in comment 1:)
mailnews.headers.extraExpandedHeaders  'x-enigmail-version
content-transfer-encoding openpgp x-mimeole x-bugzilla-reason x-php-bug'.
And the doing something special part: extensions.enigmail.hideHeaders  'x-enigmail-version openpgp content-transfer-encoding x-mimeole x-bugzilla-reason x-php-bug' not being honored.
I removed 'x-enigmail-version content-transfer-encoding' from the 1st string. and that seems to fix the most frequent occurences. (enigmail is still working)

Comment 5

[Patrick Brunschwig]

I can assure you that the content-transfer-encoding is required for Enigmail to work properly. It may not be needed for the messages you have decrypted, but this does not apply to all messages there are in the world.

Comment 7

[Jan Beyer]

On Debian GNU/Linux using Thunderbird (Icedove) 3.0.11, the problem persisted. Without having enigmail installed - probably it got lost during transition from TB2 to TB3 some time ago. But installing enigmail 1.0.1 now solved the problem - the spurious header line disappeared.

Comment 8

[Ludovic Hirlimann [:Usul]]

Why do we keep this bug open ?

Comment 9

[Wayne Mery (:wsmwk)]

(In reply to Ludovic Hirlimann [:Usul] Away until 3/9 from comment #8)
> Why do we keep this bug open ?

Patrick, do you know if this is still an issue?

Comment 10

[Patrick Brunschwig]

This was solved years ago. 

But it may actually re-appear with the next version of Enigmail if bug 1414518 will not be fixed in TB 59.