Can't enter diacritics in message compose window due to switching focus to an editor element via the keyboard

RESOLVED FIXED

Status

()

Core
Event Handling
RESOLVED FIXED
9 years ago
a year ago

People

(Reporter: davida, Assigned: Bienvenu)

Tracking

({regression})

Trunk
regression
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(status1.9.2 .7-fixed, status1.9.1 unaffected)

Details

(Whiteboard: [tb31needed][rc1/final fixed])

Attachments

(1 attachment, 3 obsolete attachments)

(Reporter)

Description

9 years ago
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?
Flags: blocking-thunderbird3.1?
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.
Status: NEW → UNCONFIRMED
Ever confirmed: false
Flags: blocking-thunderbird3.1?
Keywords: regression, regressionwindow-wanted
OS: All → Mac OS X
(Reporter)

Comment 2

9 years ago
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 ?

Comment 6

9 years ago
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.

Comment 8

9 years ago
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.
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...
Status: UNCONFIRMED → NEW
Ever confirmed: true
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...
Keywords: regressionwindow-wanted
(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
(Reporter)

Comment 18

8 years ago
Neil, any guesses?  (see comment #10)
Whiteboard: [see comment 10 for repro steps]

Comment 19

8 years ago
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 !
blocking-thunderbird3.1: --- → ?

Updated

8 years ago
blocking-thunderbird3.1: ? → rc1+

Comment 21

8 years ago
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.
Depends on: 544277
(Assignee)

Comment 23

8 years ago
taking to see if trunk patch in bug 544277 applies on 1.9.2, and if so, if it solves the problem.
Assignee: nobody → bienvenu
FYI: Only on mac, the deadkeys are processed by IME framework.
(Assignee)

Updated

8 years ago
Whiteboard: [see comment 10 for repro steps] → [1.9.3 moz-central fix patch doesn't apply - trying to backport]
(Assignee)

Comment 25

8 years ago
Created attachment 444489 [details] [diff] [review]
possible moz-central fix

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.
Attachment #444489 - Flags: feedback?(enndeakin)
(Assignee)

Updated

8 years ago
Whiteboard: [1.9.3 moz-central fix patch doesn't apply - trying to backport] → [feedback requested from enndeakin for possible moz-central patch]

Comment 26

8 years ago
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.
(Assignee)

Comment 27

8 years ago
Created attachment 444523 [details] [diff] [review]
minimal patch

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.
Attachment #444489 - Attachment is obsolete: true
Attachment #444523 - Flags: superreview?(bugzilla)
Attachment #444523 - Flags: review?(enndeakin)
Attachment #444489 - Flags: feedback?(enndeakin)
(Assignee)

Updated

8 years ago
Whiteboard: [feedback requested from enndeakin for possible moz-central patch] → [has patch for review]

Comment 28

8 years ago
Comment on attachment 444523 [details] [diff] [review]
minimal patch

I assume you didn't mean to remove the blank line.
Attachment #444523 - Flags: review?(enndeakin) → review+
(Assignee)

Comment 29

8 years ago
(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.
(Assignee)

Comment 30

8 years ago
Created attachment 444757 [details] [diff] [review]
fix blank lines

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.
Attachment #444523 - Attachment is obsolete: true
Attachment #444757 - Flags: superreview?(bugzilla)
Attachment #444757 - Flags: review+
Attachment #444523 - Flags: superreview?(bugzilla)
(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.
blocking-thunderbird3.1: rc1+ → ---
Component: Message Compose Window → Event Handling
Product: Thunderbird → Core
QA Contact: message-compose → events
Summary: Can't enter diacritics → Can't enter diacritics in message compose window due to switching focus to an editor element via the keyboard
Whiteboard: [has patch for review] → [tb31needs][has patch for review]
Created attachment 444869 [details] [diff] [review]
Patch with unit test changes from bug 544277

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+.
Attachment #444757 - Attachment is obsolete: true
Attachment #444869 - Flags: superreview?(bugzilla)
Attachment #444869 - Flags: review+
Attachment #444757 - Flags: superreview?(bugzilla)
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.
Attachment #444869 - Flags: superreview?(bugzilla)
Attachment #444869 - Flags: superreview+
Attachment #444869 - Flags: approval1.9.2.5?
Whiteboard: [tb31needs][has patch for review] → [tb31needs][rc1/final fixed][needs approval 1.9.2.5 for TB 3.1.1]

Updated

8 years ago
Blocks: 541042

Comment 34

8 years ago
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.
Attachment #444869 - Flags: approval1.9.2.5? → approval1.9.2.6+
Checked in: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/7c3523614fb1
Status: NEW → RESOLVED
Last Resolved: 8 years ago
status1.9.2: --- → .6-fixed
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [tb31needs][rc1/final fixed][needs approval 1.9.2.5 for TB 3.1.1] → [tb31needs][rc1/final fixed]
Whiteboard: [tb31needs][rc1/final fixed] → [tb31needed][rc1/final fixed]

Updated

8 years ago
Duplicate of this bug: 541042
Duplicate of this bug: 571663

Updated

8 years ago
status1.9.1: --- → unaffected
You need to log in before you can comment on or make changes to this bug.