If I have several mail account and check mail on one of them and then press CTRL+M for a new message the From address is set to identity of the current mail account. But if I press on a mailto link is a message of the mail account or use the "Send Mail to" in the header of a mail, the From address is set to the first mail account. Expected: Starting compose in anyway when you're inside a specific mail account should set the From address to the identity of the current mail account.

change qa contact to myself

nominating this bug for nsbeta1-The context menu item "send mail to" in the envelope area of the message should behave the same as new message, where the from field gets filled with the current mail account and not the default.

Scott or Jean-Francois, Do we have the ability to get the correct identity from within the message pane or message headers? I'm not sure how far the sandbox extends and if it prevents us from getting access to the selected identity.

I don't know...

marking nsbeta1-

-->varada

What's the internal difference between hitting CTRL+M (which chooses the correct sender) and right clicking on mailaddress and saying compose mail to (which doesn't select the correct sender)

taking all of varada's bugs.

This bug also applies, when left-clicking on an email address within a message. I assume that it's the same bug.

As noted in bug 81281, the symptom of the wrong identity used when a compose window is opened using the "Compose Mail To" item (in the context menu for an envelope-header email address) has been fixed. (I haven't been able to find the bug which contained the fix for this; but I think it must have been fixed before bug 167815 was filed.) The symptom of the wrong identity used when a compose window is opened by clicking on an email address in the message body is still valid. Note that it's true both for mailto: links in HTML and linkified mailto's and email addresses in plain text.

*** Bug 221861 has been marked as a duplicate of this bug. ***

*** Bug 262063 has been marked as a duplicate of this bug. ***

*** Bug 296669 has been marked as a duplicate of this bug. ***

*** Bug 194809 has been marked as a duplicate of this bug. ***

*** Bug 303619 has been marked as a duplicate of this bug. ***

Can we get this changed to a Thunderbird bug so Thunderbird can be fixed? I have verified that this happening in Thunderbird.

(In reply to comment #16) > Can we get this changed to a Thunderbird bug so Thunderbird can be fixed? I have > verified that this happening in Thunderbird. This bug is assigned to "Core" which is the backend code, shared by Thunderbird and Seamonkey.

*** Bug 346698 has been marked as a duplicate of this bug. ***

An extension has been written called "Corrtect Identity" which corrects this https://addons.mozilla.org/thunderbird/1203/ However, this shouldn't rely on a user installing an extension. It was reported in ealier versions and fixed, so why has it re-appeared now? See bug 81281

(upgrade summary)

Taking, since I have a (currently very messy) patch for this.

In a way, I feel a little bad about this, since (according to jcranmer) nsMsgComposeContentHandler.cpp has been essentially unchanged since it was first checked in to CVS, but here's a patch to fix this. Note that it doesn't technically do what the bug title says, since no other part of Thunderbird does that either. Instead, this uses the first identity for the server associated with the nsIMsgDBHdr, like everything else does. That should probably be fixed one day, but for now, I think we should aim for consistency. :bienvenu, I'm not sure what we should do here for tests, as this isn't an area I'm very familiar with (I expect Firefox/Toolkit has some tests for things like this, but I'm not sure where to look). One thing in particular that I didn't test was opening mailto: urls from another application, since apparently Ubuntu 11.04 decided that users were too stupid to be allowed to input a custom command for the mailto: handler.

Comment on attachment 543575 [details] [diff] [review] Fix this (no tests) I'm not sure that you should error out instead of just falling through to the OpenComposeWindowWithURI call (e.g., if you can't get a msg hdr). I'm not sure in what situations this code gets called. Would it get called from clicking on a mailto link in a content tab, or in Seamonkey by clicking on a mailto link in a web page?

(In reply to comment #29) > I'm not sure that you should error out instead of just falling through to > the OpenComposeWindowWithURI call (e.g., if you can't get a msg hdr). I'm > not sure in what situations this code gets called. Would it get called from > clicking on a mailto link in a content tab, or in Seamonkey by clicking on a > mailto link in a web page? Ah, right. I actually meant to do like you said, but I forgot about it halfway through as I was trying to figure out how to get at the message header. I tested this patch with content tabs with mailto: links and everything seems ok.

Comment on attachment 543832 [details] [diff] [review] Don't bail out when we can't get an identity r=me, with some nits: mmm, delicious, brined compose window :-) I know you just moved this text, but please fix the typo + * own chrome url you want to use in brining up a + * compose window, pass it in here. I think GetMessageHeader should fail if msgHdr is null, so NS_ENSURE_SUCCESS(rv, rv) should be sufficient. + rv = msgURI->GetMessageHeader(getter_AddRefs(msgHdr)); + NS_ENSURE_SUCCESS(rv,rv); + if (!msgHdr) + return NS_ERROR_FAILURE; Should pass in &rv here, and add an NS_ENSURE_SUCCESS(rv, rv) after. + nsCOMPtr<nsIMsgAccountManager> accountManager = do_GetService( + NS_MSGACCOUNTMANAGER_CONTRACTID);

