This is just some static backup of the original site, don't expect every link to work!

Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#159 closed defect (fixed)

Signature does not change when virtual identity changes automatically

Reported by: Keith S. <mozkeith2@…> Owned by: rene
Version: 0.5.11 Keywords:
Cc:

Description

This is a small inconsistency related to signature switching. I realize this behavior may be changing in 0.6.0, but see below on that.

Suppose you have multiple email accounts #1, and #2. Each account has a different default signature. You have a virtual identity stored for recipient A, and it is tied to account #2.

Now suppose you are in account #1, and you hit Ctrl-M to compose a new message. As soon as you enter the recipient's name, the virtual identity will change. (This depends on how you have the options set up, but I think this is default behavior.) In this case, the signature will remain as is -- it will NOT change to the signature for account #2, the one associated with the stored virtual identity.

Now, if you go to the From bar, and change to the original identity, then back to the same virtual identity, it WILL change the signature.

Similarly, if you type Control-M to compose a new message, and select the virtual identity associated with recipient A BEFORE typing the recipient's name, this WILL also change the signature to use the one for the associated mail account.

Ideally, it should alter the signature when automatically choosing a virtual identity -- not just when doing it manually.

This reproduces in both 0.5.12 and 0.6.0pre4. However, I noticed that in 0.6.0, there was a note that changing the signature requires the Signature Switch extension. The details on that are a bit lacking, though, so it might be good if you could clarify here whether this issue basically is intended to go away (or at least be someone else's problem) in 0.6.0.

(FWIW, the Signature Switch extension does some things differently from VI 0.5 -- for example, it always puts the signature at the bottom of the message. This seems to be a big complaint on the TB addons site. That kind of makes this a regression, no?)

Cheers.

Change History (10)

comment:1 Changed 13 years ago by rene

Owner: set to rene
Status: newassigned

Hi,

there was a problem with the synchronisation if the (hidden) original Message-Identity dropdown menu. Therefore siganture switching and adaptation was broken too. Hopefully this is fixed as a sideeffect of the restored synchronization in 0.6.0pre6, please check this. Else I will investigate this issue further.

Nice regards, Rene

comment:2 Changed 13 years ago by Keith S. <mozkeith2@…>

Hi Rene,

I tried with 0.6.0pre6, and the behavior is the same, BUT I think I've tracked down the issue, and it appears to be data-related. There might be a bug somewhere, but I'm no longer in a state (at least with these records) to validate that.

Here is some more detail on two use cases. I selected the option "prefers Smart Reply identities", but otherwise everything was the default.

In mail account #1, I enter the name of recipient A on the To: line. It notifies me "using stored Virtual Identity as sender". It changes the From/Reply? to, and SMTP to that of mail account #2, however it did NOT change the base identity. Now I can see, this is why it didn't change the signature.

I tried again using another stored identity for recipient B -- same stored virtual ID settings, same base identity (account #2). With that recipient, it DID change the base identity, and thus the signature.

Now here's the weird thing: in the data storage editor, there IS a base identity defined for recipient A, but there is NOT a base identity defined for recipient B -- the opposite of what I would have expected.

I edited recipient A's stored data to remove the base identity, and add it back. After doing this, now the behavior is as expected.

Because I was able to reproduce this in 0.5.12, either there was some kind of data corruption/discrepancy (right title/wrong id sort of thing), or an issue with the data migration from 0.5 to 0.6. (Unfortunately, I didn't reproduce in 0.5 until after I'd downgraded again, so I can no longer say whether this was happening before the upgrade.)

Either way, I think you can close this issue now. If it happens again, I know to delete the base identity and add it again in the data storage editor, and that should fix it. Gotta say how cool it is that you provided that option.

comment:3 Changed 13 years ago by Keith S. <mozkeith2@…>

Resolution: fixed
Status: assignedclosed

comment:4 Changed 13 years ago by Keith S. <mozkeith2@…>

Resolution: fixed
Status: closedreopened

I found a backup of my pre-upgraded data, and am now looking at older versions. The problem does NOT reproduce on 0.5.12.

Is there a place to set the "default" base identity, when one is not specified for a stored identity? I think that might be the difference: where an identity is not specified, 0.5.12 is choosing the one I expect (that matches the From address), and 0.6.0 is not (it leaves it as is).

Or perhaps 0.6.0 is actually the correct behavior, and 0.5.12 was actually broken?

Thanks.

comment:5 Changed 13 years ago by rene

Hi Keith,

the behavior of virtual Identity changed from 0.5.12 to 0.6 in some fact's which might effect this issue, but I'm not aware of any causing this trouble. In both versions an undefined base identity should change nothing related to the pre-selected one. If you still able to reproduce this problem, please provide a debug-log from both cases (by email or search/replace your email addresses before posting here)

Nice regards, Rene

comment:6 Changed 13 years ago by Keith S. <mozkeith2@…>

This might be fixed in the latest pre-release. I know it wasn't happening all the time, so I'm still trying to find a use case where this still occurs. If I find one, I will post a debug log. Cheers.

comment:7 Changed 13 years ago by arthurNOSPAMizzy.net

I see the problem 100% of the time with TB 3.0 and VI 0.6.0rc1.

comment:8 Changed 13 years ago by rene

Resolution: fixed
Status: reopenedclosed

rc1 was buggy (see #181), please check if problem still exists in rc3 and reopen if necessary.

Nice regards, Rene

comment:9 Changed 13 years ago by Keith S. <mozkeith2@…>

Have not seen any recurrences of this issue. Whenever it happens now, I find it's because the base identity is blank.

comment:10 Changed 13 years ago by anonymous

decoration Changed 1 year ago by admin

bathtub Changed 1 year ago by admin

solar system Changed 1 year ago by admin

stair parts Changed 1 year ago by admin

solar supply Changed 1 year ago by admin

Note: See TracTickets for help on using tickets.