22206 - ALT + NUM Pad operation moves the cursor point unnecessarily

Status: VERIFIED FIXED

(MailNews Core :: Composition, defect, P3)

Description

[Katsuhiko Momoi]

** Observed with 12/17/99 Win32 M12 build **

I noticed this problem in both regular Composer and Mail Composer.
We seem to have also a similar/related problem in Reply/quoted
mail composition. Marina is filing the latter bug. This bug is
just for new composition but it seems that the cursor point
operation is currently screwed up for ALT + NUM key operation.

[Under Composer and New Mail Composer]

1. Type something like, "abcdefg"
2. Insert the cursor into the spot between 'c' and 'd'.
3. now use ALT + 0234 to insert "e" with the circumflex.
4. Note that the 'e' with the circumflex was inserted between
   'b' and 'c' instead!

Comment 1

[lchiang]

qa contact to sujay since this is in regular composer.
reassign to beppe.

Comment 2

[rubydoo123]

assigning to jfrancis

Comment 3

[Katsuhiko Momoi]

See also a related Bug 22205.

Comment 4

[Kathleen :Brade]

reassign to myself to do some preliminary investigation for jfrancis

Comment 5

[Kathleen :Brade]

I think Joe fixed this problem.
I tested it with a build from today and it now works.

Comment 6

[sujay]

verified in 1/7 build.

Comment 7

[marina]

I'm reopening this bug,because it is reemerging as a problem again.It is not 
possible to enter consequitively a line of non-ascii chars, you have to correct 
a char's position every time, cursor point is screwed up for alt+num operation.
Repeat all steps that Kat suggested and you'll see the problem. It is a valid 
problem for Editor, Mail, ABook.

Comment 8

[Kathleen :Brade]

reassign to jfrancis since he's the caret guru and may know what changes affected 
this.

Comment 9

[Katsuhiko Momoi]

This is too much of a problem to be ignored for Beta 1. 
A must for Beta 1. Let me add a bit more observation to what I reported 
originally.

1. Try to insert an ALT+NUMPad characters into the final position of  an existing string of  "abcd". You will 
    see that it gets intserted into the poisition between c and d, the one before the final position.
2. Try to insert an ALT_NUMPad character into a position between, "a" and "b" in an existing "abcd" string.
    It gets inserted into a position between "c" and "d" as in 1.

So the problem is that when Alt+Num Pad is engaged we somehow always  reset the cursor position to 
the one before the final position (i.e. penultimate position). 

Comment 10

[Katsuhiko Momoi]

Re-assigning QA contact to marina as this is needed for Intl mail and 
composer input.

Comment 11

[Joe Francis]

accepting bug.  no need to hold m13 for this.  m14'ing...

Comment 12

[Katsuhiko Momoi]

Updated keyword field to reflect beta1.

Comment 13

[leger]

Putting on PDT+ radar for beta1.

Comment 14

[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 15

[Katsuhiko Momoi]

So, kin, fixing this problem should solve Bug 22205. Should we mark the other one as a duplicate
of this bug and track it when this bug is done with?

Comment 16

[Pat Gunn]

Most high-ascii characters differ from Mac to Linux to Windows, so
the simple solution of disabling high-ascii input (however that can be
done) would probably be best for the internet.

Comment 17

[kinmoz]

Yes, bug 22205 is a dup of this bug.

Comment 18

[kinmoz]

Kat,

Is this Alt-numpad key sequence neccessary for IME?

What about the concern [e-mail] brings up above?

Comment 19

[Katsuhiko Momoi]

kin, we arecurrently able to input high-ascii characters in all 3 platforms. 

I take it that [e-mail]'s remark is simply a tonge-in-cheek statement, a bit
funny, maybe, but totally inapproriate in the context of our serious efforts to fix this problem
for Windows.

Comment 20

[Pat Gunn]

No, I'm totally serious. The use of alt-numpad is primarily used to generate
high-ascii characters (why else would you use it), and high-ascii characters
are totally nonportable because MacOS, Windows, and Unix disagree as to the
contents of the upper half of the ASCII set. So it might be better to disable
the alt-numpad (if possible) rather than fix it. Maybe MSDN has some code
to do so?

Comment 21

[Katsuhiko Momoi]

We have mail standard charsets to deal with the issues like the one you're talking about.
For example, for Larin 1 languages, Mozilla sends outmsgs  using ISO-8859-1 charset. All reputable
mailers would know how to map this charset to their own OS encoding, ISO-8859-1 ionUnix,
Windows-1252 on Windows, and MacRoman on Macintosh.

It's been working like this since the days of Navigator 1.x. I'm totally confused by the intent of your 
suggestion.

Comment 22

[Katsuhiko Momoi]

Note also that we  promote sending Latin 1 messages only with the Internet standard Latin 1
charset, i.e. ISO-8859-1. 
I'm sorry but your comments are simply off the mark.

Comment 23

[Katsuhiko Momoi]

Hi , [e-mail]' I re-read your comments and maybe there is one respect in which
they address an important issue. That is, it would be best for users not to use the high-ascii
characters which are not available in other platforms. ISO-8859-1 charset is the lowest common
denominator. The characters in that charset are available on all platforms though mapped to
different code points sometimes. This is why you don't see anything other than ISO-8859-1 as
the mail send charset in our Mail Composer menu. That is how we discourage users from inputting
high-ascii characters available only on Windows platform. 
But the ALT+NUMPad operation must be working on Windows for inputting other high-ASCII 
characters in ISO-8859-1 charset otherwise communication in most European languages
will be impossible

Please understand that we are addressing your concerns in other ways and we hope you'll find 
the final product to be reflective of inter-operability concerns.

Comment 24

[Joe Francis]

Tag! Kin, you're it!

Comment 25

[Katsuhiko Momoi]

*** Bug 22205 has been marked as a duplicate of this bug. ***

Comment 26

[kinmoz]

Accepting bug.

Comment 27

[kinmoz]

I have a fix in hand that prevents caret movement while the alt key is down. 
Currently waiting on code review.

Comment 28

[kinmoz]

Fix checked in. Should appear in the 02/10/2000 builds.

Modified all keybindings for up, down, left, right, home, end, pgUp, and pgDown
so that they are not triggered if the Alt key is down.

    mozilla/xpfe/global/resources/content/editorBindings.xul             
revision 1.6
    mozilla/xpfe/global/resources/content/browserBindings.xul            
revision 1.7
    mozilla/xpfe/global/resources/content/inputBindings.xul              
revision 1.11
    mozilla/xpfe/global/resources/content/textAreaBindings.xul           
revision 1.4
    mozilla/xpfe/global/resources/content/win/platformInputBindings.xul  
revision 1.3
    mozilla/xpfe/global/resources/skin/htmlBindings.xml                  
revision 1.4
    mozilla/xpfe/global/resources/skin/win/platformHTMLBindings.xml      
revision 1.3

r=[e-mail],[e-mail]

Comment 29

[kinmoz]

oops forgot to mark FIXED.

Comment 30

[Katsuhiko Momoi]

** Checked with 2/17/2000 Win32 build **

With the above build, ALT+NUMPad actions do not
lead to erratic cursor behavior. I can now input 
accented Latin 1 characters without any problem
either on a new line, or at an insertion point
in the middle of an exsiting text.  The latter problem
was reported in Bug 22205. All of this without locking
NumPad, which is what users expect under EN keyboard.

All these problems seem to have gone away with this fix.
Marking the fix verified.