22205 - When inserting ALT+ num key characters into existing text, the cursor moves erratically

Status: VERIFIED DUPLICATE of bug 22206

(MailNews Core :: Composition, defect, P3)

Description

[marina]

Steps to reproduce:
-select a message;
-click reply;
-enter some text and continue to enter non-ascii chars using ALT+ 0233;
-now note:
input jumps two lines down after iqatest1 wrote: and inserts there

Comment 1

[Phil Peterson]

Reassign to beppe

Comment 2

[rubydoo123]

assigning to jfrancis and cc ftang

Comment 3

[rubydoo123]

assigning to jfrancis and cc ftang

Comment 4

[Katsuhiko Momoi]

See also a related Bug 22206.

Comment 5

[Kathleen :Brade]

reassign to myself to do some preliminary investigation for jfrancis

Comment 6

[Kathleen :Brade]

I think Joe has fixed this as part of his caret fixes recently.
This now works for me testing on a build from today.

Comment 7

[marina]

I'm reopening because Alt+Num operation still is not working as it should so the 
focus is lost when entering non-ascii chars and input jumps tending to start new 
line every time you use Alt+ NUM key

Comment 8

[Kathleen :Brade]

reassign to jfrancis; cc mjudge 
This might have something to do with what happens when right-arrowing at the end 
of the edit buffer (?)  Who has that bug?

Comment 9

[marina]

I would think this bug should be fixed for Beta 1, it is a really annoying 
problem and should be on PDT + radar. Kat, Lisa?

Comment 10

[Katsuhiko Momoi]

Yes, I agree that this is a bad problem.
This seems to be a general editor problem and not restrcited to just reply mail.
Essentially, I see the following problem:

1. Say you have a line like "This is an editing practic." repeated several times in your Composer
   document:

   This is an editing practice
   This is an editing practice
   This is an editing practice
   This is an editing practice

2. Now insert the cursor into somewhere in the second line.
3. Use ALT+NUMPad to input a character (e.g. ALT+0231, ALT+0235, etc.)
4. As you enter characters see where the cursor is jumping to. The behavior is
   very erratic.

Note: If you are not inserting into a middle of existing lines with ALT+NUMPad, you don't see
        this kind of problem. On a clean Editor canvas, you will see only the problem described in
        Bug 22206, which is already marked for beta1.

Could this be something we can resolve when Bug 22206 is resolved? If so, we can resolve this to be
a duplicate of that bug. 
    

Comment 11

[Katsuhiko Momoi]

And of course, the reason this is critical for reply mail is that reply is normally
guaranteed to have existing lines quoted from the original mail.

Comment 12

[leger]

Putting on PDT+ radar for beta1.

Comment 13

[kinmoz]

This should probably be assigned to someone dealing with XUL keybindings.

The problem only occurs when the numlock key is not down. The '2', '4', '6', and 
'8' keys, on the num pad, act as arrow keys when the numlock key is not down.

What's happening here is that the XUL bindings for the arrow keys are getting 
triggered, even though the ALT key is down. The bindings need to be modified so 
that ALT arrow key is ignored.

The editor never sees the keys being typed until the ALT key goes up and the OS 
fires off a key event.

Comment 14

[kinmoz]

Adding myself to Cc list.

Comment 15

[Joe Francis]

Tag! Kin, you're it!

Comment 16

[Katsuhiko Momoi]

Resolving this bug as a duplicate of Bug 22206 to make it
easier to manage both bugs. Will not verify it untill
the other bug has been fixed. At that time, we will check
the behavior reported here. Dependency on Bug 22206 has been 
noted.

*** This bug has been marked as a duplicate of 22206 ***

Comment 17

[lchiang]

verified duplicate