Not sure if it's a mac only bug or not, but: Start new mail, and in body area, type option-e, e (which generates an é in e.g. the subject field), and it just generates a plain e. Likely midas bug?

Changing to Mac only, as that's all we're sure of at this point. I can't reproduce this using the 3.1a1RC1 build on Mac, when I type option-e, I see this character: ´ Setting to UNCONFIRMED at the moment for that reason. I suspect that David has some sort of OS X system preference related to international keyboard layouts set. David, is that the case? I've CCed _Tsk_ hoping for help on the regression / regressionwindow-wanted stuff. _Tsk_, is a CC like this actually necessary, or do you have some other mechanism in place (eg a bugzilla whine) to keep you apprised of new bugs with those keywords? Assuming this bug does get confirmed as happening 100% of the time (_Tsk_, I bet you have keyboard settings similar to davida, perhaps you're a good person to do this?), I think it should be marked as blocking 3.1 beta 1.

fyi, i'm using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2pre) Gecko/20100121 Lanikai/3.1b1pre dmose, if you type option-e you should see ´ with an underline and then if you then type 'e' the two chars will combine to form an é. So it sounds like you're seeing the right behavior. I don't think keyboard layouts are relevant here. (I use an en-US keyboard layout). My build is a few days old, maybe it'll go away w/ the next nightly.

Ah, indeed, it is working right for me in 3.1a1RC1 which was built longer ago than the builds you have. Perhaps this is a more recent regression...

Works for me on Mac OS X 10.6.2. src-central - c539ad59cb6c, and (just gotten) 00eb70fa04c4. mozilla-central - ffab97de1041 and (just gotten) a8810d63a74a. Works on both new message and replys. Works on both html and plain text. Hope this helps narrow down the problem space.

(In reply to comment #1) > I've CCed _Tsk_ hoping for help on the regression / regressionwindow-wanted > stuff. _Tsk_, is a CC like this actually necessary, or do you have some other > mechanism in place (eg a bugzilla whine) to keep you apprised of new bugs with > those keywords? Thqt4s good; I don4t use Whines as I read all incoming bugmail ( with a few exceptions of resolved threads) > Assuming this bug does get confirmed as happening 100% of the time (_Tsk_, I > bet you have keyboard settings similar to davida, perhaps you're a good person > to do this?), I think it should be marked as blocking 3.1 beta 1. so for me with french keyboard layout : I get a nice ê while pressing alt-e, If I switch to non French keyboard (in the menu bar) I get a nice é. David do you have the issue in -safe-mode too ?

diacritic / accent bugs with recent activity http://bit.ly/bxxNDA

I experienced the same issue in the mail compose window in Thunderbird 3.1beta1 on Ubuntu Hardy. One-stroke accented keys are fine: using my French keyboard, I can write things such as é or à using one stroke. However, if I need to write û for instance, I need to hit the "^" dead key and then "u" key. I Thunderbird 3.1beta1, I get just "u" instead of "û". This happened the first few times I launched beta1. After I restarted Thunderbird two or three times, the problem went away but I thought I'd mention it.

is message compose they only place where this is a problem? what about address book, search, etc?

Only in the message compose window. It's very random and usually disappears after a few minutes. I get the feeling it's related to spellcheck somehow. The last time I was able to reproduce the bug (by luck) the "Spell" item from the compose window toolbar was greyed out. I was unable to type ê when suddenly there was some kind of a "reflow" in spellcheck: the red wavelets under some words went away and I was able to immediately type ê after that. It's very vague and random, I'll try to put more information here as soon as I'm able to determine more precisely the root cause.

Ok I finally managed to narrow it down. Steps to reproduce: 1. Ctrl-N to open a new compose window 2. Set the sender using keyboard only 3. Use tab to jump to the subject then to the body compose area Results: The "Spell" button in the compose toolbar is grayed out and I can't enter ê. If I click using the mouse in the body compose area, then the "Spell" button becomes normal and I can enter whichever â ô û I want. This happens again if I move using the mouse to the subject then use tab to move to the body compose area.

Jonathan, davida, does this work correctly in an earlier release? ftp://ftp.mozilla.org/pub/thunderbird/releases/ I'd say a 50-50 chance something related is already reported but nothing pops out for me from this query https://bugzilla.mozilla.org/buglist.cgi?type1-0-0=anywordssubstr&field0-0-0=short_desc&bug_severity=major&bug_severity=normal&bug_severity=minor&resolution=---&classification=Client%20Software&classification=Components&query_format=advanced&longdesc=click%20spell&type0-0-0=anywordssubstr&value0-0-0=click%20spell&component=Composition&component=Message%20Compose%20Window&component=Spelling%20checker&field1-0-0=short_desc&product=Core&product=MailNews%20Core&product=Thunderbird&longdesc_type=allwordssubstr

Was working fine with 3.0.3. I'll test with 3.1a1 tomorrow.

Working fine in latest-comm1.9.1 (3.0.5pre). Not working in Lanikai alpha1 on an up-to-date Debian testing. Same behaviour (need to gain focus in the compose area using the mouse to be able to enter diacritics).

CONFIRMing, since more than one person has seen this. Jonathan, any chance you could do a binary search of nightly builds in order to figure out exactly when this regression was introduced? That could allow us to find the code change that did it...

Last good nightly: 2009-06-10 First bad nightly: 2009-06-11 Pushlog: http://hg.mozilla.org/comm-central/pushloghtml?fromchange=f1fcff5eb061&tochange=6c5a94b9bba2 (I ran mozregression twice to make sure I wasn't mistaken). I don't have a clue as to why might have caused this. The GTk version looks the same... (I first thought it was linked to that). Feel free to ask for more tests if you need to.

Thanks much for tracking down when this happened! I think this is much more likely to be a regression in Gecko than in Tb itself, which means that the mozilla-central pushlog is likely where the real changeset culprit is...

(In reply to comment #16) > Thanks much for tracking down when this happened! I think this is much more > likely to be a regression in Gecko than in Tb itself, which means that the > mozilla-central pushlog is likely where the real changeset culprit is... http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2009-06-10&enddate=2009-06-11 Possible culprit : Bug 397986 Bug 178324

Neil, any guesses? (see comment #10)

Same bug here using Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a5pre) Gecko/20100413 Shredder/3.2a1pre. In the same computer, running Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9pre) Gecko/20100203 Shredder/3.0.2pre everything is working OK! New Mail, tab to get to the body part and start writing: no diacritics. If I type the acute sign, and then the e, it appears the normal e, not the é. If I type the ñ which is a single letter on my keyboard, it appears ok. If I click on the body with the mouse, I can start typing any character, everything works fine.

(In reply to comment #18) > Neil, any guesses? (see comment #10) Neil Ping !

I don't see this bug in current builds, although I did see it in an older build I found lying around. It may have been fixed by the recently checked in bug 544277. Bug 542060 looks to be the same problem.

(In reply to comment #21) > I don't see this bug in current builds, although I did see it in an older build > I found lying around. It may have been fixed by the recently checked in bug > 544277. Bug 542060 looks to be the same problem. I've tested a couple of nightlies either side, and it looks like that is the situation. If anyone can try either side of the specific changesets mentioned in bug 544277 that would be useful to help us know for sure.

taking to see if trunk patch in bug 544277 applies on 1.9.2, and if so, if it solves the problem.

FYI: Only on mac, the deadkeys are processed by IME framework.

Neil, is it crazy for us to try to backport this patch to 1.9.2 to fix this issue for Thunderbird? I had to get around the fact that 1.9.2 doesn't have GetPrimaryFrame, but the patch does seem to fix the bug. If it's crazy, is there a less crazy subset or approach we could try for tb 3.1 w/ 1.9.2? Thx for any insight you can provide.

Comment on attachment 444489 [details] [diff] [review] possible moz-central fix nsIMEStateManager::OnTextStateFocus(presContext, aContent); >+ } else { >+ nsPresContext* presContext = presShell->GetPresContext(); >+ nsIMEStateManager::OnTextStateBlur(presContext, nsnull); >+ nsIMEStateManager::OnChangeFocus(presContext, nsnull); >+ if (!aWindowRaised) { >+ aWindow->UpdateCommands(NS_LITERAL_STRING("focus")); >+ } These few lines may be the only change you actually need to fix this bug. If not, I can look at the patch in more detail and see.

yes, thx much, this much smaller patch also fixes it. So, we might land this on our own branch, but it would be nice to get it into 1.9.2, if that's an option.

Comment on attachment 444523 [details] [diff] [review] minimal patch I assume you didn't mean to remove the blank line.

(In reply to comment #28) > (From update of attachment 444523 [details] [diff] [review]) > I assume you didn't mean to remove the blank line. no and yes :-) but mainly no. I had to patch the file by hand, and x-code likes to muck with the formatting so much that I lost track of what the code looked like before. I'll attach a diff w/ the blank line restored.

Carrying forward Neil's review, requesting sr. Standard8, which version of 1.9.2 are we shipping 3.1 with? I assume it's worth asking for 1.9.2 approval.

(In reply to comment #30) > Carrying forward Neil's review, requesting sr. Standard8, which version of > 1.9.2 are we shipping 3.1 with? I assume it's worth asking for 1.9.2 approval. So I'm currently planning 1.9.2.4, and given their current issues there, I'm proposing that we land this on a relbranch. However, we should still get it into 1.9.2, so 1.9.2.5 would be the next one there. I'm moving this into a core component where we can get approval and FF can track landing.

This patch includes the test changes from bug 544277 attachment 440226 [details] [diff] [review] - those are needed to keep the mochitests passing on 1.9.2 and help to verify this fix. I've pushed this to try server, and assuming it passes, then it'll be sr+.

Comment on attachment 444869 [details] [diff] [review] Patch with unit test changes from bug 544277 Ok, try server builds were clear. Requesting approval for 1.9.2: This patch is a subset of what was landed on trunk in bug 544277. Thunderbird needs this to fix various issues with the compose window when using the keyboard to go to the message body editor. These are focus issues that are regressions from 1.9.1.

Comment on attachment 444869 [details] [diff] [review] Patch with unit test changes from bug 544277 a=LegNeato for 1.9.2.6. Please land this on mozilla-1.9.2 default.

Checked in: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/7c3523614fb1