Comment on attachment 543832 [details] [diff] [review] Don't bail out when we can't get an identity Requesting approval for aurora. It might be too late for 6.0 though...

Comment on attachment 543832 [details] [diff] [review] Don't bail out when we can't get an identity I suppose I should get sr on this as well, since I changed an API. :)

Comment on attachment 543832 [details] [diff] [review] Don't bail out when we can't get an identity >-NS_IMETHODIMP nsMsgComposeContentHandler::HandleContent(const char * aContentType, >- nsIInterfaceRequestor* aWindowContext, nsIRequest *request) You didn't really have to reformat this... but I guess you could use > NS_IMETHODIMP > nsMsgComposeContentHandler::HandleContent(const char * aContentType, > nsIInterfaceRequestor* aWindowContext, > nsIRequest *request) I don't really like your style of wrapping though. >+ nsCOMPtr<nsIDOMWindow> window = do_GetInterface(aWindowContext); >+ if (!window) >+ return NS_ERROR_FAILURE; >+ >+ nsCOMPtr<nsIDOMDocument> document; >+ window->GetDocument(getter_AddRefs(document)); >+ nsAutoString documentURIString; >+ document->GetDocumentURI(documentURIString); This does seem a bit of a long-winded route but I'd have to ask bz what the most recommended way to get the referring URL is. >+ nsCOMPtr<nsIIOService> ioService = do_GetIOService(&rv); >+ nsCOMPtr<nsIURI> documentURI; >+ rv = ioService->NewURI(NS_ConvertUTF16toUTF8(documentURIString), >+ nsnull, nsnull, getter_AddRefs(documentURI)); NS_NewURI(getter_AddRefs(documentURI), documentURIString); >+ NS_ENSURE_SUCCESS(rv,rv); Nit: space after comma >+ NS_ENSURE_SUCCESS(rv,rv); >+ if (!msgHdr) >+ return NS_ERROR_FAILURE; [Do you really need both checks?]

Comment on attachment 543832 [details] [diff] [review] Don't bail out when we can't get an identity >+ nsCOMPtr<nsIDOMWindow> window = do_GetInterface(aWindowContext); >+ if (!window) >+ return NS_ERROR_FAILURE; >+ >+ nsCOMPtr<nsIDOMDocument> document; >+ window->GetDocument(getter_AddRefs(document)); >+ nsAutoString documentURIString; >+ document->GetDocumentURI(documentURIString); Looks like bz approves this, so sr=me with my other changes fixed.

Checked in with nits fixed: http://hg.mozilla.org/comm-central/rev/b65e94778dbd

Bustage fix for .eml messages: http://hg.mozilla.org/comm-central/rev/a6bdbe78f1f7

In this context I like to share, that TB's Help points to a pretty useless site: http://support.mozillamessaging.com/en-US/kb/configuration-options-accounts. Nowhere I can find what "Set the default email account" really effects besides the fact, that the concerning account is shifted to the top position in the left pane of TB's main window.

Has there been a reintroduction of whatever caused this bug originally - it is not working for me now: Windows 7 64bit ; TB 18.0 (also on Daily) I will check an older version to see if i can isolate when it was introduced...in the meantime perhaps it needs to be reopened?

I have now tried on TB rel 17 and I think I understand why it wasn't apparent before. I have moved the default outgoing email in the account list from the top to the bottom in the left hand side of the dialog for account settings. This happened because I needed to change the account type to IMAP and so needed to delete and re-add it. So basically it seems that unless the account is at the top of the list, setting the outgoing to default makes no difference

I just experienced this problem with 31.3.0 The link that caused it: <div><b>From:</b> "Tudor, Charles" &lt;<a moz-do-not-send="true" href="mailto:example@example.com" target="_blank">example@example.com</a>&gt;<br>