Initially reported by Nomis101: > (quoting from bug 324495 comment #71) I enter a text > in the signature box and compose a new HTML message, but there is no signature > in the text field. There is also no signature if I reply to a message. > (quoting from bug 324495 comment #73) The current Mozilla/5.0 (Windows; U; > Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090307 Shredder/3.0b3pre nightly > works fine with either the pref or a file, whereas Mozilla/5.0 (Windows; U; > Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090307 Shredder/3.1a1pre nightly > shows the behavior described and does not add either text nor HTML signature > from either pref or even file when in HTML composition mode. It's not obvious > to me why there would be a difference between those branches, nsMsgCompose.cpp > is the same. On further investigation, selecting all content, then Insert > HTML does not show any encoding of the signature at all. Composing in plain-text mode works fine, so does HTML composition in comm-central/mozilla-1.9.1 builds. Regression window is unknown.

Yes, If you attach in 3.1a1pre a signature (HTML or text), its not inserted into a mail if you compose the mail in HTML mode. I have some Steps to reproduce: 1. Make sure "Compose messages in HTML mode" is checked in Composition&Addressing 2. Go to your account settings, check "Attach this signature" and choose an HTML- or text file with a signature text. Close the Account setting. 3. Click on the Write button to compose a message --> The signatur is not displayed 4. Go back to Composition&Addressing and uncheck "Compose messages in HTML mode", so you now compose messages in text mode. Close the Account setting. 5. Click on the Write button to compose a message --> Now you can see your signature Its only broken in 3.1a1pre, its not broken in mozilla-1.9.1

> 1. Make sure "Compose messages in HTML mode" is checked in > Composition&Addressing Same happens with Shift+Write, thus it's really a matter in which mode the composition window is opened and not just a mix-up of preference settings.

My oldest 3.1a1pre Mac build is from 22. February, and it also doesn't work with this build. So it seems the regression is older than 22. February.

Regression range: Works OK Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090220 Lightning/1.0pre Shredder/3.1a1pre ID:20090220085506 Broken in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090221 Lightning/1.0pre Shredder/3.1a1pre ID:20090221062734

Don't know how that happened Restored blocking.

Pushlogs for the regression range: http://hg.mozilla.org/comm-central/pushloghtml?startdate=2009-02-20&enddate=2009-02-21+07%3A00 http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2009-02-20&enddate=2009-02-21+07%3A00

Now, that the signature patch from Bug 324495 is officially in, I've tested this again. And now it seems to work for me. Can anybody confirm that this is now working? I've only tested this with the new UI, I've don't tested it with a siganture file.

That's indeed weird, I'm unable to reproduce this with the mozilla-central based nightly Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090415 Shredder/3.1a1pre now, regardless of whether I use the pref or attach a file. That would be an interesting fix... :-) I'm somewhat reluctant anyway to just close this WFM now, especially since you previously reported seeing the issue with a prior version of the bug 324495 patch applied, thus it may be one of those bugs which show up under certain conditions only. Some more testing may be advised before declaring this done.

I'm not seeing this anymore in 20090415 Shredder/3.1a1pre But I think we should leave it open for a while. After all, we haven't tested the condition: "When the moon is in the seventh house, and Jupiter aligns with Mars" :) I'll watch for a while. (maybe only to the sixth house of the moon)

(In reply to comment #8) > especially since you > previously reported seeing the issue with a prior version of the bug 324495 > patch applied Yes and no. At that time I tested this with a patched version (UI) AND with a (officially) unpatched version (signature file). For Comment #1 I used the officially version from the mozilla side. So it is unlikely that this issue was caused through your unfinished patch.

You should be able to verify yourself whether or not the recent checkin has anything to do with the disappearance of the issue. Assuming you have a build readily available for 3.1a1pre, just back out the patch and see if the problem reoccurs (what would it tell us though, other than that whatever produced the issue got at least hidden by it?). I also compared the logs of the files touched by bug 324495 with the regression range Joe figured, the only match for that being bug 476218, which modified nsMsgIdentity.cpp::getFolderPref() during this window. However, I don't see how the change there would relate to 1.9.2 and HTML editing mode / signatures.

(In reply to comment #11) > You should be able to verify yourself whether or not the recent checkin has > anything to do with the disappearance of the issue. Assuming you have a build > readily available for 3.1a1pre, just back out the patch and see if the problem > reoccurs OK, I backed out the patch (Bug 324495) from a fresh 3.1a1pre code and attached a signature file. And it still works, it doesn't reoccurs. I see the signature in every constellation. So I assume that a checkin into mozilla-central fixed this by chance. But if so, than it is likely that any other checkin could corrupt this again...

So, this was apparently a timing coincidence. You (or Joe) could try to find the "negative" regression window to identify in which build the problem disappeared and then correlate it with the bugs in comment #6, or we can just close this now or after some time and reopen if it strikes again - your call.

I had an eye on this for a few weeks now and in my recent 3.1a1pre build (20090513) this still works. So I think we can close this WFM now (and reopen if this will reoccur in the future). But I still don't now what has fixed this (couldn't find the "negative" regression window).

Agreed, the primary cause seems to have disappeared, whatever it was. -> WFM