Mozilla Thunderbird

Bug #52667
Comment #65

Comment 65 for bug 52667

Revision history for this message

In Mozilla Bugzilla #45715, Pcmccurdy (pcmccurdy) wrote on 2006-03-03:

#65

Created an attachment (id=213877)
Adds a Reply-To-List reply mode

This has been driving me crazy for a while, so I've decided to fix it.

As described in comment #8, I've implemented another reply mode. After having read over the bug, it's clear that there are enough different, incompatible opinions on how to do the UI that the only sensible thing to do is make this accessible to extensions, so people can pick their favourite of the mutually-exclusive-yet-still-valid options. The only sensible way to do this that I can see is an extra reply mode.

In fact, my current patch doesn't even implement any UI; for now, I'm just going to add my personally preferred UI in an extension (I want a third UI button and a separate shortcut key, for the record). So to test this, I guess you should hack up the "MsgReplyToAllMessage" function in mailWindowOverlay.js to do a "msgComposeType.ReplyToList" instead of a "msgComposeType.ReplyAll". Or I'll try to get my extension finished up soon, but I might not have time to get to it until Wednesday. The patch should be straight forward though.

A default UI might make sense, as long as extensions can override it, but I wanted to get some comments on what I've got done so far. I also explicitly wanted to avoid any discussions on potential UIs for now - it'd be better to at least get the basic functionality checked in so extensions can play with it, even if Thunderbird doesn't ship with a UI right away.

My solution to getting at the content of exotic headers (as hinted in comment #8) is to get rid of the "optimization" that only sent certain headers out to JavaScript unless the "View All Headers" option was set. When I was first trying to do this as a plain extension, it struck me as incredibly annoying that extensions couldn't get at this data. Perhaps I'm just being naive, but IMHO a mail client that's designed to be extensible should be sure to give this sort of data to extensions. Several extensions (Mnenhy, Enigmail, Display Mail Route, Display Mailing List Header, possibly others) have needed this, and have had to hack around it in one way or another; I can only imagine how many people tried to do interesting things and couldn't because the headers were too hard to get to.

This is my first Mozilla patch, so even though I tried to get it right, I'm sure there are some obvious braindead things littered through my changes. Feel free to point them out, I won't take offense and I really want to get this fixed right. In particular, I had to change an interface in IDL, and I don't know what other changes that implies. Please bear with me if I did something dumb.

Created an attachment (id=213877)
Adds a Reply-To-List reply mode

This has been driving me crazy for a while, so I've decided to fix it.

As described in comment #8, I've implemented another reply mode.  After having read over the bug, it's clear that there are enough different, incompatible opinions on how to do the UI that the only sensible thing to do is make this accessible to extensions, so people can pick their favourite of the mutually-exclusive-yet-still-valid options.  The only sensible way to do this that I can see is an extra reply mode.

In fact, my current patch doesn't even implement any UI; for now, I'm just going to add my personally preferred UI in an extension (I want a third UI button and a separate shortcut key, for the record).  So to test this, I guess you should hack up the "MsgReplyToAllMessage" function in mailWindowOverlay.js to do a "msgComposeType.ReplyToList" instead of a "msgComposeType.ReplyAll".  Or I'll try to get my extension finished up soon, but I might not have time to get to it until Wednesday.  The patch should be straight forward though.

A default UI might make sense, as long as extensions can override it, but I wanted to get some comments on what I've got done so far.  I also explicitly wanted to avoid any discussions on potential UIs for now - it'd be better to at least get the basic functionality checked in so extensions can play with it, even if Thunderbird doesn't ship with a UI right away.

My solution to getting at the content of exotic headers (as hinted in comment #8) is to get rid of the "optimization" that only sent certain headers out to JavaScript unless the "View All Headers" option was set.  When I was first trying to do this as a plain extension, it struck me as incredibly annoying that extensions couldn't get at this data.  Perhaps I'm just being naive, but IMHO a mail client that's designed to be extensible should be sure to give this sort of data to extensions.  Several extensions (Mnenhy, Enigmail, Display Mail Route, Display Mailing List Header, possibly others) have needed this, and have had to hack around it in one way or another; I can only imagine how many people tried to do interesting things and couldn't because the headers were too hard to get to.

This is my first Mozilla patch, so even though I tried to get it right, I'm sure there are some obvious braindead things littered through my changes.  Feel free to point them out, I won't take offense and I really want to get this fixed right.  In particular, I had to change an interface in IDL, and I don't know what other changes that implies.  Please bear with me if I did something dumb.