Comment 55 for bug 357864

Revision history for this message
In , Mozilla-steve (mozilla-steve) wrote :

For anyone that wants to hack a dirty solution based on just xul/js files, I
posted some modifications to
http://forums.mozillazine.org/viewtopic.php?t=12190&start=15 that adds a "From"
option to the "To, Cc, Bcc, etc) drop down list in the addressing pane. It
doesn't seem like a "production" solution because it doesn't prevent me from
having two "from" lines which generates a confusing from address. However, if
you only select one from address, the hack replaces the email address in the
current identity with the one in the from address and then replaces it after the
send message completes. This gives me the functionality that I was looking for
without having to wait for a real solution to this bug. The message shows up at
the recipient with my desired email address (that can be found/completed using
the address book) and yet otherwise behaves as with the original identity. That
is, it contains my name and organization as well as copies get saved and/or sent
as the fcc fields indicate.

I don't have the environment set up to make changes to C++ code and I'm not sure
 how all of the pieces fit together. However, maybe I can propose something
that will at least get solutions talked about for this bug again.

Add an attribute to nsIMsgCompFields.idl to support an alternate "from" email
address. It may be desireable to support alternate name and/or organization as
well. Modify nsMsgCompose.cpp to the alternate email (and/or name,
organization) instead of the one supplied in the passed identity if they are
supplied.

For the UI, I think adding "From" (and possibly name and organization) clutters
the popup menu as well as the addressingWidget. Maybe a popup dialog that
appears from a menu selection under options which would allow you to set the
desired "alternate" fields of nsIMsgCompFields would be a reasonable way of
handling it.

Feel free to try the hack and/or shoot down the above suggestion.