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

VERIFIED DUPLICATE of bug 22206

Status

P3
normal
VERIFIED DUPLICATE of bug 22206
19 years ago
10 years ago

People

(Reporter: marina, Assigned: kinmoz)

Tracking

Trunk
x86
Windows NT

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+])

(Reporter)

Description

19 years ago
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

Updated

19 years ago
Assignee: ducarroz → beppe

Comment 1

19 years ago
Reassign to beppe

Comment 2

19 years ago
assigning to jfrancis and cc ftang

Comment 3

19 years ago
assigning to jfrancis and cc ftang

Comment 4

19 years ago
See also a related Bug 22206.

Updated

19 years ago
Assignee: jfrancis → brade

Comment 5

19 years ago
reassign to myself to do some preliminary investigation for jfrancis

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 6

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

Comment 7

19 years ago
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 8

19 years ago
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?
Assignee: brade → jfrancis
Status: REOPENED → NEW

Updated

19 years ago
Status: NEW → ASSIGNED
(Reporter)

Comment 9

19 years ago
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

19 years ago
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. 
    
Keywords: beta1
Summary: In Reply mode focus is lost when entering ALT+ num key → When inserting ALT+ num key characters into existing text, the cursor moves erratically

Comment 11

19 years ago
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

19 years ago
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]
(Assignee)

Comment 13

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

Comment 14

19 years ago
Adding myself to Cc list.

Comment 15

19 years ago
Tag! Kin, you're it!
Assignee: jfrancis → kin
Status: ASSIGNED → NEW

Comment 16

19 years ago
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 ***
Status: NEW → RESOLVED
Last Resolved: 19 years ago19 years ago
Depends on: 22206
Resolution: --- → DUPLICATE

Updated

19 years ago
QA Contact: lchiang → momoi

Comment 17

19 years ago
verified duplicate
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.